[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@×××.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@g.o mailing list