[gentoo-amd64] Re: emerge sandbox is using the wrong host id

[Duncan]

Peter Humphrey <prh@××××××××××.uk> posted
200609261118.18556.prh@××××××××××.uk, excerpted below, on  Tue, 26 Sep
2006 11:18:18 +0000:

> Well, I decided to forge ahead while I still have the steam. I'm upgrading
> GCC from 3.4.4 to 4.1.1-r1.
>
> I followed the instructions thus:
>
> # emerge -uav gcc
> # gcc-config i686-pc-linux-gnu-4.1.1
> # source /etc/profile
> # fix_libtool_files.sh 3.4.4
> # emerge --oneshot -av libtool
>
> I then decided, before emerging -e system and risking confusion of GCC
> versions as before, to remove 3.4.4 and emerge libtool again to check that
> the compiler works ok. That went without a problem, so I do have a working
> 4.1.1 compiler.
>
> Now, during emerge -e system, emerge of sandbox (the ninth package of 114)
> falls over with the dreaded "C compiler cannot create executables". I
> followed its own advice and ran:
> FEATURES="-sandbox" emerge sandbox
> which failed at the same point. Here are some extracts
> from /var/tmp/portage/sandbox-1.2.18.1/work/build-x86-x86_64-pc-linux-gnu/config.log:
>
> Invocation command line was
> $ ../sandbox-1.2.18.1//configure --prefix=/usr --host=i686-pc-linux-gnu --mandir=/usr/share/man --infodir=/usr
> /share/info --datadir=/usr/share --sysconfdir=/etc --localstatedir=/var/lib --libdir=/usr/lib32 --enable-multili
> b --build=i686-pc-linux-gnu
>
> Note the "--host=i686-pc-linux-gnu". I think that's wrong: it should
> say "--host=x86_64-pc-linux-gnu", no? Continuing the log extract:

No, that's correct in this case.  I see your problem now.  While most
packages you install are 64-bit only and work, sandbox has both 32-bit and
64-bit components -- libraries that enforce sandbox restrictions in both
32-bit and 64-bit mode.  What's happening is that your 64-bit gcc is
working, but somewhere along the way, you lost a working 32-bit compiler. 
With it horked, you can't compile any 32-bit stuff, including the 32-bit
part of sandbox.  However, since most of the system is 64-bit and that's
working, you can compile most packages just fine.

Other packages that likely won't compile will be glibc and gcc, since they
both have 32-bit aspects as well, and that's what's horked.

> configure:1942: checking for i686-pc-linux-gnu-gcc
> configure:1958: found /usr/bin/i686-pc-linux-gnu-gcc
> configure:1968: result: i686-pc-linux-gnu-gcc
> configure:2250: checking for C compiler version
> configure:2253: i686-pc-linux-gnu-gcc --version </dev/null >&5
> gcc-config error: i686-pc-linux-gnu-gcc wrapper: Could not
> determine which compiler to use.  Invalid CTARGET or CTARGET has no
> selected profile.
>
> Indeed, issuing commands manually I get this:
>
> $ i686-pc-linux-gnu-gcc --version
> gcc-config error: i686-pc-linux-gnu-gcc wrapper: Could not determine
> which compiler to use.  Invalid CTARGET or CTARGET has no selected
> profile.

This simply confirms the above -- you have a dead 32-bit gcc.

> $ which i686-pc-linux-gnu-gcc
> /usr/bin/i686-pc-linux-gnu-gcc
> $ eselect compiler list
> Available compilers for CTARGET i686-pc-linux-gnu
>   [1]   x86_64-pc-linux-gnu-4.1.1/x86-vanilla
> Available compilers for CTARGET x86_64-pc-linux-gnu
>   [2]   x86_64-pc-linux-gnu-4.1.1/amd64-vanilla
>
> Activated profiles:
> [null]
> $ x86_64-pc-linux-gnu-gcc --version
> x86_64-pc-linux-gnu-gcc (GCC) 4.1.1 (Gentoo 4.1.1-r1)
> [...copyright notice...]
>
> [End of log extracts]

Note the [null].  That should be where it lists the configured active
32-bit compiler.  It's not set, so you are having problems.

FWIW, this is almost certainly one of the reasons eselect-compiler is
currently masked...  Also note that since it's masked, the instructions
for upgrading gcc needn't bother with any eselect compiler specific
issues.  Here's what happened.  The old gcc-config (which the instructions
have in mind) set both, but eselect compiler sets them separately and since
you used the gcc-config compatibility wrapper with instructions for the
old both-at-once gcc-config, guess what, you set only one.

So...  Try eselect compiler list, then eselect compiler set <number>,
where <number> is an appropriate number selected from the available 32-bit
compiler options.

Hopefully, that gets you back on the right track, and you can successfully
complete the sandbox emerge.  If it doesn't, things get more difficult,
but we identified the problem now, which is certainly half the way to
fixing it right there.  If necessary, you can rebuild gcc using the
multilib version in the stage tarball to get working multilib back, and go
from there.  Same with glibc if necessary.

>
> Other packages are compiling as I write, having got to package 38 of
> 105, so the environment is broadly correct.

As I said, the majority of the packages will be 64-bit, so lack of a valid
32-bit compiler setting won't affect them at all.  Only the toolchain
packages, for the most part, will be affected, so sandbox, glibc, gcc, and
maybe binutils.  (I don't have a good grasp of exactly how much of
binutils is multilib split, but various remarks I've read indicate that at
least some of it is.)  However, if you are lucky, simply setting the
32-bit compiler will put you back in good form.

...  I wonder how much of your earlier problems might have the same thing?
Oh, well, hindsight's always 20/20, as they say.  One more thing to add
to our list of things to check...

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