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) = ?
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
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
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
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
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.
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.
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.