On Wed, Apr 13, 2005 at 02:59:10AM -0400, you [Jakub Jelinek] wrote: > On Wed, Apr 13, 2005 at 08:54:19AM +0300, Ville Herva wrote: > > Is anyone else seeing this, or is this something specific to my > > installation: > > > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=154229 > > > > Since upgrading to glibc-2.3.4-21, I've been seeing the following problem: > > glibc.so.6 is not found when launching certain binaries (see below). > > > > Reverting back to glibc-2.3.4-18 fixes it (I just verified.) > > > > A binary called des (that I compiled on 1999) always shows this, but saw it > > with at least grep once. That problem went away by itself, but older > > binaries like des still show it. > > See %changelog: > - move LinuxThreads libraries to /%{_lib}/obsolete/linuxthreads/ > and NPTL libraries to /%{_lib}. To run a program against LinuxThreads, > LD_ASSUME_KERNEL=2.4.xx LD_LIBRARY_PATH=/%{_lib}/obsolete/linuxthreads/ > is now needed Thanks. LD_LIBRARY_PATH=/lib/obsolete/linuxthreads works. I added this information to the bugzilla entry. > The move was necessary because of the change to make NPTL the default > library programs are linked against and are using its headers. > > glibc 2.0 compiled programs are implicitly using LD_ASSUME_KERNEL=2.2.5. > I'll probably change the hack to also add implicitly > /%{_lib}/obsolete/linuxthreads/ to library search path, but be aware that > when linuxthreads is finally dumped into the trash bin, which will happen > in ~ a year or less, glibc 2.0 programs will finally stop working. > > BTW, it must have been early 1999, RHL 6.0 already shipped with glibc 2.1.x. I have at least two binaries that show this (possible quite a bit more I haven't been searching for them), and another of them is compiled on Sep 22 2002 on then-current Red Hat system. (The 7912-byte binary is available at http://iki.fi/v/tmp/xsel). I'm *quite* sure it wasn't linked against glibc 2.0. Strange. -- v -- v@xxxxxx
