1i5t5.duncan at cox
Dec 13, 2008, 7:55 AM
Post #1 of 2
(574 views)
Permalink
|
|
I was wrong Was: dev-util/devhelp-0.21 emerge fails
|
|
Duncan <1i5t5.duncan [at] cox> posted pan.2008.12.04.00.02.27 [at] cox,
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
|
