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

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

[ViNiL]

Hello!

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.

Any advice?

Thanks a lot.
ViNiL

-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

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

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

[Ian Hastie]

On Fri, 05 Aug 2005 12:20:35 +0200
ViNiL <vinil@zagamma.cz> wrote:

> Hello!
> 
> 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.
> 
> Any advice?

This sounds like a problem that I had once with an early glibc-2.3.5. 
It was that the soft link at /lib/ld-linux.so.2 was set wrongly. 
Firstly this is what you should get.

# ls -l /lib/ld-linux.so.2
lrwxrwxrwx  1 root root 22 Jul 25 01:11 /lib/ld-linux.so.2 ->
../lib32/ld-linux.so.2

If you don't then just do this

# rm /lib/ld-linux.so.2
# ln -s ../lib32/ld-linux.so.2 /lib/ld-linux.so.2
# ldconfig

That should fix the problem.

-- 
Ian.

EOM
-- 
gentoo-amd64@gentoo.org mailing list

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

[ViNiL]

Duncan, thanks for your tips! I used my favourite trick: download stage2
+ tarball, chroot, quickpkg glibc, exit, emerge -avK glibc...

Ian Hastie wrote:
> This sounds like a problem that I had once with an early glibc-2.3.5. 
> It was that the soft link at /lib/ld-linux.so.2 was set wrongly.

This is it! /lib/ld-linux.so.2 pointed to /lib/ld-2.3.5.so which seemed
OK to me. When I changed it to /lib32/ld-linux.so.2, everything is
working fine, now.

The catch is: whenever I compile the glibc, the symlink is wrong again.
Don't you know why?


Thanks a lot.

My system is:
~amd64
glibc-2.3.5-r1
gcc-3.4.4
sandbox-1.2.11


ViNiL

-- 
gentoo-amd64@gentoo.org mailing list

[gentoo-amd64] gcc-4.0.1 compiled glibc-2.3.5.20050722, SUCCESS! Was: broken (32bit) glibc ?

[Duncan]

Duncan posted <pan.2005.08.05.11.17.40.751083@cox.net>, excerpted below, 
on Fri, 05 Aug 2005 04:17:41 -0700:

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

FWIW, I did just that.  I'm now running a gcc-4.0.1 compiled
glibc-2.3.5.20050722.  One more thing working with gcc4!  Woohoo!

I /did/ have to modify one of the Gentoo patches, the pro-police-guard
patch, I believe it was.  That patch adds the -fno-stack-protector flag,
recognized by gcc-3.4.4, but not gcc-4.0.1.  After that, it compiled fine,
and didn't give me the non-working 32-bit shared libraries I got with the
earlier snapshot.

I haven't looked at the gcc ebuilds to verify, but I'm guessing the
pro-police stack-protector (and therefore the normal default no- flag that
would turn it off if a hardened profile enabling it by default was in use)
stuff isn't in the default gcc-3.4.x either, but rather a patch added by
the ebuild.  gcc4 hasn't gotten to the point yet where hardened is looking
at it much, so the equivalent patches haven't been added there, yet, so
gcc4 ebuilds don't recognize the stack-protector flags.

I'm not running hardened, so didn't need the flag turning the
stack-protector off.  However, I tried compiling without the patch
entirely, and while it worked for most things, it triggered the old
__guard symbol errors in xorg bug from about a year ago, so I had to
recompile with the patch, but just with the one line adding the
-fno-stack-protector flag to CFLAGS commented out.

All in all, due to a couple fat-fingerings/fat-headings on my part (like
forgetting I had gcc-config-ed back to gcc-3.4.4, and doing an entire
glibc recompile with 3.3.4 when I wanted 4.0.1!  <grr>!), I must have
recompiled glibc about four times, yesterday! I was sure putting my dual
Opterons to use yesterday! <g>

OTOH, I found yet another package that doesn't yet like gcc4, as well. 
util-linux emerges fine with gcc4, which is why I hadn't noticed it b4,
but I tried running cfdisk, and it segfaulted every single time I tried to
load my hard drive!  Interestingly enough, it worked fine as a user (that
is, it protested about device access permissions and quit, as one would
expect trying to run it as a user), and even worked just fine when I
mistakenly pointed it at my DVD burner with a burnt DVD+R loaded (well it
said read-only mode, but I wouldn't have expected it to work on the DVD at
all, and it did), but it'd segfault every time I tried to point it at my
hard drive, as root so it could actually read it.  I run 100% reiserfs
formatted hard drive partitions, however, and I'm guessing its reiserfs
code isn't gcc4 safe, just yet, tho as I said it emerged fine.  Since it
worked with ISO9660 (surprising me), I'm guessing it probably works with
the more common ext2/3 as well.  It certainly doesn't like reiserfs, tho,
when compiled with gcc4!  As expected, recompiling it with gcc-3.4.4
worked just fine.  (In fact, it was after that remerge that I forgot I had
gcc-3.4.4 selected and did the entire glibc with gcc-3.4.4 instead of the
gcc-4.0.1 I had intended!)

So anyway... with gcc4 now working on glibc, it shouldn't be all /that/
much longer until Gentoo starts supporting gcc-4.x.  This is fairly
significant here, since Gentoo amd64 was one of the first to
officially support gcc-3.4, and will likely be one of the first to support
gcc-4.x as well, particularly since gcc support for amd64 is still
maturing and thus new versions bringing more improvements than they do for
the mature x86(32) arch.  However, there are certainly still /other/
packages that need some attention, before that happens, util-linux
obviously being one of them.  That said, I've been rather surprised at how
much already /does/ work with gcc4.  Nearly my entire system, including
all of the KDE (which had problems with gcc4 early on) I have installed,
is now compiled with gcc4.  I haven't kept precise track, but could
probably count on one hand and certainly could count on two, the number of
packages where the currently merged version has gcc4 issues that I've run
into.

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

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

[Jeremy Huddleston]

[-- Attachment #1: Type: text/plain, Size: 630 bytes --]

On Fri, 2005-08-05 at 12:20 +0200, ViNiL wrote:
> Hello!
> 
> 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?)

Yeah... uh... don't strip glibc.  ;)

I'd recommend just grabbing glibc off of the 2005.1 livecd beta.

> 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

This is prolly 'cause your existing 32bit glibc is broke.


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-amd64] gcc-4.0.1 compiled glibc-2.3.5.20050722, SUCCESS! Was: broken (32bit) glibc ?

[Jeremy Huddleston]

[-- Attachment #1: Type: text/plain, Size: 2706 bytes --]

> I haven't looked at the gcc ebuilds to verify, but I'm guessing the
> pro-police stack-protector (and therefore the normal default no- flag that
> would turn it off if a hardened profile enabling it by default was in use)
> stuff isn't in the default gcc-3.4.x either, but rather a patch added by
> the ebuild.  gcc4 hasn't gotten to the point yet where hardened is looking
> at it much, so the equivalent patches haven't been added there, yet, so
> gcc4 ebuilds don't recognize the stack-protector flags.

Yeah.  I'm prolly not going to consider unmasking gcc4 for atleast 6
months, and even then it'd be within testing profiles only.  I think
halcy0n is the only one *really* following gcc4 development closely
among those maintaining the gentoo toolchain.  I've tried it out every
few months, but it's still too slow for your average applications
(huge/complex C++ applications get speed boosts), and it still pushes
out too much buggy code.  This is expected, though, with a .0 release.
4.0.1 is better, but there's still many regressions.

> OTOH, I found yet another package that doesn't yet like gcc4, as well. 
> util-linux emerges fine with gcc4, which is why I hadn't noticed it b4,
> but I tried running cfdisk, and it segfaulted every single time I tried to
> load my hard drive!  Interestingly enough, it worked fine as a user (that
> is, it protested about device access permissions and quit, as one would
> expect trying to run it as a user), and even worked just fine when I
> mistakenly pointed it at my DVD burner with a burnt DVD+R loaded (well it
> said read-only mode, but I wouldn't have expected it to work on the DVD at
> all, and it did), but it'd segfault every time I tried to point it at my
> hard drive, as root so it could actually read it.  I run 100% reiserfs
> formatted hard drive partitions, however, and I'm guessing its reiserfs
> code isn't gcc4 safe, just yet, tho as I said it emerged fine.  Since it
> worked with ISO9660 (surprising me), I'm guessing it probably works with
> the more common ext2/3 as well.  It certainly doesn't like reiserfs, tho,
> when compiled with gcc4!  As expected, recompiling it with gcc-3.4.4
> worked just fine.  (In fact, it was after that remerge that I forgot I had
> gcc-3.4.4 selected and did the entire glibc with gcc-3.4.4 instead of the
> gcc-4.0.1 I had intended!)

reiserfs is buggy when using a good compiler... I don't want to imagine
what happens with a beta compiler ;)  Also, don't rule out glibc as the
culprit for util-linux failing.  Recompile it with gcc3.4 with a gcc4
glibc to rule that out and make sure it's code generated by gcc4 IN
util-linux that's the problem.



[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: gcc-4.0.1 compiled glibc-2.3.5.20050722, SUCCESS! Was: broken (32bit) glibc ?

[Duncan]

Jeremy Huddleston posted
<1123346597.11655.11.camel@cloud.outersquare.org>, excerpted below,  on
Sat, 06 Aug 2005 09:43:17 -0700:

> reiserfs is buggy when using a good compiler... I don't want to imagine
> what happens with a beta compiler ;)

Actually, reiserfs has been rock solid, here, ever since the kernel folks
added journal=ordered and made that the default.  That's a pretty
significant statement, too, considering I was running defective RAM (still
am, but with a new BIOS that allows me to underclock it slightly, to
~PC3000 from PC3200, and it's stable at that) for sometime, and was
regularly locking up the entire system, without any possibility of
graceful shutdown or recovery of writes in-progress.  I did lose a few
files back in the bad old days of the early 2.4 kernels (back on 32-bit
Mandrake), but IMO it's about as solid as it gets, now, even under the
fairly regular but unpredictable lockups caused by bad memory.

> Also, don't rule out glibc as the
> culprit for util-linux failing.  Recompile it with gcc3.4 with a gcc4
> glibc to rule that out and make sure it's code generated by gcc4 IN
> util-linux that's the problem.

Actually, at the time I tried it I think I was on glibc-2.3.5-r1,
gcc-3.4.4 compiled.  I only got the gcc-4 compiled glibc-2.3.5.20050722
snapshot successfully merged /after/ that.  Remember, as I mentioned, I
forgot I had reset gcc to 3.4.4 for the util-linux remerge, and did a full
merge of the glibc snapshot with 3.4.4 instead of the 4.0.1 I had intended
to use, so it was only /after/ that, that I got the new glibc merged, to
my satisfaction.

Besides, remerging util-linux with gcc-3.4.4 fixed it right up, and it's
a short enough remerge job that I verified by trying a fresh gcc4 emerged
version again after that (hoping there might have been a patch added to
the ebuild to fix the problem since my initial emerge), and it went right
back to segfaulting, and again back to working when I remerged again with
gcc-3.4.4, so it was pretty definitely util-linux as compiled with
gcc-4.0.1, that was the issue.

BTW, I use FEATURES=buildpkg, so after initial compile, switching glibcs
back to the old gentoo approved 2.3.5-rX compiled with a gentoo approved
gcc-3.4.4, is simply a matter of emerge -K-ing the desired glibc.  That's
really the only reason I'm daring enough to be running the still
hard-masked snapshot in the first place.  With emerge -K, it's almost as
simple as a glibc-config, parallel to gcc-config, would be, and in some
ways less problematic, given the fact that since I've compiled KDE against
gcc-4's libstdc++, every time I gcc-config back to 3.4.x, certain KDE apps
(generally, anything using khtml, so not only Konqueror, but kweather,
and a few others) refuse to work correctly, until I gcc-config back to a
gcc-4.x once again.

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

Re: [gentoo-amd64] Re: gcc-4.0.1 compiled glibc-2.3.5.20050722, SUCCESS! Was: broken (32bit) glibc ?

[Jeremy Huddleston]

[-- Attachment #1: Type: text/plain, Size: 1264 bytes --]

> BTW, I use FEATURES=buildpkg, so after initial compile, switching glibcs
> back to the old gentoo approved 2.3.5-rX compiled with a gentoo approved
> gcc-3.4.4, is simply a matter of emerge -K-ing the desired glibc.  That's
> really the only reason I'm daring enough to be running the still
> hard-masked snapshot in the first place.  With emerge -K, it's almost as
> simple as a glibc-config, parallel to gcc-config, would be, and in some
> ways less problematic, given the fact that since I've compiled KDE against
> gcc-4's libstdc++, every time I gcc-config back to 3.4.x, certain KDE apps
> (generally, anything using khtml, so not only Konqueror, but kweather,
> and a few others) refuse to work correctly, until I gcc-config back to a
> gcc-4.x once again.

Yeah... uh... that's a known PITA issue...  HOPEFULLY everything
compiled against the 3.4 libstdc++ should work with the 4.0 libstdc++.
You can get around this particular issue by
creating /etc/env.d/01usegcc4stdcpp to force the loader to use the gcc4
libs:
LDPATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.1/32

Then run env-update

You can check that it's using the gcc4 libstdc++ by doing:
ldd /usr/kde/3.4/bin/konqueror | grep stdc++


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[gentoo-amd64] Re: Re: gcc-4.0.1 compiled glibc-2.3.5.20050722, SUCCESS! Was: broken (32bit) glibc ?

[Duncan]

Jeremy Huddleston posted <1123362061.11745.7.camel@cloud.outersquare.org>,
excerpted below,  on Sat, 06 Aug 2005 14:01:01 -0700:

> [Duncan wrote...]
>> [S]ince I've compiled KDE against gcc-4's libstdc++, every time I
>> gcc-config back to 3.4.x, certain KDE apps (generally, anything using
>> khtml, so not only Konqueror, but kweather, and a few others) refuse to
>> work correctly, until I gcc-config back to a gcc-4.x once again.
> 
> Yeah... uh... that's a known PITA issue...  HOPEFULLY everything
> compiled against the 3.4 libstdc++ should work with the 4.0 libstdc++.
> You can get around this particular issue by creating
> /etc/env.d/01usegcc4stdcpp to force the loader to use the gcc4 libs:
> LDPATH=/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.1:/usr/lib/gcc/x86_64-pc-linux-gnu/4.0.1/32
> 
> Then run env-update
> 
> You can check that it's using the gcc4 libstdc++ by doing: ldd
> /usr/kde/3.4/bin/konqueror | grep stdc++

Wow, I wasn't aware of that trick!  Very cool!  Thanks!

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

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

[Ian Hastie]

On Sat, 06 Aug 2005 11:37:08 +0200
ViNiL <vinil@zagamma.cz> wrote:

> Duncan, thanks for your tips! I used my favourite trick: download
> stage2 + tarball, chroot, quickpkg glibc, exit, emerge -avK glibc...
> 
> Ian Hastie wrote:
> > This sounds like a problem that I had once with an early
> > glibc-2.3.5.  It was that the soft link at /lib/ld-linux.so.2 was
> > set wrongly.
> 
> This is it! /lib/ld-linux.so.2 pointed to /lib/ld-2.3.5.so which
> seemed OK to me. When I changed it to /lib32/ld-linux.so.2, everything
> is working fine, now.
> 
> The catch is: whenever I compile the glibc, the symlink is wrong
> again. Don't you know why?

I can only assume it's a bug in the ebuild.  The newer glibc ebuilds
don't seem to have the problem, not that I remember having to fix for
them anyway.  Doesn't seem to have been reported as a bug either.  It's
possible it might be the underlying cause of some other bugs though.

-- 
Ian.

EOM
-- 
gentoo-amd64@gentoo.org mailing list