Re: bugs: dynamic libraries, xconsole, xdm
"Christopher C. Chimelis" <firstname.lastname@example.org> wrote:
>> The library libc-2.2.1.so does not contain the symbol lstat, but does
>> define the symbols __lxstat and __lxstat64, as suggested by the header
>> file. I'm not sure exactly what's going on here, but clearly
>> something is wrong. It looks like it might be related to the large
>> file (>4GB) support in glibc-2.2.
>xfig may need a recompile. I'll try to test this tonight to find out.
This was with regard to libgtk1.2; that's what you meant to say,
>> Finally, xdm itself takes about five minutes to start up, again on a
>> 275MHz PC64. This is independent of the xconsole problem mentioned
>> above. I know that the problem is not with the X-server, because
>> startx brings it up much faster. Something must be wrong; the xdm log
>> file is no help, because it's just a condensed version of the X-server
>> log. There doesn't appear to be any xdm-specific information in it;
>> perhaps this is a clue.
>That's very odd. xdm starts right up on my SX and even faster on my
>UP2k at work. Granted, I haven't tried it out since 4.0.2-1, but it
>worked very well then. Initial load time may be killing you, though.
>Is xdm being started at boot time or is this from the command line
Either way, same result. Using startx, on the other hand, the X-server
comes up in less than a minute. The X-server log reveals lots of
modules being loaded; this is the initial load time I'd be worried
about. It doesn't seem reasonable that xdm should take so much longer
Update: I just tried it again, and xdm actually takes 3-1/2 minutes to
bring up the X-server, and during this time it's eating 98% of the
CPU. Try this:
# /etc/init.d/xdm start ; top
Then you can watch the CPU utilization until the video mode changes;
better yet, do it through a telnet session. I bet that your machines
are doing the same thing as mine, only faster.
Get free email and a permanent address at http://www.netaddress.com/?N=1