[gentoo-amd64] Re: -fPIC - Toolchain broken?

["Duncan" <1i5t5.duncan@cox.net>]

Sebastian Redl <sebastian.redl@getdesigned.at> posted
45364363.3010601@getdesigned.at, excerpted below, on  Wed, 18 Oct 2006
17:08:19 +0200:

> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> warning: creating a DT_TEXTREL in object.
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> ucol_wgt.o: relocation R_X86_64_PC32 against `compareRanges' can not be
> used when making a shared object; recompile with -fPIC
> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
> final link failed: Bad value
> collect2: ld returned 1 exit status
> 
> Normally, that would simply indicate that a source file was compiled
> without -fPIC, which is wrong. However, that's not the case here: manual
> checking of the compiler command lines of all previous sources shows that
> they were all, in fact, compiled with -fPIC and -DPIC.
> 
> I even manually removed the previously built libraries (libicudata.so and
> libicuuc.so) and relinked them with -fPIC, although I don't even know
> whether the flag has any influence on linking. Same error.
> 
> I have the same problem when manually trying to compile any Mozilla-based
> application. However, most programs and libraries build fine - I just
> finished merging KOffice without any problems.

I see the specifics of this are being investigated, but here's some
general comments, which hopefully prove enlightening.  =8^)  I think I
wrote about this a few days ago, but for those that may have missed it...

-fPIC is an interesting beast.  It's required on amd64 for all shared
objects (*.so*), but isn't recommended (except for hardened) for
application binaries, both due to occasional unexpected complications and
because it's slower.  Thus, putting it in CFLAGS is NOT a good thing,
unless it's for a specific library package only, to get it to merge while
you are waiting for the bug you filed on it (right?) to get
researched/fixed/tested.

HOWEVER, and a big HOWEVER this can be, just because the error says -fPIC
doesn't NECESSARILY mean that's got anything to do with the real problem. 
The situation is often the following.  During the configure step, some of
the various tests involve compiling tiny stub programs and seeing if they
compile correctly with the option being tested.  The problem is that
sometimes what is being tested doesn't always return a gcc error, only a
gcc warning.  If that's the case, the test often simply checks for a
warning, not WHAT the warning was.  Apparently, the -fPIC test is one such
test-for-warning-only test, so if gcc throws a warning of some kind for
ANY reason during that test, it'll often cause the configure script to
believe that -fPIC doesn't work on the platform, when in fact on our
platform it's required, for libraries/shared-objects anyway!  Obviously,
this WILL cause problems.

One of the most common causes here is warning triggering CFLAGS, such as
those that might have been configured for a different version of gcc, that
the current version doesn't recognize.  In fact, this is /so/ common a
problem, that the Gentoo amd64 team came up with a normally workable if
not 100% solution -- use the profile bashrc script to test for
unrecognized flags and eliminate them automatically.  This apparently
reduced the false bug reports due to stale CFLAGS substantially, but the
script is just that, and doesn't test all possible cases as doing so
would be "complex", and besides, there are other ways to trigger a warning
as well.

So... anytime I see this error, the first thing I try is flipping some
CFLAGS on and off, and see if there's a reasonable combination that works.
 Only if that fails do I try -fPIC and bug it as necessary.

-- 
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

-- 
gentoo-amd64@gentoo.org mailing list