From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([69.77.167.62] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1LBWqA-0002NE-DM for garchives@archives.gentoo.org; Sat, 13 Dec 2008 15:55:38 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id D369BE003C; Sat, 13 Dec 2008 15:55:36 +0000 (UTC) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by pigeon.gentoo.org (Postfix) with ESMTP id 9256BE003C for ; Sat, 13 Dec 2008 15:55:36 +0000 (UTC) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1LBWq7-0008LB-9p for gentoo-amd64@lists.gentoo.org; Sat, 13 Dec 2008 15:55:35 +0000 Received: from ip68-230-99-190.ph.ph.cox.net ([68.230.99.190]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Dec 2008 15:55:30 +0000 Received: from 1i5t5.duncan by ip68-230-99-190.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sat, 13 Dec 2008 15:55:30 +0000 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] I was wrong Was: dev-util/devhelp-0.21 emerge fails Date: Sat, 13 Dec 2008 15:55:23 +0000 (UTC) Message-ID: References: <49368849.4050803@asyr.hopto.org> <4936D6A1.9030002@asyr.hopto.org> Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-amd64@lists.gentoo.org Reply-to: gentoo-amd64@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-99-190.ph.ph.cox.net User-Agent: Pan/0.133 (House of Butterflies) Sender: news Content-Transfer-Encoding: quoted-printable X-Archives-Salt: 08efa877-c07a-406e-a9ef-beb35d22a025 X-Archives-Hash: af40d02a503c02b3ea93ca91a471d095 Duncan <1i5t5.duncan@cox.net> posted pan.2008.12.04.00.02.27@cox.net, excerpted below, on Thu, 04 Dec 2008 00:02:27 +0000: >> .libs/libdevhelp_1_la-Yelper.o: relocation R_X86_64_PC32 against symbo= l >> `gtk_moz_embed_get_nsIWebBrowser' can not be used when making a shared >> object; recompile with -fPIC >> /usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/../../../../x86_64-pc-linux-gnu= / > bin/ld: >> final link failed: Bad value collect2: ld returned 1 exit status >=20 > Well, that seems to have gotten you further, and the error is clearer > now. >=20 >> relocation R_X86_64_PC32 >=20 > An error of that nature shows it's trying to link 32-bit code into a 64= - > bit binary. That's not going to work. Somehow, you need to get it to > see the 64-bit version and use it instead of the 32-bit version, but > that's beyond my ability to solve. I thought I better get this right up there in the subject, in case=20 anybody had depended on what I said. So as it says, I was wrong. The relocation R_X86_64_PC32 error is not 32-bit related as I stated, but= =20 rather shared-lib/static-lib related. On amd64 in 64-bit mode, shared=20 libs (*.so*) must be relocatable code, while executables and the static=20 libs (*.a) linked into them may remain fixed address. (But, and this is=20 how I discovered my error, static libs linked into shared objects must be= =20 relocatable as well. I ran into this with the new amarok-2.0 ebuild,=20 which has a *.so plugin linked against a static lib *.a from mysql...=20 doesn't work under normal conditions, the reason amarok-2 isn't keyworded= =20 ~amd64 yet.) As the error states, the object being linked into the shared-object must=20 be compiled with -fPIC. Normally, the make files should take care of=20 this, but occasionally they fail, or as in my problem above, there's an=20 attempt made to link normal static libs into shared objects. I had the wrong impression as I'd not run into the error since I had=20 switched to no-multilib, and with the 32 in there, I (wrongly) assumed it= =20 was tied into 32-bit. Oops! But, I was still right on the above my ability to solve bit, at least=20 unless you want to compile the offending bit with -fPIC, but adding it=20 just to that bit requires intimate knowledge of make and etc, and adding=20 it to other code in the same ebuild will slow any code in static=20 libraries and executables (as opposed to the shared objects that require=20 it) down, so while a quick recompile with -fPIC can help temporarily,=20 getting the devs to look at it and fix it properly is the correct=20 solution. --=20 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