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(a)iki.fi