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

["Anthony G. Basile" <blueness@gentoo.org>]

On 09/17/14 15:41, Markos Chandras wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 09/17/2014 08:13 PM, Anthony G. Basile wrote:
>> On 09/17/14 13:50, Markos Chandras wrote: 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@gentoo.org> 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.
> Well i need to see the structure for your second approach to
> understand what you have in mind. Perhaps the first option is the
> safest and ensure some backwards compatibility with existing mips32 users?

Yes it would be more backwards compat, but it is not semetrical.

The regular (ie glibc) profiles would become:

   [1]   default/linux/mips/13.0/o32 <-change
   [2]   default/linux/mips/13.0/n32
   [3]   default/linux/mips/13.0/n64
   [4]   default/linux/mips/13.0/multilib/o32 <-change
   [5]   default/linux/mips/13.0/multilib/n32
   [6]   default/linux/mips/13.0/multilib/n64
   [7]   default/linux/mips/13.0/mipsel/o32               <- change
   [8]   default/linux/mips/13.0/mipsel/n32
   [9]   default/linux/mips/13.0/mipsel/n64
   [10]  default/linux/mips/13.0/mipsel/multilib/o32     <-change
   [11]  default/linux/mips/13.0/mipsel/multilib/n32
   [12]  default/linux/mips/13.0/mipsel/multilib/n64

The embedded profiles would remain the same since they are o32 only 
(right now):

   [13]  hardened/linux/musl/mips
   [14]  hardened/linux/musl/mips/mipsel
   [15]  default/linux/uclibc/mips
   [16]  hardened/linux/uclibc/mips
   [17]  default/linux/uclibc/mips/mipsel
   [18]  hardened/linux/uclibc/mips/mipsel

I doubt we would ever do a mutlilib musl or uclibc.  But we might have a 
uclibc n32 or n64, in which case we'd repeat the same as above.

>
> - -- 
> Regards,
> Markos Chandras
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQF8BAEBCgBmBQJUGeP/XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
> RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z5msH/1YBYb9trZYGrkXkR0FIcx9Y
> ltJ8PL7jGG1B4NO0PJJpwehMSsxFbkpq3VT9ahrVq4+K58/3XRDmoWGEsWpBIo3o
> KHCmCOoC2KPmGFEXofKsD7iAlb83X5/KsHVhHioUy/5D7JMf4PrPLPjkMtRFU0oR
> h9+hah+3tSMO5QUh4blXnYJ4LeE298GjPJMwPtMlhx4uRUyXeRhUfuINzdf9uMBV
> FFHfJKOfsr9aizUpJxza/Wph+IA+NVGTCekZzWQ6gSZW+MxiF3mAeLFj6I6g+0lI
> Ga8+Z1Bs/JM7P4csLJ2Sp+ccgaIGXg6xU/BtlpKyJl745mpBAt58w17762+ivjs=
> =PqPy
> -----END PGP SIGNATURE-----
>


-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA