1 |
I seem to recall that, at some point not too long ago, prefix was multilib |
2 |
compatible, before the current masking occurred. |
3 |
|
4 |
|
5 |
|
6 |
In my ongoing experimentation with crossdev under prefix, thus far I am not |
7 |
able to build multilib cross-gcc's from the no-multilib profile. I don't |
8 |
know, right now, if the same problem applies to non-prefixed gentoo installs |
9 |
(if someone wanted to test that out for me I'd be much obliged). In prefix |
10 |
what I'm seeing is that attempts to build the stage2 (crossdev stage 2) gcc |
11 |
fail building the non-default-abi gcclib. It's a link failure that occurs |
12 |
due to the lack of any non-default-abi-libdir on the library paths generated |
13 |
in the build/gcclib/32 Makefile. |
14 |
|
15 |
|
16 |
|
17 |
Anyhow, I'm wondering, is there somebody out there who knows what is behind |
18 |
the decision to mask multilib in prefix-portage (or made it themselves), and |
19 |
what it would take to fix it? By any chance, does the limitation pertain to |
20 |
mostly to gcc-config and the special prefix magic that happens in the |
21 |
dynamically generated gcc wrappers? |
22 |
|
23 |
|
24 |
|
25 |
Because, going forward, it seems like that's a problem we need to fix, |
26 |
anyhow, due to the no-multilib profile deprecation. I don't know if that |
27 |
also explains the inability to build the multilib cross-gcc's, or not, but |
28 |
it does seem that, going forward, a no-multilib requirement is not an |
29 |
albatross we want around prefix-portage's neck. |
30 |
|
31 |
|
32 |
|
33 |
Now that bleeding-edge GNU toolchains are starting to support sysroot and |
34 |
relocatable toolchains, perhaps we could start disentangling or |
35 |
conditionalizing prefix-portage's reliance on the gcc-wrappers, and this |
36 |
would begin to relieve whatever forces are pushing us into this no-multilib |
37 |
corner? Or am I barking up the wrong tree with that? |
38 |
|
39 |
|
40 |
|
41 |
Eager to hear your thoughts, |
42 |
|
43 |
|
44 |
|
45 |
-gmt |