1 |
Sebastian Redl <sebastian.redl@×××××××××××.at> posted |
2 |
45364363.3010601@×××××××××××.at, excerpted below, on Wed, 18 Oct 2006 |
3 |
17:08:19 +0200: |
4 |
|
5 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: |
6 |
> warning: creating a DT_TEXTREL in object. |
7 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: |
8 |
> ucol_wgt.o: relocation R_X86_64_PC32 against `compareRanges' can not be |
9 |
> used when making a shared object; recompile with -fPIC |
10 |
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld: |
11 |
> final link failed: Bad value |
12 |
> collect2: ld returned 1 exit status |
13 |
> |
14 |
> Normally, that would simply indicate that a source file was compiled |
15 |
> without -fPIC, which is wrong. However, that's not the case here: manual |
16 |
> checking of the compiler command lines of all previous sources shows that |
17 |
> they were all, in fact, compiled with -fPIC and -DPIC. |
18 |
> |
19 |
> I even manually removed the previously built libraries (libicudata.so and |
20 |
> libicuuc.so) and relinked them with -fPIC, although I don't even know |
21 |
> whether the flag has any influence on linking. Same error. |
22 |
> |
23 |
> I have the same problem when manually trying to compile any Mozilla-based |
24 |
> application. However, most programs and libraries build fine - I just |
25 |
> finished merging KOffice without any problems. |
26 |
|
27 |
I see the specifics of this are being investigated, but here's some |
28 |
general comments, which hopefully prove enlightening. =8^) I think I |
29 |
wrote about this a few days ago, but for those that may have missed it... |
30 |
|
31 |
-fPIC is an interesting beast. It's required on amd64 for all shared |
32 |
objects (*.so*), but isn't recommended (except for hardened) for |
33 |
application binaries, both due to occasional unexpected complications and |
34 |
because it's slower. Thus, putting it in CFLAGS is NOT a good thing, |
35 |
unless it's for a specific library package only, to get it to merge while |
36 |
you are waiting for the bug you filed on it (right?) to get |
37 |
researched/fixed/tested. |
38 |
|
39 |
HOWEVER, and a big HOWEVER this can be, just because the error says -fPIC |
40 |
doesn't NECESSARILY mean that's got anything to do with the real problem. |
41 |
The situation is often the following. During the configure step, some of |
42 |
the various tests involve compiling tiny stub programs and seeing if they |
43 |
compile correctly with the option being tested. The problem is that |
44 |
sometimes what is being tested doesn't always return a gcc error, only a |
45 |
gcc warning. If that's the case, the test often simply checks for a |
46 |
warning, not WHAT the warning was. Apparently, the -fPIC test is one such |
47 |
test-for-warning-only test, so if gcc throws a warning of some kind for |
48 |
ANY reason during that test, it'll often cause the configure script to |
49 |
believe that -fPIC doesn't work on the platform, when in fact on our |
50 |
platform it's required, for libraries/shared-objects anyway! Obviously, |
51 |
this WILL cause problems. |
52 |
|
53 |
One of the most common causes here is warning triggering CFLAGS, such as |
54 |
those that might have been configured for a different version of gcc, that |
55 |
the current version doesn't recognize. In fact, this is /so/ common a |
56 |
problem, that the Gentoo amd64 team came up with a normally workable if |
57 |
not 100% solution -- use the profile bashrc script to test for |
58 |
unrecognized flags and eliminate them automatically. This apparently |
59 |
reduced the false bug reports due to stale CFLAGS substantially, but the |
60 |
script is just that, and doesn't test all possible cases as doing so |
61 |
would be "complex", and besides, there are other ways to trigger a warning |
62 |
as well. |
63 |
|
64 |
So... anytime I see this error, the first thing I try is flipping some |
65 |
CFLAGS on and off, and see if there's a reasonable combination that works. |
66 |
Only if that fails do I try -fPIC and bug it as necessary. |
67 |
|
68 |
-- |
69 |
Duncan - List replies preferred. No HTML msgs. |
70 |
"Every nonfree program has a lord, a master -- |
71 |
and if you use the program, he is your master." Richard Stallman |
72 |
|
73 |
-- |
74 |
gentoo-amd64@g.o mailing list |