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