bugs: dynamic libraries, xconsole, xdm
some bugs I've encountered while upgrading to glibc-2.2.1 and
This binary is dynamically linked to a library called 'libXaw3d.so.7',
which as far as I can tell exists nowhere; it's not in the xaw3dg
package from stable, testing, or unstable. I don't know how this could
happen; however, after making a symlink from libXaw3d.so.7 to
libXaw3d.so.6 and running ldconfig, it appears to work OK.
This library is unusable because:
error while loading shared libraries:
/usr/lib/libgtk-1.2.so.0: undefined symbol: lstat
Here's a relevant quote from /usr/include/sys/stat.h
(packaged in libc6.1-dev_2.2.1-1):
/* To allow the `struct stat' structure and the file type `mode_t'
bits to vary without changing shared library major version number,
the `stat' family of functions and `mknod' are in fact inline
wrappers around calls to `xstat', `fxstat', `lxstat', and `xmknod',
which all take a leading version-number argument designating the
data structure and bits used. <bits/stat.h> defines _STAT_VER with
the version number corresponding to `struct stat' as defined in
that file; and _MKNOD_VER with the version number corresponding to
the S_IF* macros defined therein. It is arranged that when not
inlined these function are always statically linked; that way a
dynamically-linked executable always encodes the version number
corresponding to the data structures it uses, so the `x' functions
in the shared library can adapt without needing to recompile all
Further inspection of this header file reveals that lstat() is an
external reference only under the following conditions:
#if defined __USE_BSD || defined __USE_XOPEN_EXTENDED
# ifndef __USE_FILE_OFFSET64
/* Get file attributes about FILE and put them in BUF.
If FILE is a symbolic link, do not follow it. */
extern int lstat (__const char *__restrict __file,
struct stat *__restrict __buf) __THROW;
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.
xconsole (from xbase-clients_4.0.2-1)
I found that this program was consuming 80% of the CPU time on a
275MHz PC64. This can't be right. xdm_4.0.2-1 runs this program by
default; I had to disable it (/etc/X11/xdm/Xsetup).
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.
I hope this information is helpful to somebody.
Get free email and a permanent address at http://www.netaddress.com/?N=1