[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gentoo-amd64
Subject:    Re: [gentoo-amd64] I was wrong Was: dev-util/devhelp-0.21 emerge fails
From:       Beso <givemesugarr () gmail ! com>
Date:       2008-12-13 17:13:31
Message-ID: d257c3560812130913rdfdda50rafad3134f264f721 () mail ! gmail ! com
[Download RAW message or body]

2008/12/13 Duncan <1i5t5.duncan@cox.net>:
> Duncan <1i5t5.duncan@cox.net> posted pan.2008.12.04.00.02.27@cox.net,
> excerpted below, on  Thu, 04 Dec 2008 00:02:27 +0000:
>
>>> .libs/libdevhelp_1_la-Yelper.o: relocation R_X86_64_PC32 against symbol
>>> `gtk_moz_embed_get_nsIWebBrowser' can not be used when making a shared
>>> object; recompile with -fPIC
>>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/
>> bin/ld:
>>> final link failed: Bad value collect2: ld returned 1 exit status
>>
>> Well, that seems to have gotten you further, and the error is clearer
>> now.
>>
>>> relocation R_X86_64_PC32
>>
>> An error of that nature shows it's trying to link 32-bit code into a 64-
>> bit binary.  That's not going to work.  Somehow, you need to get it to
>> see the 64-bit version and use it instead of the 32-bit version, but
>> that's beyond my ability to solve.
>
> I thought I better get this right up there in the subject, in case
> anybody had depended on what I said.  So as it says, I was wrong.
>
> The relocation R_X86_64_PC32 error is not 32-bit related as I stated, but
> rather shared-lib/static-lib related.  On amd64 in 64-bit mode, shared
> libs (*.so*) must be relocatable code, while executables and the static
> libs (*.a) linked into them may remain fixed address.  (But, and this is
> how I discovered my error, static libs linked into shared objects must be
> relocatable as well.  I ran into this with the new amarok-2.0 ebuild,
> which has a *.so plugin linked against a static lib *.a from mysql...
> doesn't work under normal conditions, the reason amarok-2 isn't keyworded
> ~amd64 yet.)
>
> As the error states, the object being linked into the shared-object must
> be compiled with -fPIC.  Normally, the make files should take care of
> this, but occasionally they fail, or as in my problem above, there's an
> attempt made to link normal static libs into shared objects.
>
> I had the wrong impression as I'd not run into the error since I had
> switched to no-multilib, and with the 32 in there, I (wrongly) assumed it
> was tied into 32-bit.  Oops!
>
> But, I was still right on the above my ability to solve bit, at least
> unless you want to compile the offending bit with -fPIC, but adding it
> just to that bit requires intimate knowledge of make and etc, and adding
> it to other code in the same ebuild will slow any code in static
> libraries and executables (as opposed to the shared objects that require
> it) down, so while a quick recompile with -fPIC can help temporarily,
> getting the devs to look at it and fix it properly is the correct
> solution.
>
for mysql the fix is quite simple: add -fPIC to the cflags in the
portage mysql.eclass.
this would force -fPIC for it. if you want to do things better you
could add a simple
case probing for the compiler and forcing the -fPIC for mysql only on amd64.
this -fPIC issue of amarok has been pointed out when amarok 2 has gone
to the first
alpha release, if i recall well. the strange thing is that mysql
makefile doesn't really
seem to intend to use -fPIC. i don't really know why this issue with a
so widely
spread package.

-- 
dott. ing. beso

[prev in list] [next in list] [prev in thread] [next in thread]