On Wed 26 Mar 2014 12:25:29 Steven J. Long wrote:
> Mike Frysinger wrote:
> > Greg Turner wrote:
> > > As for how to fix it, if foo-bar-baz-quux crossdev targets are at
> > > ${EROOT}/usr/foo-bar-baz-quux, putting wrappers in
> > > ${EROOT}/usr/foo-bar-baz-quux/cross-wrappers, or something like that,
> > > seems perfectly reasonable... heck, pure speculation, but it might
> > > even noticeably speed up day-to-day $PATH searching on systems with
> > > lots of crossdev targets installed.
> >
> > 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. It's *borked*, plain and
> simple, so fix it please or expect people to come up with other solutions
> [1]; fragmenting the effort, and making cross-compilers lives harder, as
> we try to blend together a working solution from various efforts. The
> exact thing crossdev is supposed to answer.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. -mike
signature.asc
Description: This is a digitally signed message part.
