Bug 62279 - relocation error
relocation error
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: glibc (Show other bugs)
7.3
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jakub Jelinek
Brian Brock
:
Depends On:
Blocks: 61901
  Show dependency treegraph
 
Reported: 2002-03-28 21:02 EST by Peter Bowen
Modified: 2016-11-24 10:21 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-04-01 15:30:17 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)

  None (edit)
Description Peter Bowen 2002-03-28 21:02:12 EST
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.
Comment 1 Jakub Jelinek 2002-03-29 04:29:01 EST
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.
Comment 2 Peter Bowen 2002-03-29 07:59:41 EST
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.
Comment 3 Jakub Jelinek 2002-03-29 15:29:36 EST
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.
Comment 4 Peter Bowen 2002-03-29 15:54:57 EST
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
Comment 5 Peter Bowen 2002-04-01 15:30:09 EST
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.
Comment 6 Jakub Jelinek 2002-04-04 06:35:35 EST
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.

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