1 |
Dnia 2014-06-21, o godz. 03:31:30 |
2 |
Greg Turner <gmt@×××××.us> napisał(a): |
3 |
|
4 |
> On Fri, Jun 20, 2014 at 1:10 PM, Ian Stakenvicius <axs@g.o> wrote: |
5 |
> > Thoughts [about wrapping gcc, so that non-native multilib-build ABI's can |
6 |
> finally return to a world where [[ ${GCC} != *' '* ]] ]? |
7 |
> |
8 |
> TLDR: good idea, I'm strongly in favor of it. |
9 |
> |
10 |
> A wrapper would fix horrors like the following, which, last I checked, was |
11 |
> sort-of required* on ABI_X86="*32*" DEFAULT_ABI="amd64" systems with |
12 |
> crossdev i686-pc-linux-gnu targets in ${PATH}: |
13 |
> |
14 |
> [...] |
15 |
> |
16 |
> But, it's not just that cmake can't properly handle a C{C,XX} variables |
17 |
> with spaces in them**. There are a bunch of similar places where we had to |
18 |
> patch Makefiles and autotools to wedge GCC="foo bar" support in. |
19 |
|
20 |
I wasn't aware of that. |
21 |
|
22 |
I honestly would love if toolchain cooperated with us on bringing this. |
23 |
However, I'm a bit pessimistic about their willing. For one, we'd first |
24 |
have to fix all multilib arches to use different CHOSTs for |
25 |
different ABIs -- and so far, people prefer inventing some custom hacks |
26 |
in the name of keeping status quo. |
27 |
|
28 |
As far as multilib builds are concerned, I guess I could create |
29 |
${T}/bin with proper wrappers. We do similar thing in python-r1 suite |
30 |
already to make sure that all 'python[23]' calls behave correctly. Of |
31 |
course, this will still require fixing CHOSTs and work only for |
32 |
multilib ebuilds. But on the other hand, it would allow us to avoid |
33 |
masking crossdev. |
34 |
|
35 |
-- |
36 |
Best regards, |
37 |
Michał Górny |