Shared library relocation R_X86_64_32 solution on amd64?

Kris Kennaway kris at obsecurity.org
Wed Apr 27 13:29:01 PDT 2005


On Wed, Apr 27, 2005 at 08:38:59PM +0100, Michael Hopkins wrote:

> >> It has been mentioned a few times on this list: my understanding of this
> >> issue is that you can't link to shared libraries unless they have been
> >> compiled with -fPIC.  Is that right?
> > 
> > Yes, and libobjc.a isn't a shared library, so you can't link it into one.
> > 
> Do you know why this problem appears to be specific to amd64?

It's not, ia64 and sparc64 have similar requirements.

> >> I have two main questions in this post.
> >> 
> >> 1) What installs libobjc.a?  I want to reinstall it with CFLAGS += -fPIC. I
> >> assumed that it was installed by gcc-objc but after reinstalling that with
> >> -fPIC the libobjc.a library was untouched!
> > 
> > Since it's in /usr/lib, it's part of the base system.  We don't seem
> > to install a shared library version of that,
> 
> I may have been creating a red herring when I said it needed to link to a
> shared library.  I think the actual issue is linking any kind of amd64
> library which hasn't been made with -fPIC into another shared library - I
> await clarification from others who know better about these things.

Yeah, by definition you should only be using -fPIC with shared
(relocatable) libraries).

> > so you should talk to
> > kan at .
> > 
> Does this mean kan at freebsd.org?  I have copied to that address in case.

Yes.

> >> sure it will hit a lot of people on many different ports and if it's a tier
> >> 1 platform then don't we need to have a proper strategy for dealing with
> >> this?
> > 
> > Well, yeah, there is a proper strategy.  "Link shared objects to
> > shared libraries".
> > 
> Did you see that the simlar earlier problem was solved by rebuilding ffcall
> with -fPIC?  I don't think libcallback.a is a shared library either but the
> link was made possible by the rebuild.

You generally shouldn't be compiling static (.a) libraries with -fPIC
because this causes performance penalities for applications that
really want to link statically with them.

> I am still not completely clear whether the cause of this problem is:
> 
>  1) the GNUstep source code
>  2) the GNUstep makefile
>  3) the FreeBSD amd64 default library setup
>  4) the FreeBSD amd64 'linking logic'
>  5) something else?

For the error above, it looks like at least 3) (i.e. FreeBSD should
provide a libobjc.so).  Whether or not gnustep will use it, or if
there are further problems, I can't say.

Kris
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-amd64/attachments/20050427/e153d422/attachment.bin


More information about the freebsd-amd64 mailing list