Re: [gentoo-mips] multilib problems on mips64 profiles

[Anthony G. Basile]

On 09/17/14 13:50, Markos Chandras wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 09/17/2014 02:38 PM, Ian Stakenvicius wrote:
>> On 17/09/14 04:31 AM, Micha³ Górny wrote:
>>> Dnia 2014-09-13, o godz. 10:47:49 Markos Chandras
>>> <hwoarang@g.o> napisa³(a):
>>
>>>> Here is some weirdness with eg mips64/n32 multilib profile
>>>> when trying a world update
>>>>
>>>> [ebuild     U  ] sys-devel/libtool-2.4.2-r1:2 [2.4.2:2]
>>>> USE="-static-libs {-test} -vanilla" ABI_MIPS="(n32%*) o32%*
>>>> -n64%" 0 kB
>>>>
>>>> As you can see n32 and o32 are enabled but n64 is not.
>>>> Obviously this is not full mips64 multilib. This is probably
>>>> due the portage profile stacking/inheritance problems on
>>>> mips64, where the mips64/multilib profiles inherit the default
>>>> o32 one. Michal (multilib CC'd) can provide more information on
>>>> what exactly goes wrong since he understands the problem better
>>>> than me. Michal also said that on amd64, the multilib profiles
>>>> defaults to 64-bit only. I believe this contradicts with what
>>>> someone expects from MIPS64 where all three ABIs need to be
>>>> present *by default* unless you override the ABI_MIPS variable
>>>> in make.conf. Correct?
>>
>>> Well, long story short we inherit from 'top-level' profile that
>>> has some o32 settings inside. I believe that it could be saner
>>> to move those from arch/mips/mips64 -> arch/mips/mips64/o32 (like
>>> we have /n32 and /n64 there), so that instead of having to unset
>>> them, we'd just have them set for the relevant real profiles.
>>
>>> However, I'm not sure if this doesn't come with some pitfalls.
>>
>>
>> Blueness and I talked about this (proper n32 / n64 / o32 defaults
>> and forces/masks) in #gentoo-dev two or three weeks ago; I thought
>> we worked out the correct modifications to profiles to get it right
>> and he had already pushed the fixes...  ??
>
> I can't see anything. Did you actually push them? What was decided as
> the plan for action?

I did not have time to get to them.  I was going to play with two 
different approaches.  One is simply turning off o32 at multilib/../n32 
level, the other was to restructure the profiles entirely and put o32, 
n32 and 64 on par, not inherit from a hire level "default" profile.  I'm 
leaning towards that approach, but I'm worried it might play havoc on 
our users.

>
>>
>> Is it just a matter of documenting the full map of exactly what
>> multilib profile should be forced-on and default-on in each, and
>> then either adjusting profiles if they don't match up OR allowing
>> users to select the correct profile for what they want?
>>
>> For example, i'm not understanding why n64 -should- be enabled by
>> default on the mips64/n32 profile??  If you wanted more than
>> {n,o}32 shouldn't you be choosing the base mips64 profile?
>>
>>
> Perhaps it should not but neither should o32
>
> - --
> Regards,
> Markos Chandras
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQF8BAEBCgBmBQJUGcn9XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
> RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZjSIH/3g0y2CTrZrJtmo7n9XvUIBK
> F35WepF3zkkKE6BFxNF1qbLE7OrIUbhERZzn3bDdEz/9vBlE/oMfrV+M2tbdMX77
> rohS5jvAQN5F2TYhdtJBWrDV1PRidfTIx+qAL1IFIw+xNA96Wzyy+TveqRYb6BG5
> jqIHvyNdFu8yZKGp5OEbJgz9Jk/d4bB4cDPkIKbZODWl2aD6iuVO6hvSveB9WQrd
> Rmair7kUi27Drrr8aNd0pt9tF0PFoFM1+Tt1axLXWDHkx3gLsqCEg7fXSKHsoUGO
> kJH8WcWhJiYhK4nN+NJuaBm35UKFpZMY1ac5iA8UoR92QN00NqAeiMa+vMt9u7s=
> =wYWx
> -----END PGP SIGNATURE-----
>


-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
[phone]