> 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 libc5):
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
Attachment:
pgpGurQj85l5a.pgp
Description: PGP signature