> Hi. I'm sorry for posting to not apropriate mailing list, but right now I
> have no choice, and I really need a quick help. :)
>
> I have one trouble: after installing glibc 2.0.5 (from redhat 4.8.1) and
> kernel 2.0.31pre10 (well, it's a real pre9 kernel + pre9-pre10 patch), and
> after updating most of the packages (pine, joe, X, .. - from rh 4.8.1 too)
> I have some troubles.
>
> Why some of my old binaries (compiled under libc5.4.34) now
> requires libc.so.5 AND libc.so.6? ldd reports that. Certainly, they don't
> work. Some of my old binaries requires, some not - why? How do I fix
> this?
We had this problem with the unstable version of Debian, which we are
currently switching over to glibc/libc6. I'll relate to you the Debian
experience, and you can try to figure out the equivalent for Red Hat
(which I'm not terribly familiar with).
Actually, I'll just attach a copy of a posting I made to debian-user.
You might want to read some of the debian-devel archives to get a
more complete understanding.
Assuming Red Hat works the same way, you'll have a bunch of libc5 libraries
in /usr/lib/libc5-compat, and libc6 libraries in the normal locations.
The latest ld.so should be able to figure it out most of the time,
except for some cases where the paths are hard-coded into the binaries.
In those cases, you need to recompile those apps for libc6, or edit
the binaries as detailed in the message below.
As I said, I'm not sure what Red Hat is doing. They may not support
mixing libc5 and libc6 yet. Perhaps this message should go to
tbird-list@redhat.com instead?
Cheers,
- Jim
------- Forwarded Message
To: adavis@netpci.com
Cc: debian-user@lists.debian.org
Subject: Re: Emacs dumps core after some major upgrades on system
Date: Sun, 14 Sep 1997 00:20:25 -0700
From: Jim Pick <jim@jimpick.com>
> Emacs dumps core, repeatedly. I just replaced the xlib6, installing both
> xlib6 and xlib6g in hamm. Is this possibly the problem? I have just installed
> new slang0.99 libraries from hamm, and the newest svgalib1 in hamm. Also, a
> number of applicatoins that were, mainly dependent upon earlier slang0 libs.
> I also had to reinstall dosemu today, and I installed, then removed wine.
>
> Out of these, can someone see something that might have interacted w/ emacs?
> Since I lean heavily on emacs, I'll have to back out of a lot of these
> upgrades, hope-fully.
>
> Alan Davis
> adavis@netpci.com
This is a question about the unstable distribution - so it really belongs on
debian-devel. But I'll give a quick summary here. Followups to debian-devel,
please.
There was a huge thread in debian-devel "Re: xlib6g and emacs (and others)"
about this.
This is happening because emacs is accidentally being dynamically linked
against the
new libc6 libraries that came in xlib6g (the old libc5 libraries are shuffled
off to /usr/lib/libc5-compat) as well as libc5.
You can verify this by doing:
fleming:/mirror/debian/hamm$ ldd /usr/bin/emacs
libXaw.so.6 => /usr/X11R6/lib/libXaw.so.6 (0x4000c000)
libXmu.so.6 => /usr/X11R6/lib/libXmu.so.6 (0x40044000)
libXt.so.6 => /usr/X11R6/lib/libXt.so.6 (0x40056000)
libSM.so.6 => /usr/X11R6/lib/libSM.so.6 (0x4009e000)
libICE.so.6 => /usr/X11R6/lib/libICE.so.6 (0x400a7000)
libXext.so.6 => /usr/X11R6/lib/libXext.so.6 (0x400bc000)
libX11.so.6 => /usr/X11R6/lib/libX11.so.6 (0x400c8000)
libncurses.so.3.0 => /lib/libncurses.so.3.0 (0x4016c000)
libm.so.5 => /lib/libm.so.5 (0x401a8000)
libc.so.5 => /lib/libc.so.5 (0x401b1000)
libc.so.6 => /lib/libc.so.6 (0x4026d000)
ld-linux.so.2 => /lib/ld-linux.so.2 (0x4030b000)
(my emacs is broken right now too)
Because there were so many libraries to move from libc5 to libc6, we don't
want to have to rename them all to have different names and versions (which
would have been simpler), because then we'd need to make major changes to
the source code for almost every package to link with the new libs.
For some libraries, we do have different .so names (ie. libc.so.5, libc.so.6)
- - but for most of the additional libraries, we are just going to keep the
same old .so names, and place the libc6 version of the libs in the standard
locations (/lib, /usr/lib, /usr/X11R6/lib), and place the libc5 versions of
the libs in an "alternate location" (/usr/lib/libc5-compat).
The new ld.so (the dynamic linker) has been hacked to try to determine whether
or not a program wants to link with the libc5 or libc6 version - and sets up
the links appropriately. You can see where it thinks the libraries are by
typing the following: (I've trimmed the results a bit)
# ldconfig -p
258 libs found in cache `/etc/ld.so.cache' (version 1.7.0)
libpng.so.1 (ELF) => /usr/lib/libpng.so.1
libpng.so.0 (ELF) => /usr/lib/libpng.so.0
libpng.so (ELF) => /usr/lib/libpng.so
libndbm.so (ELF-libc5) => /usr/lib/libc5-compat/libndbm.so
libndbm.so (ELF-libc6) => /usr/lib/libndbm.so
libdl.so.2 (ELF-libc6) => /lib/libdl.so.2
libdl.so.1 (ELF-libc5) => /lib/libdl.so.1
libdl.so (ELF-libc6) => /usr/lib/libdl.so
libdbm.so (ELF-libc5) => /usr/lib/libc5-compat/libdbm.so
libdbm.so (ELF-libc6) => /usr/lib/libdbm.so
libc.so.6 (ELF-libc6) => /lib/libc.so.6
libc.so.5 (ELF-libc5) => /lib/libc.so.5
libX11.so.6 (ELF-libc6) => /usr/X11R6/lib/libX11.so.6
libX11.so.6 (ELF-libc6) => /usr/openwin/lib/libX11.so.6
libX11.so.6 (ELF) => /usr/lib/libc5-compat/libX11.so.6
libX11.so (ELF-libc6) => /usr/X11R6/lib/libX11.so
libX11.so (ELF-libc6) => /usr/openwin/lib/libX11.so
So, the ld.so linker uses this info to try to determine what libraries
to link with. Note that in some cases, it has identified libraries
as either libc5 or libc6. And in some cases, it doesn't know (because
they are staticly linked? or haven't bee updated yet?).
For newly compiled binaries that use dynamically linked libs, they
provide enough info for ld.so to make the proper decision. For older
binaries, ld.so has to guess, and sometimes it makes a mistake.
I think that's what is happening to emacs (and many other apps). The
simple fix is to re-compile emacs for libc6, and ld.so will know
what to do. Of course, we are in a transition state right now, where
it was impossible to compile emacs (and other packages) until the
proper libs were available.
The current libc5 emacs was built with '-rpath /usr/X11R6/lib' in it's
Imakefile causing it to use the libc6-based X libs instead of the
libc5-based. (don't ask me, I don't understand) I think fvwm2 had
the same problem, which is why I had to recompile it for it to work
after I upgraded to xlib6g.
Here's some snippets from the thread on debian-devel:
David Engel wrote:
> The quickest way to work around the problem without removing xlib6g is
> to edit the emacs binary, search for "/usr/X11R6/lib" and replace
> "usr/X11R6/lib" with ASCII NUL characters. If you don't know how or
> can't do this, I've put a compressed, already-edited version at
> ftp://ftp.ods.com/pub/linux/emacs.gz. Just fetch it, uncompress it,
> "chmod +x" it and copy it to /usr/bin.
> > David Engel wrote:
> The quickest way to work around the problem without removing xlib6g is
> to edit the emacs binary, search for "/usr/X11R6/lib" and replace
> "usr/X11R6/lib" with ASCII NUL characters. If you don't know how or
> You also need to check that that path isn't followed by a / (you're
> destroying other search paths for other things if it is). And it
> doesn't have to be NULs, anything that isn't a directory with X libs
> in will do :)
Mark Barker wrote:
> I used the following little script:
>
> #!/bin/sed -f
> s|/usr/X11R6/lib\([^/]\)|/usr/zzzzz/lib\1|
Here's what I did (the above script installed as sedlibc5):
fleming:/usr/bin# cp emacs emacs.bak
fleming:/usr/bin# sedlibc5 emacs.bak > emacs.
fleming:/usr/bin# chmod +x emacs
fleming:/usr/bin# ldd emacs
libXaw.so.6 => /usr/X11R6/lib/Xaw3d/libXaw.so.6 (0x4000c000)
libXmu.so.6 => /usr/lib/libc5-compat/libXmu.so.6 (0x4005e000)
libXt.so.6 => /usr/lib/libc5-compat/libXt.so.6 (0x40070000)
libSM.so.6 => /usr/lib/libc5-compat/libSM.so.6 (0x400b2000)
libICE.so.6 => /usr/lib/libc5-compat/libICE.so.6 (0x400bb000)
libXext.so.6 => /usr/lib/libc5-compat/libXext.so.6 (0x400d0000)
libX11.so.6 => /usr/lib/libc5-compat/libX11.so.6 (0x400db000)
libncurses.so.3.0 => /lib/libncurses.so.3.0 (0x40179000)
libm.so.5 => /lib/libm.so.5 (0x401b5000)
libc.so.5 => /lib/libc.so.5 (0x401be000)
et voila - it works!
Cheers,
- Jim
------- End of Forwarded Message
--==_Exmh_-164283026P
Content-Type: application/pgp-signature
-----BEGIN PGP MESSAGE-----
Version: 2.6.3a
iQCVAwUBNC3uaeQz770qyIfJAQHyrwP9Hgb8f21MhVcGpCibUfcvxdsGglf/iHE1
UVMfjJfkWhVpw6KUvgxtP8+h9+CEa0abu31FUrjfJg4yO/MnTbeS+I6c5dQ9gGjx
TBs9ZX5nY0EQ9QYemxcdcLG1uG6Oo9OpRtMgiOepzg66KyrMTSdmTzzHIRkVR+UX
qzjsorjo3Pg=
=e8eh
-----END PGP MESSAGE-----
--==_Exmh_-164283026P--