Shared library relocation R_X86_64_32 solution on amd64?
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
> > so you should talk to
> > kan at .
> Does this mean kan at freebsd.org? I have copied to that address in case.
> >> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
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