Re: HELP WANTED: doogiebug strikes latest XFree86 packages
"Marcelo E. Magallon" <mmagallo@debian.org> writes:
> >> Mark Montague <monty@gg.caltech.edu> writes:
>
> > I saw and fixed something similar-- on looking with ldd, I found that
> > it ld.so was finding /usr/lib/libc5-compat/libXmu.so.6 before
> > /usr/X11R6/lib/libXmu.so.6.
>
> That *should* be ok. The dynamic linker should be able to tell that
> the libraries in /usr/lib/libc5-compat/ are libc5 libraries.
I seem to remember seeing some libc5-compat notes in the
apt-listchanges; maybe that's where the problem came in.
Experimentally, it's like this:
% ldd `which xterm`
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4002d000)
libXaw.so.7 => /usr/X11R6/lib/libXaw.so.7 (0x40065000)
libXmu.so.6 => /usr/lib/libc5-compat/libXmu.so.6 (0x400b9000)
libXt.so.6 => /usr/lib/libc5-compat/libXt.so.6 (0x400cb000)
libSM.so.6 => /usr/lib/libc5-compat/libSM.so.6 (0x4010e000)
libICE.so.6 => /usr/lib/libc5-compat/libICE.so.6 (0x40117000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x4012d000)
libXext.so.6 => /usr/lib/libc5-compat/libXext.so.6
(0x4013b000)
libX11.so.6 => /usr/lib/libc5-compat/libX11.so.6 (0x40146000)
libncurses.so.5 => /lib/libncurses.so.5 (0x401e3000)
libc.so.6 => /lib/libc.so.6 (0x40224000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
% xterm
xterm: error while loading shared libraries:
/usr/X11R6/lib/libXaw.so.7: undefined symbol:
XmuCvtGravityToString
% cat /etc/ld.so.conf
# for XF86 3.9 testing
#/gagdsk1/monty/X_3.9.15_public_beta/usr/X11R6/lib
/usr/lib/InventorDebug
/usr/X11R6/lib/Xaw3d
/usr/local/lib
#/usr/X11R6/lib
/usr/lib/libc5-compat
/lib/libc5-compat
/usr/X11R5/lib
/usr/lib/StarOffice-3.1/linux-x86/lib
/usr/X11R6/lib
versus:
% ldd `which xterm`
libfreetype.so.6 => /usr/lib/libfreetype.so.6 (0x4002d000)
libXaw.so.7 => /usr/X11R6/lib/libXaw.so.7 (0x40065000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x400b9000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x400ce000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x40118000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x40121000)
libXpm.so.4 => /usr/X11R6/lib/libXpm.so.4 (0x40137000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x40145000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x40153000)
libncurses.so.5 => /lib/libncurses.so.5 (0x4022e000)
libc.so.6 => /lib/libc.so.6 (0x4026f000)
/lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)
% xterm
[normal behavior]
% cat /etc/ld.so.conf
# for XF86 3.9 testing
#/gagdsk1/monty/X_3.9.15_public_beta/usr/X11R6/lib
/usr/lib/InventorDebug
/usr/X11R6/lib/Xaw3d
/usr/local/lib
/usr/X11R6/lib
/usr/lib/libc5-compat
/lib/libc5-compat
/usr/X11R5/lib
/usr/lib/StarOffice-3.1/linux-x86/lib
#/usr/X11R6/lib
I do note that the ldconfig man page says:
ldconfig will attempt to deduce the type of ELF libs (ie.
libc5 or libc6/glibc) based on what C libs if any the
library was linked against, therefore when making dynamic
libraries, it is wise to explicitly link against libc (use
-lc).
and I also see:
% strings /usr/lib/libc5-compat/libXmu.so.6 | grep libc.so
libc.so.6
% strings /usr/lib/libc5-compat/libz.so.1 | grep libc.so
libc.so.5
% dpkg --search libc5-compat/libXmu
xlib6: /usr/lib/libc5-compat/libXmu.so.6.0
xlib6: /usr/lib/libc5-compat/libXmu.so.6
% dpkg --status xlib6
Package: xlib6
Status: install ok installed
Priority: optional
Section: oldlibs
Installed-Size: 1912
Maintainer: Branden Robinson <branden@debian.org>
Source: xfree86v3
Version: 3.3.6-37
Replaces: xbase (<< 3.3.2.3a-2), elf-x11r6lib, xlib
Depends: xlibs (>> 4.0), libc6 (>= 2.2.1-2)
Conflicts: elf-x11r6lib, xlib
Description: shared libraries required by libc5 X clients
[...]
So it looks like the libc5-compat libs may have been linked to the
wrong libc this time around, maybe.
- M
--
Mark "Monty" Montague | monty@gg.caltech.edu | I don't do Windows(tm)
I'm dubious about any company whose assets can be destroyed by rm -rf
<URL:http://www.gg.caltech.edu/~monty/monty.shtml>
X-PGP-Fingerprint: E4 EA 6D B1 82 46 DB A1 B0 FF 60 B9 F9 5D 5C F7
Reply to: