Date: Wed, 27 Apr 2005 13:29:00 -0700 From: Kris Kennaway <kris@obsecurity.org> To: Michael Hopkins <michael.hopkins@hopkins-research.com> Cc: Kris Kennaway <kris@obsecurity.org> Subject: Re: Shared library relocation R_X86_64_32 solution on amd64? Message-ID: <20050427202900.GA52508@xor.obsecurity.org> In-Reply-To: <BE95A8E3.38FDB%michael.hopkins@hopkins-research.com> References: <20050427192112.GA30646@xor.obsecurity.org> <BE95A8E3.38FDB%michael.hopkins@hopkins-research.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--jI8keyz6grp/JLjh Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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 th= is > >> issue is that you can't link to shared libraries unless they have been > >> compiled with -fPIC. Is that right? > >=20 > > Yes, and libobjc.a isn't a shared library, so you can't link it into on= e. > >=20 > 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. > >>=20 > >> 1) What installs libobjc.a? I want to reinstall it with CFLAGS +=3D -= fPIC. I > >> assumed that it was installed by gcc-objc but after reinstalling that = with > >> -fPIC the libobjc.a library was untouched! > >=20 > > 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, >=20 > 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 (relocatable) libraries). > > so you should talk to > > kan@. > >=20 > Does this mean kan@freebsd.org? I have copied to that address in case. Yes. > >> 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 wi= th > >> this? > >=20 > > Well, yeah, there is a proper strategy. "Link shared objects to > > shared libraries". > >=20 > Did you see that the simlar earlier problem was solved by rebuilding ffca= ll > with -fPIC? I don't think libcallback.a is a shared library either but t= he > 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: >=20 > 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. Kris --jI8keyz6grp/JLjh Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (FreeBSD) iD8DBQFCb/YLWry0BWjoQKURAvHhAKCLMs8OZFcGARhs9Ca91LFHKsLLIgCfexLJ b1FDR0x/FaJIvEoAW+dWuzw= =SfdC -----END PGP SIGNATURE----- --jI8keyz6grp/JLjh--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050427202900.GA52508>