1 |
-----BEGIN PGP SIGNED MESSAGE----- |
2 |
Hash: SHA256 |
3 |
|
4 |
On 26/03/14 12:12 PM, Mike Frysinger wrote: |
5 |
> On Wed 26 Mar 2014 12:25:29 Steven J. Long wrote: |
6 |
>> Mike Frysinger wrote: |
7 |
>>> Greg Turner wrote: |
8 |
>>>> As for how to fix it, if foo-bar-baz-quux crossdev targets |
9 |
>>>> are at ${EROOT}/usr/foo-bar-baz-quux, putting wrappers in |
10 |
>>>> ${EROOT}/usr/foo-bar-baz-quux/cross-wrappers, or something |
11 |
>>>> like that, seems perfectly reasonable... heck, pure |
12 |
>>>> speculation, but it might even noticeably speed up day-to-day |
13 |
>>>> $PATH searching on systems with lots of crossdev targets |
14 |
>>>> installed. |
15 |
>>> |
16 |
>>> if they're in $PATH, then the exact location is irrelevant. |
17 |
>>> they need not be in /usr/bin to cause a problem. if they're not |
18 |
>>> in $PATH, then you're breaking the cross-compilers and that is |
19 |
>>> unacceptable. |
20 |
>> |
21 |
>> Cross-compilation should be supported via cross-emerge, and |
22 |
>> perhaps a small script the cross-compiler sources to setup the |
23 |
>> env (ie prefix to PATH in this case) for using CHOST-* tools, |
24 |
>> like x86-pc-linux-gnu-gcc targetting a straight x86 platform, |
25 |
>> instead of the normal multilib setup. The latter being used by |
26 |
>> the former (I'd have thought it was already done.) |
27 |
>> |
28 |
>> The cross tools should NOT pollute the default PATH, simply |
29 |
>> because the user happened to run crossdev at some point. It's |
30 |
>> *borked*, plain and simple, so fix it please or expect people to |
31 |
>> come up with other solutions [1]; fragmenting the effort, and |
32 |
>> making cross-compilers lives harder, as we try to blend together |
33 |
>> a working solution from various efforts. The exact thing crossdev |
34 |
>> is supposed to answer. |
35 |
> |
36 |
> that's bs. people install crossdev to get a cross-compile |
37 |
> environment, not to get something that only works through `emerge`. |
38 |
> attempting to restrict it so it only works through `emerge` is |
39 |
> unacceptable and it has never been that way. -mike |
40 |
> |
41 |
|
42 |
it -does- make sense though to limit anything that one wants to EMERGE |
43 |
with the crossdev, to require the use of cross-emerge. Would it not |
44 |
be possible to somehow ensure the crossdev tools are ignored |
45 |
in/removed from/cannot pollute the standard emerge environment? Are |
46 |
there any use cases where one -would- want the crossdev to be used in |
47 |
a standard emerge environment instead of using cross-emerge ? |
48 |
|
49 |
|
50 |
|
51 |
|
52 |
-----BEGIN PGP SIGNATURE----- |
53 |
Version: GnuPG v2.0.22 (GNU/Linux) |
54 |
|
55 |
iF4EAREIAAYFAlMy/xkACgkQ2ugaI38ACPClAAD/bwSIWjCu32eDlf3faqnqhvc3 |
56 |
94JxKfSwY3pPv7X4A68A/1g8KSov5e/BHGYXyhlyCd8j3Bc+IukxoNYMXiXiluh7 |
57 |
=TMGw |
58 |
-----END PGP SIGNATURE----- |