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
<[email protected]> 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
