1 |
Dnia 2014-09-13, o godz. 10:47:49 |
2 |
Markos Chandras <hwoarang@g.o> napisał(a): |
3 |
|
4 |
> Here is some weirdness with eg mips64/n32 multilib profile when trying |
5 |
> a world update |
6 |
> |
7 |
> [ebuild U ] sys-devel/libtool-2.4.2-r1:2 [2.4.2:2] |
8 |
> USE="-static-libs {-test} -vanilla" ABI_MIPS="(n32%*) o32%* -n64%" 0 kB |
9 |
> |
10 |
> As you can see n32 and o32 are enabled but n64 is not. Obviously this |
11 |
> is not full mips64 multilib. This is probably due the portage profile |
12 |
> stacking/inheritance problems on mips64, where the mips64/multilib |
13 |
> profiles inherit the default o32 one. Michal (multilib CC'd) can |
14 |
> provide more information on what exactly goes wrong since he |
15 |
> understands the problem better than me. Michal also said that on |
16 |
> amd64, the multilib profiles defaults to 64-bit only. I believe this |
17 |
> contradicts with what someone expects from MIPS64 where all three ABIs |
18 |
> need to be present *by default* unless you override the ABI_MIPS |
19 |
> variable in make.conf. Correct? |
20 |
|
21 |
Well, long story short we inherit from 'top-level' profile that has |
22 |
some o32 settings inside. I believe that it could be saner to move |
23 |
those from arch/mips/mips64 -> arch/mips/mips64/o32 (like we have /n32 |
24 |
and /n64 there), so that instead of having to unset them, we'd just |
25 |
have them set for the relevant real profiles. |
26 |
|
27 |
However, I'm not sure if this doesn't come with some pitfalls. |
28 |
|
29 |
-- |
30 |
Best regards, |
31 |
Michał Górny |