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.43) id 1E10Gd-00054V-H8 for garchives@archives.gentoo.org; Fri, 05 Aug 2005 11:21:35 +0000 Received: from robin.gentoo.org (localhost [127.0.0.1]) by robin.gentoo.org (8.13.4/8.13.4) with SMTP id j75BJCcY032271; Fri, 5 Aug 2005 11:19:12 GMT Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by robin.gentoo.org (8.13.4/8.13.4) with ESMTP id j75BJC89003917 for ; Fri, 5 Aug 2005 11:19:12 GMT Received: from list by ciao.gmane.org with local (Exim 4.43) id 1E10Eg-0006x9-92 for gentoo-amd64@lists.gentoo.org; Fri, 05 Aug 2005 13:19:34 +0200 Received: from ip68-230-97-182.ph.ph.cox.net ([68.230.97.182]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Aug 2005 13:19:34 +0200 Received: from 1i5t5.duncan by ip68-230-97-182.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Fri, 05 Aug 2005 13:19:34 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-amd64@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-amd64] Re: broken (32bit) glibc ? Date: Fri, 05 Aug 2005 04:17:41 -0700 Organization: Sometimes Message-ID: References: <1123237235.11188.36.camel@echelon.zagamma.vpn> 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=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: ip68-230-97-182.ph.ph.cox.net User-Agent: Pan/0.14.2.91 (As She Crawled Across the Table) Sender: news X-Archives-Salt: 3bc58119-5bfc-4be9-a42a-c921aa5a2617 X-Archives-Hash: 985657f6225b7a4d63461bd51e463d86 ViNiL posted <1123237235.11188.36.camel@echelon.zagamma.vpn>, excerpted below, on Fri, 05 Aug 2005 12:20:35 +0200: > After upgrading glibc to 2.3.5-r1, I am no longer able to run 32bit > binaries. The error is: "Accessing a corrupted shared library" I guess the > 32bit linker is broken (is it ok if this file is stripped?) > > What's more. I cannot compile any other glibc, now. It ends with: > configure: error: cannot compute sizeof (long double), 77 ./conftest: > Accessing a corrupted shared library > > I have 32bit emul enabled in kernel. First, try the FEATURES=-sandbox, emerge gcc, if you haven't done so yet. Sometimes it's a corrupt 32-bit sandbox, not glibc or whatever. Still, I had the same error with the glibc snapshot masked for testing by those running gcc4, and -sandbox wouldn't fix it here. You've been using FEATURES=buildpkg, right? That's been recommended here (by your's truly) several times. Assuming so, simply emerge --packageonly =glibc-2.3.5, and it'll emerge that version from the binpkg you created due to that feature, and you'll be back in business. That's what I did when I had the same problem with the mask-for-testing-with-gcc4 glibc snapshot, as mentioned above, perhaps six weeks ago. That got me back the old, known working in both 32-bit and 64-bit ABI, package. Or... copy over the versions from your emergency boot partitions. You /do/ have a root-mirror partition as a backup in case your root partition goes bye-bye, right? (I have three backups here, a rootmirror on my main disk, and a working copy and backup on my backup disk, as well, altho I must admit, they are rather old snapshots, now, and I'm afraid fixing such a problem here might not be quite as easy as copying them over, ATM, due to the age, 2004.something.) If not, look up the 2004.1 -> 2005.0 upgrade instructions. That had a URL to a binary version, IIRC, that one installed as part of the upgrade procedure, then used to rebuild one locally that had both the 32-bit and 64-bit ABIs activated. One should be able to install that, then rebuild one locally, just as one would do if performing the upgrade. Barring that, you could try copying over the binaries from the 2005.0 stages or LiveCD. Note that this could be a bit more difficult, given you'd have to copy over individual files and get the right ones. None-the-less, it should be possible, using equery list on your currently merged package to get or guess the 32-bit files needed. Or, alternatively, if you trust me, I can mail you a copy of my binpkg, as my -r1 seems to work just fine, here. You can of course check the tbz2 file list and relative sizes against your copy, but you'd pretty much have to trust me that the contents of the files were legit. I've no reason to wish to crack you or anyone else, but it's still a matter of trust, since all you have to go on is my word and reputation here, as I'm not a Gentoo dev. Or... get it from someone else that you trust more. One of the devs might be willing... FWIW, my glibc-2.3.5-r1 works fine, here, to the best of my knowledge. I really don't run a lot of 32-bit stuff, but I haven't had the issues with sandbox and the like that I had with the snapshot, when I tried it and was getting the same corrupted shared library errors. I just remerged sandbox to be sure, and yes, it emerged both ABI versions just fine, which was NOT happening when I had the error you mention, so mine must be working. Do note, however, that my -r1 version has the glibc strings patch that was dicussed here. If you do have me mail you one, I could mail you that, or my (also known working, but unmodified from Gentoo normal) 2.3.5-r0 (IOW, 2.3.5 no r#), which you could use to recompile your own. Both of those were compiled with gcc-3.4.3/3.4.4, as I gave up on gcc4 after that issue, and would need the snapshot version to try it again, anyway. ... I'm thinking about trying the latest, newer snapshot, with (now) gcc-4.0.1. I haven't done so yet, and of course if I did, I'd keep the other versions in binpkg form, since the snapshot is still hard-masked. -- 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 in http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html -- gentoo-amd64@gentoo.org mailing list