Shared library relocation R_X86_64_32 solution on amd64?

Michael Hopkins michael.hopkins at
Wed Apr 27 12:39:06 PDT 2005

On 27/4/05 8:21 pm, "Kris Kennaway" <kris at> wrote:

> On Wed, Apr 27, 2005 at 10:23:39AM +0100, Michael Hopkins wrote:
>> 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.
>> ------------------------------------------------------------------------
>> 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.
Do you know why this problem appears to be specific to amd64?

>> 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.

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

>> 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".
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.

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?

> Kris
Thanks for the input



        _/    _/   _/_/_/             Hopkins Research Ltd
       _/    _/   _/    _/
      _/_/_/_/   _/_/_/
     _/    _/   _/   _/
    _/    _/   _/     _/               'touch the future'

More information about the freebsd-amd64 mailing list