From owner-freebsd-amd64@FreeBSD.ORG Wed Apr 27 19:39:06 2005 Return-Path: Delivered-To: freebsd-amd64@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 4259C16A4CE; Wed, 27 Apr 2005 19:39:06 +0000 (GMT) Received: from neon.webfusion.co.uk (neon.webfusion.co.uk [212.67.202.39]) by mx1.FreeBSD.org (Postfix) with ESMTP id AC9B643D39; Wed, 27 Apr 2005 19:39:05 +0000 (GMT) (envelope-from michael.hopkins@hopkins-research.com) Received: from 83-216-132-201.markch725.adsl.metronet.co.uk ([83.216.132.201] helo=[192.168.0.5]) by neon.webfusion.co.uk with asmtp (Exim 3.36 #1) id 1DQsND-0001bm-00; Wed, 27 Apr 2005 20:39:03 +0100 User-Agent: Microsoft-Entourage/10.1.1.2418 Date: Wed, 27 Apr 2005 20:38:59 +0100 From: Michael Hopkins To: Kris Kennaway Message-ID: In-Reply-To: <20050427192112.GA30646@xor.obsecurity.org> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit cc: kan@freebsd.org cc: "freebsd-amd64@freebsd.org" Subject: Re: Shared library relocation R_X86_64_32 solution on amd64? X-BeenThere: freebsd-amd64@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the AMD64 platform List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Apr 2005 19:39:06 -0000 On 27/4/05 8:21 pm, "Kris Kennaway" 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' _/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/