Bug 213252 - glibc breaks compatibility between fc5 and fc6
glibc breaks compatibility between fc5 and fc6
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: glibc (Show other bugs)
6
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-10-31 09:35 EST by Arjan van de Ven
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-31 09:53:38 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Binary that shows this behavior when run on FC5 (85.88 KB, application/octet-stream)
2006-10-31 09:35 EST, Arjan van de Ven
no flags Details

  None (edit)
Description Arjan van de Ven 2006-10-31 09:35:16 EST
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:

(gdb) run
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
(gdb) bt
#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
Comment 1 Arjan van de Ven 2006-10-31 09:35:21 EST
Created attachment 139854 [details]
Binary that shows this behavior when run on FC5
Comment 2 Jakub Jelinek 2006-10-31 09:53:38 EST
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).
Comment 3 Arjan van de Ven 2006-10-31 09:57:42 EST
since I use the fc5 glibc for linking it's not quite pure luck :)

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