Re: [gentoo-dev] Re: crossdev and multilib interference

[Mike Frysinger <vapier@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1802 bytes --]

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

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]