On Thu 27 Mar 2014 00:41:47 Alexandre Rostovtsev wrote:
> On Wed, 2014-03-26 at 22:41 -0400, Mike Frysinger wrote:
> > On Wed 26 Mar 2014 12:23:53 Ian Stakenvicius wrote:
> > > On 26/03/14 12:12 PM, Mike Frysinger wrote:
> > > > that's bs.  people install crossdev to get a cross-compile
> > > > environment, not to get something that only works through `emerge`.
> > > > attempting to restrict it so it only works through `emerge` is
> > > > unacceptable and it has never been that way.
> > > 
> > > it -does- make sense though to limit anything that one wants to EMERGE
> > > with the crossdev, to require the use of cross-emerge.  Would it not
> > > be possible to somehow ensure the crossdev tools are ignored
> > > in/removed from/cannot pollute the standard emerge environment?  Are
> > > there any use cases where one -would- want the crossdev to be used in
> > > a standard emerge environment instead of using cross-emerge ?
> > 
> > you've lost me.  when you `emerge-$CTARGET`, that package doesn't go
> > anywhere near your ROOT=/ system.  it's entirely contained in
> > /usr/$CTARGET/.
> > 
> > when you run `crossdev $CTARGET`, it installs all the standard
> > $CTARGET-xxx
> > tools in /usr/bin.  this isn't "polluting" the environment at all ... in
> > fact, they're living right alongside existing tools.
> > 
> > as i pointed out elsewhere in this thread, the problem is that multilib
> > relies on automatic detection of the toolchain *failing* so that it falls
> > back to the native value.  in other words, when you run `./configure
> > --host=i686-pc-linux- gnu`, it tries to find e.g. i686-pc-linux-gnu-ar. 
> > it doesn't exist so the fallback is used (plain `ar`).  multilib is using
> > these tuples so that the standard checks (autoconf/eclasses/etc...)
> > trigger in the right ways for the cpu/os/userland combinations.
> > 
> > since crossdev installs a full proper toolchain for the target, the one
> > multilib was using to lie now exists and its toolchain is used instead.
> 
> Crossdev is "polluting the environment" in the specific case that we are
> talking about - secondary native ABIs on a multilib system.
> 
> An amd64 multilib system is not expected to build MIPS binaries that
> would be hosted on itself. So of course anyone using amd64 undersands
> that mips-pc-linux-gnu-ar is part of a cross-compile toolchain, no
> matter whether it's in /usr/bin or /usr/libexec/crossdev or anywhere in
> the filesystem.
> 
> However, an i686 crossdev on an amd64 multilib system is a fundamentally
> different situation.

no, it is not

> An amd64 multilib system *is* expected to build x86
> binaries that would be hosted on itself. So i686-pc-linux-gnu-ar is
> expected to be not a part of any cross-compile toolchain, but a part of
> the native toolchain for the machine's secondary native ABI. Especially
> when i686-pc-linux-gnu-ar is in /usr/bin.

sure, and it works just fine when you use the correct toolchain.  if the user 
wants to build an ABI using their default toolchain, they can pass the right 
ABI flag for it.

but that's irrelevant to how our multilib implementation picks its fake 
CHOST_$ABI to take care of implementing things.  if anything, the current 
system is provably broken because the default ends up executing unqualified 
`ar` and `ranlib` friends.
-mike