From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from lists.gentoo.org ([140.105.134.102] helo=robin.gentoo.org) by nuthatch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1GaIuQ-0003ft-O0 for garchives@archives.gentoo.org; Wed, 18 Oct 2006 21:25:07 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.8/8.13.6) with SMTP id k9ILM4EZ009787; Wed, 18 Oct 2006 21:22:04 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.8/8.13.6) with ESMTP id k9ILM3Qg014594 for ; Wed, 18 Oct 2006 21:22:04 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1GaIrG-0006cu-Lj for gentoo-amd64@lists.gentoo.org; Wed, 18 Oct 2006 23:21:52 +0200 Received: from ip68-230-97-209.ph.ph.cox.net ([68.230.97.209]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 23:21:50 +0200 Received: from 1i5t5.duncan by ip68-230-97-209.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Wed, 18 Oct 2006 23:21:50 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: "Duncan" <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: -fPIC - Toolchain broken? Date: Wed, 18 Oct 2006 21:21:41 +0000 (UTC) Message-ID: References: <45364363.3010601@getdesigned.at> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-209.ph.ph.cox.net User-Agent: pan 0.117 (Old Rip Van Winkle) Sender: news X-Archives-Salt: b2619594-8c97-43bc-b9e2-dbec0f45de63 X-Archives-Hash: 77d73583570212ff14aa8b4dee7ba114 Sebastian Redl 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