1 |
Duncan <1i5t5.duncan@×××.net> posted pan.2008.12.04.00.02.27@×××.net, |
2 |
excerpted below, on Thu, 04 Dec 2008 00:02:27 +0000: |
3 |
|
4 |
>> .libs/libdevhelp_1_la-Yelper.o: relocation R_X86_64_PC32 against symbol |
5 |
>> `gtk_moz_embed_get_nsIWebBrowser' can not be used when making a shared |
6 |
>> object; recompile with -fPIC |
7 |
>> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu/ |
8 |
> bin/ld: |
9 |
>> final link failed: Bad value collect2: ld returned 1 exit status |
10 |
> |
11 |
> Well, that seems to have gotten you further, and the error is clearer |
12 |
> now. |
13 |
> |
14 |
>> relocation R_X86_64_PC32 |
15 |
> |
16 |
> An error of that nature shows it's trying to link 32-bit code into a 64- |
17 |
> bit binary. That's not going to work. Somehow, you need to get it to |
18 |
> see the 64-bit version and use it instead of the 32-bit version, but |
19 |
> that's beyond my ability to solve. |
20 |
|
21 |
I thought I better get this right up there in the subject, in case |
22 |
anybody had depended on what I said. So as it says, I was wrong. |
23 |
|
24 |
The relocation R_X86_64_PC32 error is not 32-bit related as I stated, but |
25 |
rather shared-lib/static-lib related. On amd64 in 64-bit mode, shared |
26 |
libs (*.so*) must be relocatable code, while executables and the static |
27 |
libs (*.a) linked into them may remain fixed address. (But, and this is |
28 |
how I discovered my error, static libs linked into shared objects must be |
29 |
relocatable as well. I ran into this with the new amarok-2.0 ebuild, |
30 |
which has a *.so plugin linked against a static lib *.a from mysql... |
31 |
doesn't work under normal conditions, the reason amarok-2 isn't keyworded |
32 |
~amd64 yet.) |
33 |
|
34 |
As the error states, the object being linked into the shared-object must |
35 |
be compiled with -fPIC. Normally, the make files should take care of |
36 |
this, but occasionally they fail, or as in my problem above, there's an |
37 |
attempt made to link normal static libs into shared objects. |
38 |
|
39 |
I had the wrong impression as I'd not run into the error since I had |
40 |
switched to no-multilib, and with the 32 in there, I (wrongly) assumed it |
41 |
was tied into 32-bit. Oops! |
42 |
|
43 |
But, I was still right on the above my ability to solve bit, at least |
44 |
unless you want to compile the offending bit with -fPIC, but adding it |
45 |
just to that bit requires intimate knowledge of make and etc, and adding |
46 |
it to other code in the same ebuild will slow any code in static |
47 |
libraries and executables (as opposed to the shared objects that require |
48 |
it) down, so while a quick recompile with -fPIC can help temporarily, |
49 |
getting the devs to look at it and fix it properly is the correct |
50 |
solution. |
51 |
|
52 |
-- |
53 |
Duncan - List replies preferred. No HTML msgs. |
54 |
"Every nonfree program has a lord, a master -- |
55 |
and if you use the program, he is your master." Richard Stallman |