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