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.

> putting CHOST things in /usr/CTARGET is incorrect.  /usr/CHOST/CTARGET/
> is for hosting helper programs specific to CTARGET that run on CHOST.

Great, make it part of the env script. Though CHOST is usually the "target"
for most packages, so not sure of the relevance apart from toolchain.
Greg appeared to be saying use /usr/CHOST/usr/bin/gcc for example (istr
it's effectively a root under there) or just prefix the relevant bindirs
to PATH, along with whatever other voodoo you need. sed for instance is
still going to come from native CBUILD /bin.

Regards,
steveL

[1] https://github.com/chewi/cross-boss [still in preview]
-- 
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-)

Reply via email to