From Bugzilla Helper: User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description of problem: I've compiled and linked an application on RH7.2, where it runs fine. Trying to run it on RH7.3, it dies at runtime with a linker error: fsearch: relocation error: fsearch: symbol __libc_close, version GLIBC_2.0 not defined in file libc.so.6 with link time reference AFAIK, RH7.3 is supposed to be fully binary compatible with RH7.2? It seems the __libc_close function has been tagged with a different version in RH7.3 (see below), causing the linker problems. Is the problem in my build process, or is it simply glibc 2.2.5 which breaks binary compability? The app uses pthreads, I believe this may be the source of the symbol linkage, but I'm not sure (how to find out?). $ readelf -a fsearch | grep __libc_close 081cd8fc 01007 R_386_JUMP_SLOT 0804a2e0 __libc_close 16: 0804a2e0 58 FUNC GLOBAL DEFAULT UND __libc_close (3) 902: 0804a2e0 58 FUNC GLOBAL DEFAULT UND __libc_close@@GLIBC_2.0 RedHat 7.2 (glibc 2.2.4): $ readelf -a /lib/libc.so.6 | grep __libc_close 1303: 000e1780 58 FUNC GLOBAL DEFAULT 11 __libc_close@@GLIBC_2.0 RedHat 7.3 (glibc 2.2.5): $ readelf -a /lib/libc.so.6 | grep __libc_close 1289: 000dbf30 58 FUNC GLOBAL DEFAULT 11 __libc_close@@GLIBC_PRIVATE Version-Release number of selected component (if applicable): How reproducible: Always Steps to Reproduce: Additional info:
Never mind, this turned out to be a problem in my application (explicit linking with __libc_close). Sorry about the noise.