Date: Wed, 27 Apr 2005 20:38:59 +0100 From: Michael Hopkins <michael.hopkins@hopkins-research.com> To: Kris Kennaway <kris@obsecurity.org> Cc: "freebsd-amd64@freebsd.org" <freebsd-amd64@freebsd.org> Subject: Re: Shared library relocation R_X86_64_32 solution on amd64? Message-ID: <BE95A8E3.38FDB%michael.hopkins@hopkins-research.com> In-Reply-To: <20050427192112.GA30646@xor.obsecurity.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 27/4/05 8:21 pm, "Kris Kennaway" <kris@obsecurity.org> 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@.
>
Does this mean kan@freebsd.org? 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
Michael
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
_/ _/ _/_/_/ Hopkins Research Ltd
_/ _/ _/ _/
_/_/_/_/ _/_/_/ http://www.hopkins-research.com/
_/ _/ _/ _/
_/ _/ _/ _/ 'touch the future'
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?BE95A8E3.38FDB%michael.hopkins>