| 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 |
Archives