[gentoo-amd64] Re: Building vanilla gcc fails, any ideas?

[Duncan]

Jack Lloyd <lloyd@×××××××××.net> posted
20080206144246.GE8236@×××××××××.net, excerpted below, on  Wed, 06 Feb 2008
09:42:47 -0500:

> Trying to build a gcc 4.3 snapshot (20080125) fails on my x86-64 box.

> Currently I'm configuring with
>
> ../gcc-4.3-20080125/configure --enable-languages=c,c++,objc,obj-c++
> --prefix=/usr/local/gcc-4.3-20080125 --program-suffix=-4.3-20080125

You'll probably have better luck (and if nothing else, can see what sort 
of patches Gentoo is including to see if any of them might fix your 
problem) if you use the Gentoo ebuild snapshots.  These aren't in the 
main tree, as they've been moved to I believe the toolchain overlay.  The 
easiest way to grab various overlays is to emerge layman, check its 
documentation and configure it, then add the overlays you want to your 
list.  Here, I have my own "esyn" (note the missing c, so I know it's my 
version) script that syncs portage and layman, does the esearch update 
database, and emerge --fetch 's all the updated ebuilds, so they are 
ready to go when I decide to merge them.

I haven't been keeping up with gcc-4.3, but for 4.0 thru 4.1, I regularly 
ran the snapshot ebuilds as my main system gcc, using gcc-config to 
switch back to an earlier version when something failed to build with the 
newer version.  Since 4.0 was the first version that supported amd64 
natively (with 3.x it was an add-on) but the .0 was mainly a rewrite and 
didn't target major improvements, both 4.0 and 4.1 were big improvements 
for gcc on amd64, far bigger than on x86 (32-bit), but 4.0 had some 
issues that were fixed fairly quickly for the 4.1 branch, so it was 
actually better than the stable 4.0 branch at that point.

BTW, if you don't specifically need multilib, things get quite a bit less 
complex if you choose a no-multilib (64-bit only) profile.  Since both 
gcc and glibc basically double their build when doing multilib, it 
substantially decreases merge time for them, and the all too common 
problems with sandbox (which result from issues with the 32-bit side gcc 
which aren't apparent elsewhere since nothing else uses them) disappear 
as well.

Alternatively for those that DO use 32-bit stuff still, it's possible to 
do the full chroot thing, compiling everything you need 32-bit as 32-bit, 
almost but not quite to the point of having a parallel 32-bit Gentoo 
beside your 64-bit one.  (If you do want a parallel 32-bit boot, it's 
pretty easy once you have the chroot setup, just a few more packages.)  
That's better for 32-bit than using multilib anyway, since you get to 
compile all the compatibility libs that you'd otherwise install as 
binaries, and compiling is the Gentoo way. =8^)  But you don't HAVE to 
compile it for the initial install unless you want to, as you can use a 
stage-3 and packages CD install instead. =8^)  (Of course, this will be 
easier once 2008.0 comes out; 2007.0 is getting a bit long in the tooth 
by now.)

I don't do proprietaryware and everything I need happens to be 64-bit 
compatible already, so I've no reason to run 32-bit anyway, but knowing 
how much it has simplified things, and that there's the 32-bit chroot 
guide already available telling how to do that, I'd prefer that to going 
back to multilib if I DID have reason to run 32-bit, now.  Of course as 
they say, YMMV, but it's certainly an option, and it certainly does cut 
the headaches of having 32-bit problems hamper updates on an otherwise 
mainly 64-bit system.

You asked for hints.  Those are mine. =8^)

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

-- 
gentoo-amd64@l.g.o mailing list