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

[Duncan]

Randy Barlow posted on Mon, 18 Jan 2010 16:39:07 -0500 as excerpted:

> Howdy! I'm trying to perform a Gentoo install in a VM (KVM), and I seem
> to have a problem building grub.  It fails in the configure process like
> this:
>
> checking for i686-pc-linux-gnu-gcc... (cached) x86_64-pc-linux-gnu-gcc
> -m32 checking for C compiler default output file name... a.out checking
> whether the C compiler works... configure: error: in
> `/var/tmp/portage/sys-boot/grub-0.97-r9/work/grub-0.97': configure:
> error: cannot run C compiled programs. If you meant to cross compile,
> use `--host'.
>
> I thought that was pretty odd. I also discovered that glibc won't build
> correctly, with this:

That's classic screwed-up-32-bit symptoms.  Your primary 64-bit toolchain 
is fine, so most things compile fine, but the 32-bit toolchain is 
screwed, so anything attempting to use it fails.  Grub is of course 32-
bit, so it's failing.  glibc compiles for both bitnesses, so the 32-bit 
side of it is failing.  If I'm not mistaken, you'll likely find that gcc 
won't build either, because it too compiles dual bitnesses.

There are a number of reasons this might have happened.  You mention that 
this is a new install, which should eliminate some of the historical 
ones.  Your current profile looks good (it's a current 10th anniversary 
amd64 profile and isn't no-multilib), but you didn't mistakenly try a no-
multilib version and compile some bits of the toolchain, did you?

gcc 4.3.4... should be fine.  I know of no issues with glibc.

Hmm, kernel config!  You have 32-bit executable format turned on in the 
kernel, right?  That's under Executable file formats / Emulations, IA32 
Emulation.  (It's not emulation, but anyway...)  If that's it, you're not 
the first one that's messed up, and probably won't be the last, either.

I haven't messed with VMs here (my machine doesn't have the hardware 
extensions, and I haven't particularly needed a slower software-only a VM 
for anything, so...), so I know not what if any options may need enabled 
there, in either the host or the VM.  If it's related to that, you'll 
need to find help from someone else.

One other possibility to try is FEATURES=-sandbox emerge sandbox.  
Multilib profiles include sandboxing libs for both 32-bit and 64-bit as 
well, and sometimes it's simply the 32-bit side of that which gets 
screwed up.  Of course, building sandbox requires 32-bit as well, but if 
it's just the 32-bit sandbox libs that are screwed,t then bypassing them 
to remerge sandbox itself will work, and hopefully the newly built 
sandbox will be functional.  If that fails with 32-bit errors as well, 
the problem is deeper in your toolchain, likely a screwed-up 32-bit gcc, 
or possibly a screwed-up 32-bit glibc.  It can also be binutils.

If it's not sandbox and not kernel, particularly since you're just fresh 
installing, it's probably best to extract the stage tarball in a temp dir 
somewhere, chroot into it, and quickpkg gcc, glibc, binutils, and 
sandbox.  That will give you binpkgs of the stage tarball versions of 
those packages.  Back out of that temp chroot again, you can
emerge --usepkgonly the binpkgs you just created, thus getting back a 
working toolchain including 32-bit again.  (You can try one at a time and 
then test, to figure out what broke, or just do them all, then rebuild 
them later.)  Using that toolchain, you should be able to rebuild the 
packages you binpkg installed from the stage tarball, and get back on 
track.

Given the automated stage tarball building process gentoo uses these 
days, it's narrowly possible the current tarball is somehow screwed, too, 
and the binpkgs you create from it won't solve the problem.  That is 
quite unlikely, but narrowly possible.  If that turns out to be the case, 
you can try a tarball from a week or two ago, and hopefully it'll work 
better.  If it too gives problems, then it's likely something you're 
doing wrong.  In either case, when it gets to this stage it's time to 
file a bug and get someone who knows a bit more about the intricacies of 
multilib toolchains involved.

(FWIW, I run a no-multilib profile and have for a couple years now, I 
think, but I also use a 32-bit chroot, generally following the gentoo/
amd64 32-bit chroot guide but with a few changes since I'm making a fully 
bootable but not on that machine image, to compile the x86 gentoo image I 
use on my netbook.)

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