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

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

[Peter Humphrey]

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:

configure:1533: checking for a BSD-compatible install
configure:1588: result: /bin/install -c
configure:1599: checking whether build environment is sane
configure:1642: result: yes
configure:1707: checking for gawk
configure:1723: found /bin/gawk
configure:1733: result: gawk
configure:1743: checking whether make sets $(MAKE)
configure:1763: result: yes
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.
$ 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]

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

Anyone any ideas?

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

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

[Simon Stelling]

> Anyone any ideas?

Stop using eselect-compiler, it's broken :P Unmerge it and make sure you
have =gcc-config-1.3* installed.

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-amd64@gentoo.org mailing list

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

[Peter Humphrey]

On Tuesday 26 September 2006 12:17, Simon Stelling wrote:

> Stop using eselect-compiler, it's broken :P Unmerge it and make sure you
> have =gcc-config-1.3* installed.

Yes, I think I knew it was broken; I only used it to list what's available. 
Selection of compiler I did with gcc-config.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200609261118.18556.prh@gotadsl.co.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@gentoo.org mailing list

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

[Simon Stelling]

Duncan wrote:
>> 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.

Good guess, but actually not true. It should be x86_64-pc-linux-gnu and
use the -m32 flag to produce 32bit code. This is just eselect-compiler
being broken. i686-pc-linux-gnu is installed by eselect-compiler. :)

-- 
Kind Regards,

Simon Stelling
Gentoo/AMD64 developer
-- 
gentoo-amd64@gentoo.org mailing list

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

[Peter Humphrey]

On Tuesday 26 September 2006 12:20, Duncan wrote:

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

Nope, they both compile just fine. Of those, only sandbox is causing me 
grief.

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

Actually, only sandbox and module-init-tools are failing.

> if you are lucky, simply setting the 32-bit compiler will put you back in
> good form. 

I can't see why selecting a 32-bit compiler should make portage work again. 
Surely I need a 64-bit compiler for almost the whole system? I haven't 
changed any multilib flags, so I should still have both, no?

For the moment I'm continuing with emerge -e world, just skipping the few 
packages that fail (just the two of them so far) - they still exist, after 
all, in their earlier state.

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

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

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

[Peter Humphrey]

On Tuesday 26 September 2006 12:20, Duncan wrote:

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

I found the answer. The problem has been caused by the broken 
eselect-compiler. Even after it's purged from the system, it leaves debris 
in /usr/bin. I followed the discussion of bug 133209, which showed me how 
to clear up the mess.

Emerge -e system is now running on a clean system, and has compiled sandbox 
just fine.

Thanks for the help, all.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

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

[Duncan]

Peter Humphrey <prh@gotadsl.co.uk> posted
200609271221.46275.prh@gotadsl.co.uk, excerpted below, on  Wed, 27 Sep
2006 12:21:46 +0000:

> I found the answer. The problem has been caused by the broken 
> eselect-compiler. Even after it's purged from the system, it leaves debris 
> in /usr/bin. I followed the discussion of bug 133209, which showed me how 
> to clear up the mess.
> 
> Emerge -e system is now running on a clean system, and has compiled sandbox 
> just fine.

Very glad you finally got it fixed! =8^)  Thanks for the fix report.

-- 
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@gentoo.org mailing list

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

[Peter Humphrey]

On Wednesday 27 September 2006 13:49, Duncan wrote:

> Very glad you finally got it fixed! =8^)  Thanks for the fix report.

Unfortunately, module-init-tools doesn't compile - it fails on "too many 
filenames given". I've opened a bug report.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list

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

[Peter Humphrey]

On Wednesday 27 September 2006 14:01, Peter Humphrey wrote:

> Unfortunately, module-init-tools doesn't compile - it fails on "too many
> filenames given". I've opened a bug report.

... which turned out to be a duplicate of 149210.

I've fixed my box thus pro tem:

# cat /etc/portage/env/sys-apps/module-init-tools
CFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks -freorder-blocks-and-partition -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants"
CXXFLAGS="-march=k8 -Os -pipe -frename-registers -fweb -freorder-blocks -funit-at-a-time -ftree-pre -fgcse-sm -fgcse-las -fgcse-after-reload -fmerge-all-constants"CHOST="x86_64-pc-linux-gnu"

If my global flags change in /etc/make.conf, I shall probably forget to make 
corresponding changes to anything under /etc/portage/env. This could be 
avoided if those files could be used to specify flags to be deleted from 
the environment. Perhaps I should put in a feature request.

-- 
Rgds
Peter
-- 
gentoo-amd64@gentoo.org mailing list