Bug 154229 - glibc-2.3.4-21: ld.so does not find glibc.so.6 for certain binaries
glibc-2.3.4-21: ld.so does not find glibc.so.6 for certain binaries
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
rawhide
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-04-08 12:38 EDT by Ville Herva
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version: 2.3.5-3
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-04-28 08:55:45 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Ville Herva 2005-04-08 12:38:25 EDT
Since upgrading to glibc-2.3.4-21, I've seen 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)

> LD_DEBUG=all des
     12311:	
     12311:	file=/lib/libNoVersion.so.1 [0];  needed by des [0]
     12311:	file=/lib/libNoVersion.so.1 [0];  generating link map
     12311:	  dynamic: 0xb7fe5f20  base: 0xb7fe4000   size: 0x00002028
     12311:	    entry: 0xb7fe46c8  phdr: 0xb7fe4034  phnum:          8
     12311:	
     12311:	
     12311:	file=libc.so.6 [0];  needed by des [0]
     12311:	find library=libc.so.6 [0]; searching
     12311:	 search cache=/etc/ld.so.cache
     12311:	 search path=/lib/tls/i686:/lib/tls:/lib/i686:/lib:/usr/lib/tls/
i686:/usr/lib/tls:/usr/lib/i686:/usr/lib		(system search path)
     12311:	  trying file=/lib/tls/i686/libc.so.6
     12311:	  trying file=/lib/tls/libc.so.6
     12311:	  trying file=/lib/i686/libc.so.6
     12311:	  trying file=/lib/libc.so.6
     12311:	  trying file=/usr/lib/tls/i686/libc.so.6
     12311:	  trying file=/usr/lib/tls/libc.so.6
     12311:	  trying file=/usr/lib/i686/libc.so.6
     12311:	  trying file=/usr/lib/libc.so.6
     12311:	
des: error while loading shared libraries: libc.so.6: cannot open shared object 
file: No such file or directory

> ls -l /lib/libc.so.6
lrwxrwxrwx  1 root root 13 Apr  8 12:58 /lib/libc.so.6 -> libc-2.3.4.so
> ls -l /lib/libc-2.3.4.so
-rwxr-xr-x  1 root root 1477796 Apr  6 02:26 /lib/libc-2.3.4.so

> strace des
execve("/usr/local/bin/des", ["des"], [/* 56 vars */]) = 0
uname({sys="Linux", node="babbage", ...}) = 0
brk(0)                                  = 0x804b000
access("/etc/ld.so.preload", R_OK)      = -1 ENOENT (No such file or directory)
open("/lib/libNoVersion.so.1", O_RDONLY) = 3
fstat64(3, {st_mode=S_IFREG|0755, st_size=7696, ...}) = 0
close(3)                                = 0
open("/lib/libNoVersion.so.1", O_RDONLY) = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\310\6\0"..., 512) = 512
fstat64(3, {st_mode=S_IFREG|0755, st_size=7696, ...}) = 0
old_mmap(NULL, 8232, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 3, 0) = 
0xb7fe4000
old_mmap(0xb7fe5000, 8192, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|
MAP_DENYWRITE, 3, 0) = 0xb7fe5000
close(3)                                = 0
old_mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0xb7fe3000
open("/etc/ld.so.cache", O_RDONLY)      = 3
fstat64(3, {st_mode=S_IFREG|0644, st_size=121779, ...}) = 0
old_mmap(NULL, 121779, PROT_READ, MAP_PRIVATE, 3, 0) = 0xb7fc5000
close(3)                                = 0
open("/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/lib/tls/libc.so.6", O_RDONLY)    = -1 ENOENT (No such file or directory)
open("/lib/i686/libc.so.6", O_RDONLY)   = -1 ENOENT (No such file or directory)
open("/lib/libc.so.6", O_RDONLY)        = 3
read(3, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\nO\1\000"..., 512) = 
512
close(3)                                = 0
open("/usr/lib/tls/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
open("/usr/lib/i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or 
directory)
open("/usr/lib/libc.so.6", O_RDONLY)    = -1 ENOENT (No such file or directory)
writev(2, [{"des", 3}, {": ", 2}, {"error while loading shared libra"..., 36}, 
{": ", 2}, {"libc.so.6", 9}, {": ", 2}, {"cannot open shared object file", 30}, 
{": ", 2}, {"No such file or directory", 25}, {"\n", 1}], 10des: error while 
loading shared libraries: libc.so.6: cannot open shared object file: No such 
file or directory
) = 112
exit_group(127)                         = ?
Comment 1 Jukka Ketelaars 2005-04-09 09:28:37 EDT
I have a similar problem with SAP WebAS scripts. It is easy to demonstrate as
follows:

$ LD_ASSUME_KERNEL=2.4.19
$ uname 
uname: error while loading shared libraries: libc.so.6: cannot open shared
object file: No such file or directory

One version higher and things are ok:

$ LD_ASSUME_KERNEL=2.4.20
$ uname 
Linux
Comment 2 Ville Herva 2005-04-11 01:45:46 EDT
LD_ASSUME_KERNEL does not seem make any diffence for the des binary, but I can 
get the uname symptom reproduced with it:

>LD_ASSUME_KERNEL=2.4.19 des
des: error while loading shared libraries: libc.so.6: cannot open shared object 
file: No such file or directory
>LD_ASSUME_KERNEL=2.4.20 des  
des: error while loading shared libraries: libc.so.6: cannot open shared object 
file: No such file or directory
>LD_ASSUME_KERNEL=2.4.19 uname
uname: error while loading shared libraries: libc.so.6: cannot open shared 
object file: No such file or directory
>LD_ASSUME_KERNEL=2.4.20 uname
Linux
Comment 3 John Thacker 2005-04-13 02:26:43 EDT
Similar error when running firefox or mozilla from a terminal.  I get errors
from the grep, cut, or sed inside the scripts that launch firefox and mozilla. 
Happened with this glibc update:

[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
Comment 4 Christopher Aillon 2005-04-13 09:09:38 EDT
It also affects compilation of Firefox/Mozilla:

c++ -I/usr/X11R6/include -fno-rtti -fno-exceptions -Wall -Wconversion
-Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy
-Wno-non-virtual-dtor -Wno-long-long -pedantic -fshort-wchar -pthread -pipe 
-DNDEBUG -DTRIMMED -Os -g -pipe -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -m32
-march=i386 -mtune=pentium4 -fasynchronous-unwind-tables  -DXTHREADS
-D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include
-I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0
-I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0
-I/usr/lib/glib-2.0/include   -fPIC -shared -Wl,-h -Wl,libgfx_gtk.so -o
libgfx_gtk.so  nsPrintdGTK.o gtk2drawing.o nsDeviceContextGTK.o
nsDeviceContextSpecFactoryG.o nsDeviceContextSpecG.o nsDrawingSurfaceGTK.o
nsGfxFactoryGTK.o nsGraphicsStateGTK.o nsImageGTK.o nsGCCache.o
nsRenderingContextGTK.o nsScreenGtk.o nsScreenManagerGtk.o nsPrintOptionsGTK.o
nsFontMetricsUtils.o nsAntiAliasedGlyph.o nsFontFreeType.o nsFT2FontNode.o
nsFT2FontCatalog.o nsX11AlphaBlend.o nsXFontAAScaledBitmap.o nsXFontNormal.o
nsFontMetricsGTK.o nsGdkUtils.o nsFontMetricsXft.o nsFontMetricsPango.o
mozilla-decoder.o nsRegionGTK2.o nsNativeThemeGTK.o       -Wl,--whole-archive
../../../dist/lib/libgfxft2_s.a -Wl,--no-whole-archive  -Wl,--version-script
-Wl,../../../build/unix/gnu-ld-scripts/components-version-script -Wl,-Bsymbolic
-L../../../dist/bin -lxpcom  -L../../../dist/bin -L/usr/local/lib -lplds4 -lplc4
-lnspr4 -lpthread -ldl  -lgkgfx -lgfxshared_s -lXinerama -L../../../dist/bin
-lmozjs ../../../dist/lib/libunicharutil_s.a   -L/usr/X11R6/lib   -lXft -lX11
-lfreetype -lXrender -lfontconfig   -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0
-lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0
-lgmodule-2.0 -ldl -lglib-2.0   -lpangoft2-1.0 -ldl -lm
/usr/bin/ld: cannot find -lgfxshared_s
collect2: ld returned 1 exit status
gmake[5]: *** [libgfx_gtk.so] Error 1
Comment 5 Ville Herva 2005-04-13 12:56:22 EDT
Information from Jakub Jelinek:

https://www.redhat.com/archives/fedora-devel-list/2005-April/msg00479.html
_________________________________________________________________________
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                                                                   
_________________________________________________________________________

LD_LIBRARY_PATH=/lib/obsolete/linuxthreads does help.
Comment 6 Jakub Jelinek 2005-04-28 08:55:45 EDT
In glibc-2.3.5-3 I have added a hack which automatically appends
/%{_lib}/obsolete/linuxthreads/ to search path for glibc 2.0 binaries
and LD_ASSUME_KERNEL less than 2.4.20.
Note that Fedora Core 5 will not include LinuxThreads though, so you'd better
start looking for replacement for glibc 2.0 compiled programs.
Comment 7 Ville Herva 2005-05-10 06:50:52 EDT
Ok, yum finally pulled the new glibc-2.3.5-6 into my Fedora Rawhide 
installation. I can now confirm that the legacy apps do work "out of the box" 
with it. 

I will recompile, though.

Note You need to log in before you can comment on or make changes to this bug.