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

[Mike Frysinger]

On Thu 27 Mar 2014 08:41:08 Steven J. Long wrote:
> Mike Frysinger wrote:
> > Steven J. Long wrote:
> > > Mike Frysinger wrote:
> > > > if they're in $PATH, then the exact location is irrelevant.
> > > > they need not be in /usr/bin to cause a problem.
> > > > if they're not in $PATH, then you're breaking the cross-compilers
> > > > and that is unacceptable.
> > >
> > > Cross-compilation should be supported via cross-emerge, and perhaps a
> > > small
> > > script the cross-compiler sources to setup the env (ie prefix to PATH in
> > > this case) for using CHOST-* tools, like x86-pc-linux-gnu-gcc targetting
> > > a straight x86 platform, instead of the normal multilib setup. The
> > > latter being used by the former (I'd have thought it was already done.)
> > >
> > > The cross tools should NOT pollute the default PATH, simply because the
> > > user happened to run crossdev at some point.
> >
> > 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.
>
> That's why I suggested a small sh script to source, to setup that
> environment. Personally, I do an awful lot more than that just to build a
> native chroot, let alone cross-compile. And I really don't see the hardship
> for these brave "cross-compilers" of yours in sourcing a small setup
> script, which can be added to ~/.bashrc or even the system-wide one, for
> anyone who really wants it to apply whenever they login. Is this somehow
> beyond our most advanced userbase?
>
> People may install crossdev to get a cross-compile environment, but it's a
> broken design if it's not contained. And BS about how you think it should
> ALWAYS go for everybody, only leads to borked "solutions" elsewhere like
> telling the people on an amd64 install that they have to run some god-awful
> "new" %multilib thing to compile for their secondary ABI. That's just as
> counter-intuitive, when you could just fix your borkage and have a clean
> setup for everyone.

your conclusions are invalid as you're basing them on the assumption that the 
current multilib system is working correctly and cleanly.  it is provably not.

sticking your head in the sand and blaming crossdev for errors in the multilib 
logic is asinine.
-mike