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
signature.asc
Description: This is a digitally signed message part.
