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

[Markos Chandras <hwoarang@gentoo.org>]

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

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.

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