With glibc-2.2.5-29 I get the following error: <progname>: relocation error: <progname>: symbol _dl_catch_error, version GLIBC_2.0 not defined in file ld-linux.so.2 with link time reference It was compiled on Red Hat Linux 7.2.
Which program, what does running the program with LD_DEBUG=files show? This means either you have stale copy of one of glibc shared libraries hanging around, or that the program or some library it uses wants to use forbidden glibc private interface.
Here is the full output: [pzb@gargleblaster pzb]$ LD_DEBUG=files red-carpet 28745: 28745: file=libc.so.6; needed by red-carpet 28745: file=libc.so.6; generating link map 28745: dynamic: 0x42130220 base: 0x00000000 size: 0x00134d60 28745: entry: 0x420175a0 phdr: 0x42000034 phnum: 6 28745: 28745: 28745: calling init: /lib/i686/libc.so.6 28745: 28745: 28745: initialize program: red-carpet 28745: 28745: 28745: transferring control: red-carpet 28745: 28745: file=libnss_files.so.2; generating link map 28745: dynamic: 0x4002c010 base: 0x40023000 size: 0x000093d8 28745: entry: 0x40024d00 phdr: 0x40023034 phnum: 6 28745: 28745: 28745: calling init: /lib/libnss_files.so.2 28745: 28745: opening file=/lib/libnss_files.so.2; opencount == 1 28745: 28745: file=/usr/lib/gconv/ISO8859-1.so; generating link map 28745: dynamic: 0x40061010 base: 0x40060000 size: 0x0000112c 28745: entry: 0x400606a0 phdr: 0x40060034 phnum: 4 28745: 28745: 28745: calling init: /usr/lib/gconv/ISO8859-1.so 28745: 28745: opening file=/usr/lib/gconv/ISO8859-1.so; opencount == 1 28745: red-carpet: relocation error: red-carpet: symbol _dl_catch_error, version GLIBC_2.0 not defined in file ld-linux.so.2 with link time reference All the files in the debug output are owned by the glibc package, according to rpm, and rpm -V glibc comes out clean.
Can you please run: ls -l /lib/i686 readelf -s /lib/i686/libc.so.6 | grep _dl_catch_error ? glibc-2.2.5-27+ definitely shouldn't show GLIBC_2.0 but GLIBC_PRIVATE. On my box everything looks ok btw.
Red Carpet doesn't directly call any of the dl* functions, but uses glib 1.2's module loading functions. In glibc-2.2.4-19.3 this was GLIBC_2.0, so maybe something is still calling it because a macro changed? just a guess. [pzb@gargleblaster pzb]$ ls -l /lib/i686 total 1656 -rwxr-xr-x 1 root root 1401050 Mar 27 21:37 libc-2.2.5.so lrwxrwxrwx 1 root root 13 Mar 29 09:37 libc.so.6 -> libc-2.2.5.so -rwxr-xr-x 1 root root 173487 Mar 27 21:37 libm-2.2.5.so lrwxrwxrwx 1 root root 13 Mar 29 09:37 libm.so.6 -> libm-2.2.5.so -rwxr-xr-x 1 root root 101902 Mar 27 21:37 libpthread-0.9.so lrwxrwxrwx 1 root root 17 Mar 29 09:37 libpthread.so.0 -> libpthread-0.9.so [pzb@gargleblaster pzb]$ readelf -s /lib/i686/libc.so.6 | grep _dl_catch_error 1481: 00000000 331 FUNC GLOBAL DEFAULT UND _dl_catch_error@GLIBC_PRIVATE (14) 3860: 00000000 331 FUNC GLOBAL DEFAULT UND _dl_catch_error@@GLIBC_PR
Isn't their a guarantee of binary compability within a major verion? This code was compiled on 7.2 and does not directly make any direct calls to private glibc functions. Any calls are made from system libraries, some of which are statically compiled into red carpet.
There is binary compatibility for programs using the supported interface (which does not include and never included _dl_catch_error). Just downloaded red-carpet, the problem is that Ximian doesn't know how to link binaries properly. They link -ldl statically in, but link dynamically -lc, which was never supported.