Bug 62279

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.