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