Re: compatibility libraries.

[Paul Pluzhnikov]

Amit Bhatia <bhatia2@nospam.com> writes:

> The following is what gdb gives me:
> 
> Program received signal SIGSEGV, Segmentation fault.
> 0x0857abde in _dl_relocate_object ()

One of the most imporatant commands in gdb is 'where' or 'backtrace'
Unfortunately you didn't execute that command ...

> does it mean anything very obvious? I can't understand it except for the
> fact that some kind of signal was received.(?)

Yes: the executable is apparently built statically. 

What doesn 'ldd exename' say?

If it says: "not a dynamic executable", then you need to tell
whoever made this exe that they are nuts, that statically linking
executables is *extermely* bad idea, not guaranteed to work even
across subminor OS/glibc revisions, and that you want a dynamically
linked one instead.

If 'ldd exename' says something like this:

        libc.so.6 => /lib/libc.so.6 (0x40022000)
        /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000)

then you don't have a static exe, but somehow  _dl_relocate_object()
(which is supposed to be defined only in /lib/ld-linux.so.2) also got
defined in the executable itself. You can verify this with:

  nm exename | grep _dl_relocate_object

I can't think of any way to achieve that, other than by static linking,
but perhaps the maintainers have invented a way. Ask them how this
executable was built, and how did the _dl_relocate_object() end up
in the main executable.

The primary cause of the crash is a mismatch between ld-linux.so.2
(which somehow got linked into the main exe), and glibc installed on
the system. These 2 binaries form a very tightly bound package,
and any version mismatch between them will cause numerous problems.

Cheers,
-- 
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.