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
