This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Defined symbols requiring an other library
- From: Kurt Roeckx <kurt at roeckx dot be>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 10 Jan 2008 01:45:06 +0100
- Subject: Re: Defined symbols requiring an other library
- References: <m38x2z7yk8.fsf@redhat.com>
On Wed, Jan 09, 2008 at 04:28:55PM +0000, Nick Clifton wrote:
> Hi Kurt,
>
> > Does anybody know if there will be other things that might be a problem
> > we have doing this?
>
> I suspect that you might encounter similar problems with dynamic relocs for
> other targets, not just the COPY reloc. (I do not have proof of this, but it
> seems reasonable, since ABIs vary from target to target).
>
> > Or is there a better of doing this?
>
> Wouldn't it be easier to use the loader to resolve this problem for you ? ie
> have the loader perform a dry run and tell you exactly where it found all the
> symbols ? (You may need to add code to the loader in order to do this, or you
> may be able to use a tool like strace or systemtap). Or you could look at the
> prelinker and possibly parse prelinked binaries ? (The point being that these
> tools already know how to resolve dynamic relocs and find libraries, so why not
> make use of them).
Atleast prelink is not very portable. It only seems to be available on:
Architecture: alpha amd64 i386 powerpc ppc64
systemtap has a simular problem:
Architecture: i386 amd64 ia64 s390 powerpc arm armel armeb
Changing the dynamic loader might be a good way to do this.
Kurt