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. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
