Bug 213252

Summary: glibc breaks compatibility between fc5 and fc6
Product: [Fedora] Fedora Reporter: Arjan van de Ven <arjan>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 6   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2006-10-31 14:53:38 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Binary that shows this behavior when run on FC5 none

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