[gentoo-amd64] Re: broken (32bit) glibc ?

[Duncan]

ViNiL posted <1123237235.11188.36.camel@×××××××××××××××.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@g.o mailing list