[gentoo-amd64] Re: Can not compile gcc

[Duncan]

"Mansour Al Akeel" <mansour.alakeel@×××××.com> posted
2a21586d0811141002p735a3839h74ec70ff8dd7f524@××××××××××.com, excerpted
below, on  Fri, 14 Nov 2008 14:02:19 -0400:

> checking for x86_64-pc-linux-gnu-gcc...
> /var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/xgcc
> -B/var/tmp/portage/sys-devel/gcc-4.1.2/work/build/./gcc/
> -B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
> /usr/x86_64-pc-linux-gnu/include -isystem
> /usr/x86_64-pc-linux-gnu/sys-include  -m32

First, please kill the HTML.  There's enough "old fogies" like me that 
don't like it, on most Linux related lists at least, that it's really not 
a good idea.  We have a choice as to whether to reply or not, and some of 
the guys that have been around the longest and therefore tend to have the 
most wisdom to apply to a problem, may not reply to HTML posts at all -- 
or even see them in some cases, if they filter them out, as I do for 
regular mail.  Do you really want to potentially kill the single reply 
that might have otherwise been the only one with a working fix?

Anyway, back to your question.  See that -m32?  That's telling the new 
gcc it just built while bootstrapping itself and is there testing, to 
compile the test in 32-bit mode.  It (I think) builds the 64-bit stuff 
first, and is then failing on the 32-bit stuff.  IOW, it's an issue 
related to the 32-bit aspect of the compile for both 64-bit and 32-bit 
support, that you get when you are running a multilib profile.

Personally, since I don't do the proprietaryware that's the biggest 
reason to do 32-bit compatibility in the first place, and all the 
freedomware I run has long since been 64-bit, I didn't have any reason to 
stay with multilib.  And, since it gave me headaches like this every so 
often, and even when it was working, both gcc and glibc, which are both 
already fairly long merges, took effectively double the time to build 
because they were being built for both 64-bit and 32-bit, I had lots of 
reason NOT to stay with multilib.

So I switched to the no-multilib profile and simplified my life with 
faster and more trouble-free gcc and glibc compiles, and have been VERY 
happy I did so.

Of course if you're still held captive by some proprietaryware or other 
that's only available in 32-bit, that's not going to be an option for you.

There are several possible triggers for this problem.  The first one is a 
broken 32-bit sandbox.  For that, try turning it off and remerging 
sandbox.  If it works, you should then be able to remerge gcc without 
issue and remerge sandbox normally.

FEATURES=-sandbox emerge sandbox

If that doesn't work, one thing that has been a problem in the past but 
one would hope doesn't apply any more, is if you had eselect-compiler and 
gcc-config-2.0 merged at some point.  If you did, there's a bug on it you 
should look at.  If you didn't, this one doesn't apply.

There are various other possibilities due to various broken configs and 
etc relating to the 32-bit side of the multilib toolchain.  Often the 
simplest solution to these is to remerge a known working usually older 
gcc, hopefully overwriting whatever's wrong with your current setup, 
after which you can normally rebuild the newer gcc using the working old 
one, and be back on track.  

If you've been running FEATURES=buildpkg for some time, you may have 
several older versions of gcc in your binary package archive and can just 
remerge one of them, temporarily downgrading gcc to fix the problem, then 
use it to merge a current gcc.  This of course is one of the benefits of 
running with that feature enabled.

If you have NOT been running with FEATURES=buildpkg enabled, you have a 
choice.  If you have another working gentoo/amd64 machine available, you 
can quickpkg it's gcc, copy it over and emerge -K it onto the affected 
machine.  Otherwise you'll have to choose between trusting a version 
someone else may offer you and grabbing one off the latest gentoo/amd64 
install stages.  This would involve downloading a stage tarball, 
untarring it somewhere temporary, chrooting into it, doing a quickpkg of 
the gcc therein, then from outside the chroot, doing an emerge -K of the 
binpkg built by the quickpkg.

When you get your system working correctly again (but before you go back 
to your system/world rebuild), you may wish to consider 
FEATURES=buildpkg.  If you turn it on, you can then do your system/world 
rebuild and will have binpkgs of everything, available if you need them.  
After awhile, you'll have a couple older versions of most packages as 
well, in case you need to revert to an older one for some reason.  It's a 
quite handy thing to have available, and can sure save a lot of needless 
recompiling at times, even if you /don't/ ever use it to get out of 
another hole like a busted gcc.

Spacewise, a full FEATURES=buildpkg system and world set, with what I 
have merged here, runs about a gig, but you'll want at least 2 gigs 
available for binpkgs and preferably 4 gigs or so, so you don't have to 
clean out old versions too often, on whatever partition you decide to 
store them on.  The default storage location is $PORTDIR/packages, IIRC, 
but you can point portage at a different location by setting PKGDIR in 
make.conf as appropriate.

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