1 |
On Wed 26 Mar 2014 12:25:29 Steven J. Long wrote: |
2 |
> Mike Frysinger wrote: |
3 |
> > Greg Turner wrote: |
4 |
> > > As for how to fix it, if foo-bar-baz-quux crossdev targets are at |
5 |
> > > ${EROOT}/usr/foo-bar-baz-quux, putting wrappers in |
6 |
> > > ${EROOT}/usr/foo-bar-baz-quux/cross-wrappers, or something like that, |
7 |
> > > seems perfectly reasonable... heck, pure speculation, but it might |
8 |
> > > even noticeably speed up day-to-day $PATH searching on systems with |
9 |
> > > lots of crossdev targets installed. |
10 |
> > |
11 |
> > if they're in $PATH, then the exact location is irrelevant. |
12 |
> > they need not be in /usr/bin to cause a problem. |
13 |
> > if they're not in $PATH, then you're breaking the cross-compilers |
14 |
> > and that is unacceptable. |
15 |
> |
16 |
> Cross-compilation should be supported via cross-emerge, and perhaps a small |
17 |
> script the cross-compiler sources to setup the env (ie prefix to PATH in |
18 |
> this case) for using CHOST-* tools, like x86-pc-linux-gnu-gcc targetting |
19 |
> a straight x86 platform, instead of the normal multilib setup. The |
20 |
> latter being used by the former (I'd have thought it was already done.) |
21 |
> |
22 |
> The cross tools should NOT pollute the default PATH, simply because the |
23 |
> user happened to run crossdev at some point. It's *borked*, plain and |
24 |
> simple, so fix it please or expect people to come up with other solutions |
25 |
> [1]; fragmenting the effort, and making cross-compilers lives harder, as |
26 |
> we try to blend together a working solution from various efforts. The |
27 |
> exact thing crossdev is supposed to answer. |
28 |
|
29 |
that's bs. people install crossdev to get a cross-compile environment, not to |
30 |
get something that only works through `emerge`. attempting to restrict it so |
31 |
it only works through `emerge` is unacceptable and it has never been that way. |
32 |
-mike |