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

[Anthony G. Basile]

On 09/17/14 16:13, Markos Chandras wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> On 09/17/2014 08:52 PM, Anthony G. Basile wrote:
>> On 09/17/14 15:41, Markos Chandras wrote: 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@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.
>> 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
> I think that if you symlink the following
>
> default/linux/mips/13.0/eapi -> default/linux/mips/13.0/o32/eapi
> default/linux/mips/13.0/parent -> default/linux/mips/13.0/o32/parent
>
> existing default/linux/mips/13.0/ users will be unaffected. But I am
> not sure if we are allowed to use symlinks (same thing for mipsel)
>
> If we can't avoid it then we can send the usual email to the lists
> informing users for the change. I believe it's not hard for them to
> figure out what changed and how to select the proper profile for their
> mips32 boxes.

Let me test first the new profiles.  I will put them on the 
hardened-dev::profile overlay.  I know they're not hardened, but we do 
testing of big changes to profiles there.  Then you can review what I've 
done.

I'm not sure about the sym links either.


> - --
> Regards,
> Markos Chandras
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQF8BAEBCgBmBQJUGetvXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
> RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8ZA2UH/j9O3h3cuvoFEJnRFvGOoLHF
> c0tQykVpAjcJm4G6fEDLS1+soRl+U8PENxM3cnqEeLWsz9qRTyB9QJCF6s2cg6tr
> /7eUWn3OnFD5jSW9A16BiX0vpKGCdJFz30HDN6zFJpuOj2jhKOeZplNgDICQtJr2
> yBsv7q9rN99MQc/hEQK8tvffIibrVNlNIyKb6YoRuzuPycu5v6thiTFwPSyWh8Q/
> qqdokI024Qg4DqGhwSd1puq2iISaT4xH2Fn6ZgR0pyHFwy0bQx9IRNe0cjZfP2yJ
> biCZqcG0S5VOFv161FbnA3EyutuFIzRJs60EqnyjkezlDvXJqNOmTdePYdS5/T4=
> =TPCw
> -----END PGP SIGNATURE-----
>


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