[gentoo-mips] multilib problems on mips64 profiles

[gentoo-mips] multilib problems on mips64 profiles

[Markos Chandras]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Hi,

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?

- -- 
Regards,
Markos Chandras
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQF8BAEBCgBmBQJUFBLFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z6JQH/AkuGs0pE5mshn/pGiz3cb/p
43Ksh/ZBd7z9gB54o/QeK/GnqxgkG5y4koX0rs+35SAjYCkYS3Nc7Aa0DSA0o/Mz
z6FGkOxBRBwb6jmJ8ujKYZXC6rMgHY1kA9xx2qLK+WplIsLE5tx/Tsixqa4/6XuK
28BN41A1W4kaeB9Rtlv9Mt9OFEfTPiUqSkzyHpm1fKT60O6kq0Jba3Mh15w7IKJn
HUWCy92doVpcpip+wn//reoV+logtRL8616juHGNVRMXN4ZuLHl99IJXzjh/4Fu2
9KOb+H7NgpSQIUklg8l8XV577dZAYOaZUp+sqgu0ymbZmmO1mOButiOceXxAh/Q=
=8P/6
-----END PGP SIGNATURE-----

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

[Anthony G. Basile]

On 09/13/14 05:47, Markos Chandras wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA512
>
> Hi,
>
> 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?
>
> - -- 
> Regards,
> Markos Chandras
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v2
>
> iQF8BAEBCgBmBQJUFBLFXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w
> ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRGRDlGMzA4MUI2MzBDODQ4RDBGOEYxMjQx
> RjEwRUQ0QjgxREVCRjE5AAoJEB8Q7UuB3r8Z6JQH/AkuGs0pE5mshn/pGiz3cb/p
> 43Ksh/ZBd7z9gB54o/QeK/GnqxgkG5y4koX0rs+35SAjYCkYS3Nc7Aa0DSA0o/Mz
> z6FGkOxBRBwb6jmJ8ujKYZXC6rMgHY1kA9xx2qLK+WplIsLE5tx/Tsixqa4/6XuK
> 28BN41A1W4kaeB9Rtlv9Mt9OFEfTPiUqSkzyHpm1fKT60O6kq0Jba3Mh15w7IKJn
> HUWCy92doVpcpip+wn//reoV+logtRL8616juHGNVRMXN4ZuLHl99IJXzjh/4Fu2
> 9KOb+H7NgpSQIUklg8l8XV577dZAYOaZUp+sqgu0ymbZmmO1mOButiOceXxAh/Q=
> =8P/6
> -----END PGP SIGNATURE-----
>

Yes I know the issue but have not gotten around to fixing it and won't 
anytime soon since I' struggling with real life (like getting the 
electric company to fix my power!)

I don't agree that we want all three abi's by default on all binaries.  
What we want is the three abis for the toolchain, and the option to turn 
on/off the other abis besides the default abi which should be on.  
Ideally this should be

     ABI_MIPS="(n32%*) -o32%* -n64%"

Needs to be done is

1) add -abi_mips_o32 to use.force in 
/usr/portage/profiles/arch/mips/mips64/n32 and similarly for the other 
profiles.  This allows one to turn off o32, otherwise its forced on.

2) add USE="${USE} -abi_mips_o32" to make.default.  This turns it off by 
default, but the user can turn it back on.

You should do this for all the mips64/multilibs and mips64el's.

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

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

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 1416 bytes --]

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.

-- 
Best regards,
Michał Górny

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

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

[Markos Chandras]

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

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

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

>
>>
>> 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
(716) 829-8197

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

[Markos Chandras]

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

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

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

[Anthony G. Basile]

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

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

[Markos Chandras]

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

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


> - -- 
> 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@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

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

[Anthony G. Basile]

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

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

[Matt Turner]

On Sun, Sep 21, 2014 at 2:55 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
> 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.

Either of those seem like fine solutions to me.

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

[Anthony G. Basile]

On 09/21/14 18:45, Matt Turner wrote:
> On Sun, Sep 21, 2014 at 2:55 PM, Anthony G. Basile <blueness@gentoo.org> wrote:
>> 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.
>
> Either of those seem like fine solutions to me.
>

Right now I'm testing the first option.  If you want to test too, clone 
the hardened-dev overlay and switch to the profiles branch.  Then do

mount --bind hardened-dev/profiles /usr/portage/profiles

and eselect profiles as usual.  It'll take me a bit, but if we like it, 
then I'll make the switch.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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

[Joshua Kinard]

On 09/21/2014 17:55, Anthony G. Basile wrote:
> On 09/17/14 16:19, Anthony G. Basile wrote:
[snip]
> 
> 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.

Err, I've been using this setup for the last 9+ years?  My Octane and O2 both
boot mips64 kernels and run an o32-only userland.  It works fine with the
current profile setup.  You just use a mips-unknown-linux-gnu CHOST.  I may not
be able to fully utilize all of the CPU registers like I would under n32, but
that's never been an issue for me.

So there should be no need to differentiate at the userland level between
mips/o32 and mips64/o32.  As long as the CHOST is set correctly, o32 will work
fine under a mips64 kernel (caveat: make sure CONFIG_MIPS32_O32 is set in the
kernel).

Correct me if wrong, but it seems the core problem here is that multilib
inherits from the o32 base profile.  While I think the proper longterm fix is
to have more discrete, modular/pluggable profile components (like OOP and
multiple base classes), that's not going to happen in Portage for a long time.

So I think the solution is to split the profiles into "mips" and "mips64",
i.e., 32/ and 64/ under the 'mips' base profile folder.  32/ contains
everything needed to run pure o32-only under either a mips or mips64 kernel.
I.e., mips-unknown-linux-gnu CHOST.  So on my Octane, /etc/portage/make.profile
symlinks to /usr/portage/default/linux/mips/32/<VERSION>/

64/ is where the fun is at.  I think the default ABI there should be n32 at the
base, with a subprofile for multilib that itself contains subprofiles to handle
the combinations of ABIs desired.  Still have to workout what CHOST you use for
the base (GNU standard for n32 is mips64-unknown-linux-gnueabin32).  multilib
would just use mips64-unknown-linux-gnu, and -mabi would be passed to gcc to
pick the ABI to build for.

Also, if we are going to do any kind of reorganizing of the profiles, let's not
do it under 13.0.  Personally, I'd like to get away from datestamps as profile
versions (13.0 refers to 2013) and either pick a fixed version number that we
increment or come up with some other kind of versioning scheme.  Or just do
away with it altogether and have something like a "stable" profile where things
work and an "unstable" branch that only exists when we're doing insane changes
to the profiles, which after testing, becomes "stable" (and current "stable"
becomes "oldstable" or such).

If we have to stick with datestamped versions, then use 15.0.  Cause it'll be
2015 by the time this goes active.

rough draft of the top-level layout.  Doesn't care about chosen libc, ISA, or
<VERSION>, but does reflect endianness.

default/linux/mips
   |
   |-32/
   |  |-be/
   |  |-le/
   |
   |-64/
   |  |-be/
   |  |-le/
   |  |
   |  |-multilib/
   |  |  |-be/
   |  |  |-le/
   |  |
   |


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

NAK

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[Anthony G. Basile]

On 09/21/14 18:53, Joshua Kinard wrote:
> On 09/21/2014 17:55, Anthony G. Basile wrote:
>> On 09/17/14 16:19, Anthony G. Basile wrote:
> [snip]
>>
>> 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.
>
> Err, I've been using this setup for the last 9+ years?  My Octane and O2 both
> boot mips64 kernels and run an o32-only userland.  It works fine with the
> current profile setup.  You just use a mips-unknown-linux-gnu CHOST.  I may not
> be able to fully utilize all of the CPU registers like I would under n32, but
> that's never been an issue for me.
>
> So there should be no need to differentiate at the userland level between
> mips/o32 and mips64/o32.  As long as the CHOST is set correctly, o32 will work
> fine under a mips64 kernel (caveat: make sure CONFIG_MIPS32_O32 is set in the
> kernel).

I agree that there shouldn't be any userland difference, but I'm not 
100% sure.  Anyhow, let's go with that assumption for now.

>
> Correct me if wrong, but it seems the core problem here is that multilib
> inherits from the o32 base profile.  While I think the proper longterm fix is
> to have more discrete, modular/pluggable profile components (like OOP and
> multiple base classes), that's not going to happen in Portage for a long time.

Not exactly.  The problem is that everything inherits from 
profiles/arch/mips and currently that forces o32 with mgorny's multilib 
stuff.  We need to get that out of the way for the other profiles that 
inherit it.

>
> So I think the solution is to split the profiles into "mips" and "mips64",
> i.e., 32/ and 64/ under the 'mips' base profile folder.  32/ contains
> everything needed to run pure o32-only under either a mips or mips64 kernel.
> I.e., mips-unknown-linux-gnu CHOST.  So on my Octane, /etc/portage/make.profile
> symlinks to /usr/portage/default/linux/mips/32/<VERSION>/

That's one approach, but I'm trying to find the least intrusive. I do 
have the problem fixed with the following:

   [1]   default/linux/mips/13.0/o32
   [2]   default/linux/mips/13.0/n32
   [3]   default/linux/mips/13.0/n64
   [4]   default/linux/mips/13.0/multilib/o32
   [5]   default/linux/mips/13.0/multilib/n32
   [6]   default/linux/mips/13.0/multilib/n64
   [7]   default/linux/mips/13.0/mipsel/o32
   [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
   [11]  default/linux/mips/13.0/mipsel/multilib/n32
   [12]  default/linux/mips/13.0/mipsel/multilib/n64

and would like to push this through as a fix for now.  1 and 4 have 
CHOST=mips-unknown-linux-gnu and mipsel-unknown-linux-gnu respectively. 
  2,3 and 8,9 have mips64-unknown-linux-gnu and 
mips64el-unknown-linux-gnu respectively.  Only users of profiles 1 and 7 
need to change their sym link one level down to ../o32.  That was 
necessary to move the o32 stuff out of the way of profiles/arch/mips.

>
> 64/ is where the fun is at.  I think the default ABI there should be n32 at the
> base, with a subprofile for multilib that itself contains subprofiles to handle
> the combinations of ABIs desired.  Still have to workout what CHOST you use for
> the base (GNU standard for n32 is mips64-unknown-linux-gnueabin32).  multilib
> would just use mips64-unknown-linux-gnu, and -mabi would be passed to gcc to
> pick the ABI to build for.
>
> Also, if we are going to do any kind of reorganizing of the profiles, let's not
> do it under 13.0.  Personally, I'd like to get away from datestamps as profile
> versions (13.0 refers to 2013) and either pick a fixed version number that we
> increment or come up with some other kind of versioning scheme.  Or just do
> away with it altogether and have something like a "stable" profile where things
> work and an "unstable" branch that only exists when we're doing insane changes
> to the profiles, which after testing, becomes "stable" (and current "stable"
> becomes "oldstable" or such).
>
> If we have to stick with datestamped versions, then use 15.0.  Cause it'll be
> 2015 by the time this goes active.
>
> rough draft of the top-level layout.  Doesn't care about chosen libc, ISA, or
> <VERSION>, but does reflect endianness.
>
> default/linux/mips
>     |
>     |-32/
>     |  |-be/
>     |  |-le/
>     |
>     |-64/
>     |  |-be/
>     |  |-le/
>     |  |
>     |  |-multilib/
>     |  |  |-be/
>     |  |  |-le/
>     |  |
>     |
>

I like this, but the problem is disentangling the situation under 
arch/mips, not under default/linux/mips.  Again, the inheritance problem 
stems from everything under profiles/arch/mips inheriting from 
profiles/arch/mips.  So even if you do implement the above, you still 
have to address the issue of how the arch/mips stuff is stacking.

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

I'm leaning back towards the above approach and not Ian's.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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

[Anthony G. Basile]

On 09/21/14 21:11, Anthony G. Basile wrote:
>> Correct me if wrong, but it seems the core problem here is that multilib
>> inherits from the o32 base profile.  While I think the proper longterm
>> fix is
>> to have more discrete, modular/pluggable profile components (like OOP and
>> multiple base classes), that's not going to happen in Portage for a
>> long time.
>
> Not exactly.  The problem is that everything inherits from
> profiles/arch/mips and currently that forces o32 with mgorny's multilib
> stuff.  We need to get that out of the way for the other profiles that
> inherit it.

Oh wait, maybe we mean the same thing here.  I'm not sure.  When you say 
the same base profile, do you mean profile/arch/mips?  In that case we 
are saying the same thing.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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

[Joshua Kinard]

On 09/21/2014 21:12, Anthony G. Basile wrote:
> On 09/21/14 21:11, Anthony G. Basile wrote:
>>> Correct me if wrong, but it seems the core problem here is that multilib
>>> inherits from the o32 base profile.  While I think the proper longterm
>>> fix is
>>> to have more discrete, modular/pluggable profile components (like OOP and
>>> multiple base classes), that's not going to happen in Portage for a
>>> long time.
>>
>> Not exactly.  The problem is that everything inherits from
>> profiles/arch/mips and currently that forces o32 with mgorny's multilib
>> stuff.  We need to get that out of the way for the other profiles that
>> inherit it.
> 
> Oh wait, maybe we mean the same thing here.  I'm not sure.  When you say the
> same base profile, do you mean profile/arch/mips?  In that case we are saying
> the same thing.

I actually forgot about arch/mips in the profiles.  I'll have to dig around in
there later on.  I assumed we (the MIPS team) managed everything MIPS in the
tree, since -embedded used to compartmentalize everything under their embedded
profiles.

The modular profiles bit is a longterm item.  I don't know if this mixins thing
will correct our issues or not.  If not, I may just have to dive into Portage
and write my own profile-parsing code and try my modular idea out to see if
that really does solve nay problems.

-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[Anthony G. Basile]

On 09/21/14 21:29, Joshua Kinard wrote:
> On 09/21/2014 21:12, Anthony G. Basile wrote:
>> On 09/21/14 21:11, Anthony G. Basile wrote:
>>>> Correct me if wrong, but it seems the core problem here is that multilib
>>>> inherits from the o32 base profile.  While I think the proper longterm
>>>> fix is
>>>> to have more discrete, modular/pluggable profile components (like OOP and
>>>> multiple base classes), that's not going to happen in Portage for a
>>>> long time.
>>>
>>> Not exactly.  The problem is that everything inherits from
>>> profiles/arch/mips and currently that forces o32 with mgorny's multilib
>>> stuff.  We need to get that out of the way for the other profiles that
>>> inherit it.
>>
>> Oh wait, maybe we mean the same thing here.  I'm not sure.  When you say the
>> same base profile, do you mean profile/arch/mips?  In that case we are saying
>> the same thing.
>
> I actually forgot about arch/mips in the profiles.  I'll have to dig around in
> there later on.  I assumed we (the MIPS team) managed everything MIPS in the
> tree, since -embedded used to compartmentalize everything under their embedded
> profiles.
>
> The modular profiles bit is a longterm item.  I don't know if this mixins thing
> will correct our issues or not.  If not, I may just have to dive into Portage
> and write my own profile-parsing code and try my modular idea out to see if
> that really does solve nay problems.
>

The mixins can help this issue but will not correct it.  The problem is 
the current inheritance model is so uncontrollable.  Everything I do is 
always so-so.  I can never get it right.  I would love it if we just did 
away with parent files and stacked manually in the last profile that we 
export to the user.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197

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

[Joshua Kinard]

On 09/21/2014 21:11, Anthony G. Basile wrote:
> On 09/21/14 18:53, Joshua Kinard wrote:
>> On 09/21/2014 17:55, Anthony G. Basile wrote:
>>> On 09/17/14 16:19, Anthony G. Basile wrote:
>> [snip]
>>>
>>> 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.
>>
>> Err, I've been using this setup for the last 9+ years?  My Octane and O2 both
>> boot mips64 kernels and run an o32-only userland.  It works fine with the
>> current profile setup.  You just use a mips-unknown-linux-gnu CHOST.  I may not
>> be able to fully utilize all of the CPU registers like I would under n32, but
>> that's never been an issue for me.
>>
>> So there should be no need to differentiate at the userland level between
>> mips/o32 and mips64/o32.  As long as the CHOST is set correctly, o32 will work
>> fine under a mips64 kernel (caveat: make sure CONFIG_MIPS32_O32 is set in the
>> kernel).
> 
> I agree that there shouldn't be any userland difference, but I'm not 100%
> sure.  Anyhow, let's go with that assumption for now.

There isn't.  If there is a difference that can be detected (meaning, with a
machine that can run in 32-bit or 64-bit mode with the same userland), then
you're looking at a kernel problem and that would get handled via upstream
channels.  You're actually at a big disadvantage running o32 under a 64-bit
kernel, because of not being able to use all of the registers in the CPU, can
only pass the first four function args via registers (8 in n32), etc.  o32 is
for all intents and purposes, the MIPS-I and MIPS-II ISAs, which are core to
the overall ISA set, and so all MIPS CPUs to date should (in theory, because I
do not have access to mips64r* hardware) run o32 just fine.

You can compile o32 with higher ISAs, i.e., mips3 and mips4, but it's always
been debatable how much extra that helps you (Debian used to question our logic
on this back in the day).  Can't use 64-bit features of 64-bit CPUs via that,
but it is supposed to enable things like the square-root instructions available
at the mips4 level.

The only reason I'm still running o32 is I just haven't been motivated enough
to do a full re-install of both systems.  Even if I switch to n32, I'll
probably keep o32 chroots around just to make sure things don't break there.
Might do this soon, though, as I just bought ten new hard drives for all of my
MIPS systems.  Just need to get the right brackets for them (because they're
2.5" 10K SCA drives) so I can mount everything and do data migration.


>>
>> Correct me if wrong, but it seems the core problem here is that multilib
>> inherits from the o32 base profile.  While I think the proper longterm fix is
>> to have more discrete, modular/pluggable profile components (like OOP and
>> multiple base classes), that's not going to happen in Portage for a long time.
> 
> Not exactly.  The problem is that everything inherits from profiles/arch/mips
> and currently that forces o32 with mgorny's multilib stuff.  We need to get
> that out of the way for the other profiles that inherit it.
> 

Agreed.  This worked fine in the past when o32 was our primary focus and
n32/n64 were still experimental (and multilib didn't exist).  Nowadays, the
base profile shouldn't prescribe a default ABI at all.  That needs to be
handled under a subprofile somehow.

The real problem is Portage's stacking profiles feature, while soving a lot of
problems that the previous profile system had, wasn't thought up with all of
MIPS' happyfun included.  Because endianness, ABI, ISA, kernel, libc, compiler,
and even specific machine support can all be interchangeable in MIPS, this
causes the stacking profile system to become a thing that would frighten
Yog-Sothoth itself, if we were to fully implement all of the combinations
possible under this system.


>> So I think the solution is to split the profiles into "mips" and "mips64",
>> i.e., 32/ and 64/ under the 'mips' base profile folder.  32/ contains
>> everything needed to run pure o32-only under either a mips or mips64 kernel.
>> I.e., mips-unknown-linux-gnu CHOST.  So on my Octane, /etc/portage/make.profile
>> symlinks to /usr/portage/default/linux/mips/32/<VERSION>/
> 
> That's one approach, but I'm trying to find the least intrusive. I do have the
> problem fixed with the following:
> 
>   [1]   default/linux/mips/13.0/o32
>   [2]   default/linux/mips/13.0/n32
>   [3]   default/linux/mips/13.0/n64
>   [4]   default/linux/mips/13.0/multilib/o32
>   [5]   default/linux/mips/13.0/multilib/n32
>   [6]   default/linux/mips/13.0/multilib/n64
>   [7]   default/linux/mips/13.0/mipsel/o32
>   [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
>   [11]  default/linux/mips/13.0/mipsel/multilib/n32
>   [12]  default/linux/mips/13.0/mipsel/multilib/n64
> 
> and would like to push this through as a fix for now.  1 and 4 have
> CHOST=mips-unknown-linux-gnu and mipsel-unknown-linux-gnu respectively.  2,3
> and 8,9 have mips64-unknown-linux-gnu and mips64el-unknown-linux-gnu
> respectively.  Only users of profiles 1 and 7 need to change their sym link one
> level down to ../o32.  That was necessary to move the o32 stuff out of the way
> of profiles/arch/mips.

This sounds reasonable.  I've got the Octane tasked again on building glibc to
hunt down the R10000 bug I've been stuck on for the past three months, but I
can sync later and test this under your hardened overlay...maybe.  I just tried
overlays on Gentoo/FreeBSD for nigoro's 9.3 profiles and gave up in utter
frustration.

I still think these need to be under a separate versioned directory structure,
though.  14.0/ or 15.0/ or testing/ or pikachu/, whatever.  Then we mark 13.0
as deprecated and allow time for users to migrate off before purging them out
of the tree in a month or two.  It makes for a messy commit (thanks, CVS), but
it avoids breaking people's systems out there who may not be on this mailing list.

Also, we should get a news item added as well, specific to MIPS systems only.


>>
>> 64/ is where the fun is at.  I think the default ABI there should be n32 at the
>> base, with a subprofile for multilib that itself contains subprofiles to handle
>> the combinations of ABIs desired.  Still have to workout what CHOST you use for
>> the base (GNU standard for n32 is mips64-unknown-linux-gnueabin32).  multilib
>> would just use mips64-unknown-linux-gnu, and -mabi would be passed to gcc to
>> pick the ABI to build for.
>>
>> Also, if we are going to do any kind of reorganizing of the profiles, let's not
>> do it under 13.0.  Personally, I'd like to get away from datestamps as profile
>> versions (13.0 refers to 2013) and either pick a fixed version number that we
>> increment or come up with some other kind of versioning scheme.  Or just do
>> away with it altogether and have something like a "stable" profile where things
>> work and an "unstable" branch that only exists when we're doing insane changes
>> to the profiles, which after testing, becomes "stable" (and current "stable"
>> becomes "oldstable" or such).
>>
>> If we have to stick with datestamped versions, then use 15.0.  Cause it'll be
>> 2015 by the time this goes active.
>>
>> rough draft of the top-level layout.  Doesn't care about chosen libc, ISA, or
>> <VERSION>, but does reflect endianness.
>>
>> default/linux/mips
>>     |
>>     |-32/
>>     |  |-be/
>>     |  |-le/
>>     |
>>     |-64/
>>     |  |-be/
>>     |  |-le/
>>     |  |
>>     |  |-multilib/
>>     |  |  |-be/
>>     |  |  |-le/
>>     |  |
>>     |
>>
> 
> I like this, but the problem is disentangling the situation under arch/mips,
> not under default/linux/mips.  Again, the inheritance problem stems from
> everything under profiles/arch/mips inheriting from profiles/arch/mips.  So
> even if you do implement the above, you still have to address the issue of how
> the arch/mips stuff is stacking.

I'll poke around arch/mips later and see if some of this can't be extruded
there.  I don't know if arch/mips is for us exclusively, or if we share it with
a few other project teams (other than -embedded -- do we have an OpenBSD MIPS
team or such??).


-- 
Joshua Kinard
Gentoo/MIPS
kumba@gentoo.org
4096R/D25D95E3 2011-03-28

"The past tempts us, the present confuses us, the future frightens us.  And our
lives slip away, moment by moment, lost in that vast, terrible in-between."

--Emperor Turhan, Centauri Republic

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

[Anthony G. Basile]

On 09/21/14 21:49, Joshua Kinard wrote:
> On 09/21/2014 21:11, Anthony G. Basile wrote:
>> On 09/21/14 18:53, Joshua Kinard wrote:
>>> On 09/21/2014 17:55, Anthony G. Basile wrote:
>>>> On 09/17/14 16:19, Anthony G. Basile wrote:
>>> [snip]
>>>>
>>>> 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.
>>>
>>> Err, I've been using this setup for the last 9+ years?  My Octane and O2 both
>>> boot mips64 kernels and run an o32-only userland.  It works fine with the
>>> current profile setup.  You just use a mips-unknown-linux-gnu CHOST.  I may not
>>> be able to fully utilize all of the CPU registers like I would under n32, but
>>> that's never been an issue for me.
>>>
>>> So there should be no need to differentiate at the userland level between
>>> mips/o32 and mips64/o32.  As long as the CHOST is set correctly, o32 will work
>>> fine under a mips64 kernel (caveat: make sure CONFIG_MIPS32_O32 is set in the
>>> kernel).
>>
>> I agree that there shouldn't be any userland difference, but I'm not 100%
>> sure.  Anyhow, let's go with that assumption for now.
>
> There isn't.  If there is a difference that can be detected (meaning, with a
> machine that can run in 32-bit or 64-bit mode with the same userland), then
> you're looking at a kernel problem and that would get handled via upstream
> channels.  You're actually at a big disadvantage running o32 under a 64-bit
> kernel, because of not being able to use all of the registers in the CPU, can
> only pass the first four function args via registers (8 in n32), etc.  o32 is
> for all intents and purposes, the MIPS-I and MIPS-II ISAs, which are core to
> the overall ISA set, and so all MIPS CPUs to date should (in theory, because I
> do not have access to mips64r* hardware) run o32 just fine.
>
> You can compile o32 with higher ISAs, i.e., mips3 and mips4, but it's always
> been debatable how much extra that helps you (Debian used to question our logic
> on this back in the day).  Can't use 64-bit features of 64-bit CPUs via that,
> but it is supposed to enable things like the square-root instructions available
> at the mips4 level.
>
> The only reason I'm still running o32 is I just haven't been motivated enough
> to do a full re-install of both systems.  Even if I switch to n32, I'll
> probably keep o32 chroots around just to make sure things don't break there.
> Might do this soon, though, as I just bought ten new hard drives for all of my
> MIPS systems.  Just need to get the right brackets for them (because they're
> 2.5" 10K SCA drives) so I can mount everything and do data migration.
>
>
>>>
>>> Correct me if wrong, but it seems the core problem here is that multilib
>>> inherits from the o32 base profile.  While I think the proper longterm fix is
>>> to have more discrete, modular/pluggable profile components (like OOP and
>>> multiple base classes), that's not going to happen in Portage for a long time.
>>
>> Not exactly.  The problem is that everything inherits from profiles/arch/mips
>> and currently that forces o32 with mgorny's multilib stuff.  We need to get
>> that out of the way for the other profiles that inherit it.
>>
>
> Agreed.  This worked fine in the past when o32 was our primary focus and
> n32/n64 were still experimental (and multilib didn't exist).  Nowadays, the
> base profile shouldn't prescribe a default ABI at all.  That needs to be
> handled under a subprofile somehow.
>
> The real problem is Portage's stacking profiles feature, while soving a lot of
> problems that the previous profile system had, wasn't thought up with all of
> MIPS' happyfun included.  Because endianness, ABI, ISA, kernel, libc, compiler,
> and even specific machine support can all be interchangeable in MIPS, this
> causes the stacking profile system to become a thing that would frighten
> Yog-Sothoth itself, if we were to fully implement all of the combinations
> possible under this system.
>
>
>>> So I think the solution is to split the profiles into "mips" and "mips64",
>>> i.e., 32/ and 64/ under the 'mips' base profile folder.  32/ contains
>>> everything needed to run pure o32-only under either a mips or mips64 kernel.
>>> I.e., mips-unknown-linux-gnu CHOST.  So on my Octane, /etc/portage/make.profile
>>> symlinks to /usr/portage/default/linux/mips/32/<VERSION>/
>>
>> That's one approach, but I'm trying to find the least intrusive. I do have the
>> problem fixed with the following:
>>
>>    [1]   default/linux/mips/13.0/o32
>>    [2]   default/linux/mips/13.0/n32
>>    [3]   default/linux/mips/13.0/n64
>>    [4]   default/linux/mips/13.0/multilib/o32
>>    [5]   default/linux/mips/13.0/multilib/n32
>>    [6]   default/linux/mips/13.0/multilib/n64
>>    [7]   default/linux/mips/13.0/mipsel/o32
>>    [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
>>    [11]  default/linux/mips/13.0/mipsel/multilib/n32
>>    [12]  default/linux/mips/13.0/mipsel/multilib/n64
>>
>> and would like to push this through as a fix for now.  1 and 4 have
>> CHOST=mips-unknown-linux-gnu and mipsel-unknown-linux-gnu respectively.  2,3
>> and 8,9 have mips64-unknown-linux-gnu and mips64el-unknown-linux-gnu
>> respectively.  Only users of profiles 1 and 7 need to change their sym link one
>> level down to ../o32.  That was necessary to move the o32 stuff out of the way
>> of profiles/arch/mips.
>
> This sounds reasonable.  I've got the Octane tasked again on building glibc to
> hunt down the R10000 bug I've been stuck on for the past three months, but I
> can sync later and test this under your hardened overlay...maybe.  I just tried
> overlays on Gentoo/FreeBSD for nigoro's 9.3 profiles and gave up in utter
> frustration.
>
> I still think these need to be under a separate versioned directory structure,
> though.  14.0/ or 15.0/ or testing/ or pikachu/, whatever.  Then we mark 13.0
> as deprecated and allow time for users to migrate off before purging them out
> of the tree in a month or two.  It makes for a messy commit (thanks, CVS), but
> it avoids breaking people's systems out there who may not be on this mailing list.
>
> Also, we should get a news item added as well, specific to MIPS systems only.
>
>
>>>
>>> 64/ is where the fun is at.  I think the default ABI there should be n32 at the
>>> base, with a subprofile for multilib that itself contains subprofiles to handle
>>> the combinations of ABIs desired.  Still have to workout what CHOST you use for
>>> the base (GNU standard for n32 is mips64-unknown-linux-gnueabin32).  multilib
>>> would just use mips64-unknown-linux-gnu, and -mabi would be passed to gcc to
>>> pick the ABI to build for.
>>>
>>> Also, if we are going to do any kind of reorganizing of the profiles, let's not
>>> do it under 13.0.  Personally, I'd like to get away from datestamps as profile
>>> versions (13.0 refers to 2013) and either pick a fixed version number that we
>>> increment or come up with some other kind of versioning scheme.  Or just do
>>> away with it altogether and have something like a "stable" profile where things
>>> work and an "unstable" branch that only exists when we're doing insane changes
>>> to the profiles, which after testing, becomes "stable" (and current "stable"
>>> becomes "oldstable" or such).
>>>
>>> If we have to stick with datestamped versions, then use 15.0.  Cause it'll be
>>> 2015 by the time this goes active.
>>>
>>> rough draft of the top-level layout.  Doesn't care about chosen libc, ISA, or
>>> <VERSION>, but does reflect endianness.
>>>
>>> default/linux/mips
>>>      |
>>>      |-32/
>>>      |  |-be/
>>>      |  |-le/
>>>      |
>>>      |-64/
>>>      |  |-be/
>>>      |  |-le/
>>>      |  |
>>>      |  |-multilib/
>>>      |  |  |-be/
>>>      |  |  |-le/
>>>      |  |
>>>      |
>>>
>>
>> I like this, but the problem is disentangling the situation under arch/mips,
>> not under default/linux/mips.  Again, the inheritance problem stems from
>> everything under profiles/arch/mips inheriting from profiles/arch/mips.  So
>> even if you do implement the above, you still have to address the issue of how
>> the arch/mips stuff is stacking.
>
> I'll poke around arch/mips later and see if some of this can't be extruded
> there.  I don't know if arch/mips is for us exclusively, or if we share it with
> a few other project teams (other than -embedded -- do we have an OpenBSD MIPS
> team or such??).
>
>

I don't think anyone really "owns" any of the profiles exclusively 
because arch teams often have to mask things in other profiles.  We do 
own the default/linux/mips more than arch/mips because there is less 
reason for arch testers to modify the former compared to the latter [1]. 
However, the profile are fragile and I've had to ask people to not do 
stuff in hardened for example because of the cooky stacking problem.

I'll send out an email to all gentoo-dev@ about it, and prepare a news 
item for only mips users.  I do want to move on this because its 
blocking the upgrade of my lemotes yeeloong images.

One final point, there's also a set of hardened mips profiles which I 
haven't listed under profiles.desc.  I'm testing them too and they seem 
to be doing fine with the above structure.

Note:
[1] An example here is a package which builds on amd64 and mips, but 
only has some optimization in amd64 assembly which you can enable with a 
USE flag.  That flag needs to be masked on mips because there is no 
equivalent mips assembly.  I've seen this before.

-- 
Anthony G. Basile, Ph. D.
Chair of Information Technology
D'Youville College
Buffalo, NY 14201
(716) 829-8197