| 1 |
Mike Frysinger wrote: |
| 2 |
> Steven J. Long wrote: |
| 3 |
> > Mike Frysinger wrote: |
| 4 |
> > > if they're in $PATH, then the exact location is irrelevant. |
| 5 |
> > > they need not be in /usr/bin to cause a problem. |
| 6 |
> > > if they're not in $PATH, then you're breaking the cross-compilers |
| 7 |
> > > and that is unacceptable. |
| 8 |
> > |
| 9 |
> > Cross-compilation should be supported via cross-emerge, and perhaps a small |
| 10 |
> > script the cross-compiler sources to setup the env (ie prefix to PATH in |
| 11 |
> > this case) for using CHOST-* tools, like x86-pc-linux-gnu-gcc targetting |
| 12 |
> > a straight x86 platform, instead of the normal multilib setup. The |
| 13 |
> > latter being used by the former (I'd have thought it was already done.) |
| 14 |
> > |
| 15 |
> > The cross tools should NOT pollute the default PATH, simply because the |
| 16 |
> > user happened to run crossdev at some point. |
| 17 |
|
| 18 |
> that's bs. people install crossdev to get a cross-compile environment, not to |
| 19 |
> get something that only works through `emerge`. attempting to restrict it so |
| 20 |
> it only works through `emerge` is unacceptable and it has never been that way. |
| 21 |
|
| 22 |
That's why I suggested a small sh script to source, to setup that environment. |
| 23 |
Personally, I do an awful lot more than that just to build a native chroot, |
| 24 |
let alone cross-compile. And I really don't see the hardship for these brave |
| 25 |
"cross-compilers" of yours in sourcing a small setup script, which can be |
| 26 |
added to ~/.bashrc or even the system-wide one, for anyone who really wants |
| 27 |
it to apply whenever they login. Is this somehow beyond our most advanced |
| 28 |
userbase? |
| 29 |
|
| 30 |
People may install crossdev to get a cross-compile environment, but it's a |
| 31 |
broken design if it's not contained. And BS about how you think it should |
| 32 |
ALWAYS go for everybody, only leads to borked "solutions" elsewhere like |
| 33 |
telling the people on an amd64 install that they have to run some god-awful |
| 34 |
"new" %multilib thing to compile for their secondary ABI. That's just as |
| 35 |
counter-intuitive, when you could just fix your borkage and have a clean |
| 36 |
setup for everyone. |
| 37 |
|
| 38 |
-- |
| 39 |
#friendly-coders -- We're friendly, but we're not /that/ friendly ;-) |
Archives