[lkml]   [1997]   [Sep]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: OFFTOPIC: glibc 2.0.5 strangeness?

    > 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 AND 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 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 instead?


    - Jim

    ------- Forwarded Message
    Subject: Re: Emacs dumps core after some major upgrades on system
    Date: Sun, 14 Sep 1997 00:20:25 -0700
    From: Jim Pick <>

    > 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

    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,

    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 => /usr/X11R6/lib/ (0x4000c000) => /usr/X11R6/lib/ (0x40044000) => /usr/X11R6/lib/ (0x40056000) => /usr/X11R6/lib/ (0x4009e000) => /usr/X11R6/lib/ (0x400a7000) => /usr/X11R6/lib/ (0x400bc000) => /usr/X11R6/lib/ (0x400c8000) => /lib/ (0x4016c000) => /lib/ (0x401a8000) => /lib/ (0x401b1000) => /lib/ (0x4026d000) => /lib/ (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.,
    - - 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 (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/' (version 1.7.0) (ELF) => /usr/lib/ (ELF) => /usr/lib/ (ELF) => /usr/lib/ (ELF-libc5) => /usr/lib/libc5-compat/ (ELF-libc6) => /usr/lib/ (ELF-libc6) => /lib/ (ELF-libc5) => /lib/ (ELF-libc6) => /usr/lib/ (ELF-libc5) => /usr/lib/libc5-compat/ (ELF-libc6) => /usr/lib/ (ELF-libc6) => /lib/ (ELF-libc5) => /lib/ (ELF-libc6) => /usr/X11R6/lib/ (ELF-libc6) => /usr/openwin/lib/ (ELF) => /usr/lib/libc5-compat/ (ELF-libc6) => /usr/X11R6/lib/ (ELF-libc6) => /usr/openwin/lib/

    So, the 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 to make the proper decision. For older
    binaries, 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 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
    > 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 => /usr/X11R6/lib/Xaw3d/ (0x4000c000) => /usr/lib/libc5-compat/ (0x4005e000) => /usr/lib/libc5-compat/ (0x40070000) => /usr/lib/libc5-compat/ (0x400b2000) => /usr/lib/libc5-compat/ (0x400bb000) => /usr/lib/libc5-compat/ (0x400d0000) => /usr/lib/libc5-compat/ (0x400db000) => /lib/ (0x40179000) => /lib/ (0x401b5000) => /lib/ (0x401be000)

    et voila - it works!


    - Jim

    ------- End of Forwarded Message

    [unhandled content-type:application/pgp-signature]
     \ /
      Last update: 2005-03-22 13:40    [W:0.035 / U:15.052 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site