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