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.
des
des: error while loading shared libraries: libc.so.6: cannot open shared object
file =des
/usr/local/bin/des: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), not stripped
ldd =des
/lib/libNoVersion.so.1 (0xb7fe4000) linux-gate.so.1 => (0xffffe000) libc.so.6 => not found libc.so.6 => not found
But:
ldd =grep
linux-gate.so.1 => (0xffffe000) libpcre.so.0 => /lib/libpcre.so.0 (0x43d27000) libc.so.6 => /lib/libc.so.6 (0xb7ea0000) /lib/ld-linux.so.2 (0xb7fe7000)
(See bugzilla for further details).
-- v --
v@iki.fi
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).
I'm getting similar messages when running firefox or mozilla from a terminal; errors when running the grep, cut, and sed commands contained within the scripts that launch firefox and mozilla:
[jat48@thacker ~]$ firefox grep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory cut: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory sed: error while loading shared libraries: libc.so.6: cannot open shared object file: No such file or directory
John Thacker
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
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.
Jakub
On Wed, 13 Apr 2005 02:59:10 -0400, Jakub Jelinek wrote:
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.
Dumped in the trash bin? It'll at least still be installable from Extras, right? The games and programsa that NPTL broke are still out there, I still have to use LD_ASSUME_KERNEL every so often.
thanks -mike
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@iki.fi
On Wed, Apr 13, 2005 at 07:59:30PM +0300, you [Ville Herva] wrote:
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.
<Slap> The binary (xsel) wasn't compiled on on the system I thought I had compiled it on. It was compiled on Red Hat 6.2. Sorry for the noise.
-- v --
v@iki.fi