Description of problem:
Building an application on fc6 but against the fc5 glibc causes this application
to just crash and burn when run on fc5, with the following backtrace:
Starting program: /root/biostest
Reading symbols from shared object read from target memory...done.
Loaded system supplied DSO at 0xccf000
Program received signal SIGFPE, Arithmetic exception.
0x00d8d1e6 in do_lookup_x () from /lib/ld-linux.so.2
#0 0x00d8d1e6 in do_lookup_x () from /lib/ld-linux.so.2
#1 0x00d8d569 in _dl_lookup_symbol_x () from /lib/ld-linux.so.2
#2 0x00d8ed1a in _dl_relocate_object () from /lib/ld-linux.so.2
#3 0x00d87833 in dl_main () from /lib/ld-linux.so.2
#4 0x00d9756b in _dl_sysdep_start () from /lib/ld-linux.so.2
#5 0x00d8648f in _dl_start () from /lib/ld-linux.so.2
#6 0x00d84847 in _start () from /lib/ld-linux.so.2
Created attachment 139854 [details]
Binary that shows this behavior when run on FC5
glibc only provides backward compatibility, not forward compatibility.
So, if you compile/link against glibc 2.4, you can expect it to run against
glibc 2.5, but not vice versa.
Often new functions are added or their ABI changes and glibc just adds a new
symbol version; as soon as that happens, you really can't run the program
compiled/linked against newer glibc on a system with older glibc.
The .gnu.hash stuff is similar, only glibc 2.5 and later supports DT_GNU_HASH,
so programs/dsos which only have .gnu.hash and don't have .hash section can't be
run against older glibc.
All this is caught by rpm dependencies, if you have a program/dso which only
has .gnu.hash and not .hash, it will have a rtld(GNU_HASH) rpm dependency which
is only satisfied by glibc 2.5+.
You can link with -Wl,--hash-style=both or -Wl,--hash-style=sysv to link
binaries/dsos which can be loaded even by pre-2.5 ld.so (but even then it is a
pure luck if you don't use any *@GLIBC_2.5 symbols).
since I use the fc5 glibc for linking it's not quite pure luck :)