[gentoo-amd64] Re: grub and glibc won't build on my new install

[Duncan]

Randy Barlow posted on Fri, 22 Jan 2010 23:41:05 -0500 as excerpted:

> Randy Barlow wrote:
>> I'll give the sandbox trick a whirl.
>
> Well, that turned out to be kind of hilarious:

>   * If configure failed with a 'cannot run C compiled programs' error,
> try this:
>   * FEATURES=-sandbox emerge sandbox
>
> I love how the package itself tells me to try the very command I did
> try.

Yeah... That's a known issue, with that as one of the common fixes, so 
they mention it.  Obviously they don't check the feature set when output 
that, tho.

> Anyways, perhaps I should just extract another snapshot over this
> one...

That sounds like a good idea.  The toolchain is obviously broken, and 
extracting a new stage tarball over top is one way to fix it.

When you retry, keep track of what packages are installed and if you get 
that problem, which of the toolchain packages (gcc and glibc especially) 
was installed last.  That's going to be the problem package.  If they're 
all still what was on the stage tarball, then it's gotta be it.

Meanwhile, to make things easier if something like this happens when you 
have the system up and running normally, you may wish to set 
FEATURES=buildpkg (and set PKGDIR appropriately if you don't like the 
default).  That way, as you build packages, they'll get binpkged as 
well.  Over time, you'll build up multiple versions of most packages, and 
if one breaks, it's easy enough to revert using emerge --usepkgonly =pkg-
version.  That way, a broken gcc won't matter as you can just remerge an 
older, working version.  If the problem is portage or python, so emerge 
itself is broken, since the binpkgs are simple tarballs with extra 
metadata tacked on the end, you can simply extract the tarball directly 
over the live filesystem if you have to (but be sure to move config files 
out of the way first, so they don't get overwritten by the defaults in 
the pkg tarball, then move them back).  Of course, portage won't know 
about it then, so once it's working again, the first thing you'll want to 
do is remerge the version you just extracted, thus updating the package 
database so it knows what's installed.  If you put PKGDIR on its own 
filesystem, 4 gigs or so is a reasonable size, giving you room to keep 
multiple copies of your packages without having to clean out the old ones 
too often.

Anyway... hassles with 32-bit, and the fact that I don't run 
proprietaryware and all the FLOSS I run had been long ported to amd64 
anyway, were the reason I finally decided a couple years ago to go no-
multilib.

Generally, the only reason to run multilib is proprietary binary-only
32-bit-only packages such as games, codecs, and possibly other legacy 
software, and codecs, flash, etc, are more and more available for 64-bit 
anyway, if you /do/ choose to run proprietary, so the reasons to hassle 
32-bit multilib are becoming fewer and fewer.  Meanwhile, the benefits to 
going multilib include leaving the hassle of keeping a working 32-bit 
toolchain behind, and halving your gcc and glibc compile time because 32-
bit doesn't need built.  For me, that was an easy choice to make, and one 
I haven't regretted.  I only wished I had made it sooner! =:^)

And, FWIW, it's always possible to do the 32-bit chroot thing using the 
Gentoo guide for it, and compile your own separately tracked 32-bit 
system.  Actually, that's what I did when I setup my netbook with Gentoo, 
using a 32-bit chroot to setup an image on my main machine, since it's so 
much more powerful, then transferring the image to the netbook.  I'm 
using rsync to keep the images synced, now.

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