* Re: [gentoo-mips] multilib problems on mips64 profiles
@ 2014-09-21 21:55 99% ` Anthony G. Basile
0 siblings, 0 replies; 1+ results
From: Anthony G. Basile @ 2014-09-21 21:55 UTC (permalink / raw
To: gentoo-mips
On 09/17/14 16:19, Anthony G. Basile wrote:
> 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@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.
>
> 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.
>
This isn't going to work. The problem is that the above structure
doesn't distinguish between mips/o32 and mips64/o32 (and equivalent el
versions). Now mips64/o32 is funny, but possible: it would be o32 (a
32-bit abi) on 64 bit arch/kernel, like ppc64-32ul. The structure is
possible at the level of profile/arch, but it would mean a deep
restructuring of default/linux/mips/13.0.
I'm not sure we want to make such a deep change. The profiles we would
present to the user would look like:
[1] default/linux/mips/13.0/mips/o32
default/linux/mips/13.0/mips64/o32 <- distinguish the
mips/o32 and mips64/o32
[2] default/linux/mips/13.0/mips64/n32
[3] default/linux/mips/13.0/mips64/n64
[4] default/linux/mips/13.0/multilib/o32 <- multilib is
necessarily mips64
[5] default/linux/mips/13.0/multilib/n32 <- multilib is
necessarily mips64
[6] default/linux/mips/13.0/multilib/n64 <- multilib is
necessarily mips64
[7] default/linux/mips/13.0/mipsel/o32
default/linux/mips/13.0/mips64el/o32 <- distinguish the
mipsel/o32 and mips64el/o32
[8] default/linux/mips/13.0/mips64el/n32
[9] default/linux/mips/13.0/mips64el/n64
[10] default/linux/mips/13.0/mipsel/multilib/o32 <- multilib is
necessarily mips64el
[11] default/linux/mips/13.0/mipsel/multilib/n32 <- multilib is
necessarily mips64el
[12] default/linux/mips/13.0/mipsel/multilib/n64 <- multilib is
necessarily mips64el
No need to touch the rest.
[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
Maybe we just don't want to support mips64/o32? I'm starting to lean
towards Ian's simple but asymmetric solution of turning off o32 in the
inheriting profiles.
--
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
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2014-09-13 9:47 [gentoo-mips] multilib problems on mips64 profiles Markos Chandras
2014-09-17 8:31 ` Michał Górny
[not found] ` <54198ECB.7010803@gentoo.org>
2014-09-17 17:50 ` Markos Chandras
2014-09-17 19:13 ` Anthony G. Basile
2014-09-17 19:41 ` Markos Chandras
2014-09-17 19:52 ` Anthony G. Basile
2014-09-17 20:13 ` Markos Chandras
2014-09-17 20:19 ` Anthony G. Basile
2014-09-21 21:55 99% ` Anthony G. Basile
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox