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

List:       gentoo-amd64
Subject:    [gentoo-amd64]  I was wrong  Was: dev-util/devhelp-0.21 emerge fails
From:       Duncan <1i5t5.duncan () cox ! net>
Date:       2008-12-13 15:55:23
Message-ID: pan.2008.12.13.15.55.23 () cox ! net
[Download RAW message or body]

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman


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