Description of problem: None of the libraries in /lib and /usr/lib have the note specifying the desired kernel OS ABI. This causes some programs to fail if invoked under the environment variable LD_ASSUME_KERNEL Version-Release number of selected component (if applicable): glibc-2.3.4-2.fc3 (etc.) How reproducible: On an x86_64 platform do the following. Notice that /lib/libc has a note specifying the OS ABI, but that /lib64/libc doesn't. $ eu-readelf -n /lib/libc.so.6 /lib64/libc.so.6 /lib/libc.so.6: Note segment of 32 bytes at offset 0x154: Owner Data size Type GNU 16 VERSION OS: Linux, ABI: 2.2.5 /lib64/libc.so.6: Note segment of 32 bytes at offset 0x238: Owner Data size Type This produces the following kind of error: $ export LD_ASSUME_KERNEL=2.2.5 $ grep --version grep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such fileor directory Steps to Reproduce: 1. See above Actual results: grep: error while loading shared libraries: libc.so.6: cannot open shared object file: No such fileor directory Expected results: grep (GNU grep) 2.5.1 Additional info: The problem show up in nature when invoking firefox from a console.
Exporting LD_ASSUME_KERNEL=2.2.5 for all apps is a wrong thing to do. Although 32-bit glibc supports kernels that old, 64-bit does not (x86-64 glibc can only work with 2.4.x kernels). So, just use LD_ASSUME_KERNEL=2.4.0 /the/program/that/really/needs non-FLOATING_STACKS 32-bit linuxthreads (i.e. set it in env just for the programs that need it and no others). See http://people.redhat.com/drepper/assumekernel.html for more details about LD_ASSUME_KERNEL.