Shared library relocation R_X86_64_32 solution on amd64?

[Kris Kennaway]

On Wed, Apr 27, 2005 at 10:23:39AM +0100, Michael Hopkins wrote:
> 
> 
> Hi all
> 
> I have been doing some research about why gnustep-base won't link on amd64.
> It seems as if the problem I am getting here is quite common.
> ------------------------------------------------------------------------
> gmake[1]: Leaving directory
> `/usr/home/mwh/Coding/Obj-C/gnustep/core/base/Source'
> Making all in SSL...
> gmake[1]: Entering directory
> `/usr/home/mwh/Coding/Obj-C/gnustep/core/base/SSL'
> Making all for bundle SSL...
>  Creating SSL.bundle/amd64/freebsd/gnu-gnu-gnu...
>  Compiling file GSSSLHandle.m ...
>  Linking bundle SSL ...
> /usr/bin/ld: /usr/lib/libobjc.a(Protocol.o): relocation R_X86_64_32 can not
> be used when making a shared object; recompile with -fPIC
> /usr/lib/libobjc.a: could not read symbols: Bad value
> gmake[2]: *** [SSL.bundle/amd64/freebsd/gnu-gnu-gnu/SSL] Error 1
> gmake[1]: *** [SSL.all.bundle.variables] Error 2
> gmake[1]: Leaving directory
> `/usr/home/mwh/Coding/Obj-C/gnustep/core/base/SSL'
> gmake: *** [internal-all] Error 2
> ------------------------------------------------------------------------
> 
> 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.

> continue.
> 
> 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, so you should talk to
kan at .

> 2) What is the standard method for dealing with this problem on amd64?  I'm
> 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".

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/09306b2e/attachment.bin