| Summary: | Please fill ABI and related variables in arch profiles | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Michał Górny <mgorny> |
| Component: | Eclasses | Assignee: | Multilib team <multilib+disabled> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | arm, blueness, vapier |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
(In reply to Michał Górny from comment #0) > 4. IMPLICIT_IUSE set to flag corresponding to native ABI, IUSE_IMPLICIT, sorry. I've fixed ppc & ppc64: + 27 Jun 2014; Michał Górny <mgorny@gentoo.org> make.defaults, + ppc32/make.defaults, ppc32/use.mask, ppc64/32ul/make.defaults, + ppc64/32ul/use.force, ppc64/32ul/use.mask, ppc64/make.defaults, + ppc64/use.mask, use.mask: + Clean up multilib flags. Add ABI values to the ppc32 profile for consistency + with ppc64 profiles. All arch/mips profiles done. fbsd profiles done. s390 done. Now it's time for special hardened profiles. @blueness, which ones are you doing? (In reply to Michał Górny from comment #0) > > Other possible multilibs: arm/arm64, sparc. > What are we doing for arm? Here's what I'd like to do: ABI="eabi" DEFAULT_ABI="eabi" MULTILIB_ABIS="eabi" CHOST_eabi=${CHOST} LIBDIR_eabi="lib" IUSE_IMPLICIT=abi_arm_eabi use.mask: -abi_arm_eabi use.force: abi_arm_eabi Also, the flag would need to be masked in base/use.mask:abi_arm_eabi. Any objections, else I'll make it happen in a few days. @mgorny
1. profiles/hardened/<arch> shouldn't need any changes since they inherit from arch/<arhch>
2. I've taken care of profiles/hardened/uclibc/<arch> and profiles/hardened/musl/<arch> since they do not inherit from arch/<arch>. The only exception is I haven't taken care of arm yet.
3. I don't understand the need for
ABI_X86="64"
USE_EXPAND_HIDDEN="-ABI_X86"
so I did not add the equivalent of them to profiles/hardened/{uclibc,musl}. What are they for and are they needed?
(In reply to Anthony Basile from comment #6) > (In reply to Michał Górny from comment #0) > > > > Other possible multilibs: arm/arm64, sparc. > > > > What are we doing for arm? Here's what I'd like to do: > > ABI="eabi" > DEFAULT_ABI="eabi" > MULTILIB_ABIS="eabi" I've currently made arch/arm use ABI="arm" and so on. So what's the deal with 'eabi' anyway, and what are the alternatives? > CHOST_eabi=${CHOST} > LIBDIR_eabi="lib" > IUSE_IMPLICIT=abi_arm_eabi > > use.mask: -abi_arm_eabi > use.force: abi_arm_eabi I think we'd also want to fit arm64 in here somehow. (In reply to Anthony Basile from comment #7) > @mgorny > > 1. profiles/hardened/<arch> shouldn't need any changes since they inherit > from arch/<arhch> Yes. > 3. I don't understand the need for > > ABI_X86="64" > USE_EXPAND_HIDDEN="-ABI_X86" > > so I did not add the equivalent of them to profiles/hardened/{uclibc,musl}. > What are they for and are they needed? ABI_X86 sets the default value. It's used for packages like adobe-flash when the 64-bit part is optional and therefore abi_x86_64 is not forced. Otherwise, people trying to install it will get it with empty ABI_X86. USE_EXPAND_HIDDEN tells portage to hide/show ABI flags. We hide the unnecessary flags, and show only when they're meaningful -- e.g. when a particular profile supports multilib and you may want to change them. (In reply to Michał Górny from comment #8) > (In reply to Anthony Basile from comment #6) > > (In reply to Michał Górny from comment #0) > > > > > > Other possible multilibs: arm/arm64, sparc. > > > > > > > What are we doing for arm? Here's what I'd like to do: > > > > ABI="eabi" > > DEFAULT_ABI="eabi" > > MULTILIB_ABIS="eabi" > > I've currently made arch/arm use ABI="arm" and so on. > > So what's the deal with 'eabi' anyway, and what are the alternatives? That's probably not a good idea. eabi = the newer "embedded" abi. The older abi was just called arm. Take a look at https://wiki.debian.org/ArmEabiPort So, following the Debian convention, this might be interpreted as the older abi. Distinguishing the two became an issue a while back and that's where we get the ugly -gnueabi in the CHOST tupple for the current arm toolschain. Is it too late to switch to eabi? > > > CHOST_eabi=${CHOST} > > LIBDIR_eabi="lib" > > IUSE_IMPLICIT=abi_arm_eabi > > > > use.mask: -abi_arm_eabi > > use.force: abi_arm_eabi > > I think we'd also want to fit arm64 in here somehow. I'm not sure what we should call it now. Let's not choose something stupid. I'm cc-ing vapier who would know. (In reply to Anthony Basile from comment #10) > (In reply to Michał Górny from comment #8) > > (In reply to Anthony Basile from comment #6) > > > (In reply to Michał Górny from comment #0) > > > > > > > > Other possible multilibs: arm/arm64, sparc. > > > > > > > > > > What are we doing for arm? Here's what I'd like to do: > > > > > > ABI="eabi" > > > DEFAULT_ABI="eabi" > > > MULTILIB_ABIS="eabi" > > > > I've currently made arch/arm use ABI="arm" and so on. > > > > So what's the deal with 'eabi' anyway, and what are the alternatives? > > That's probably not a good idea. eabi = the newer "embedded" abi. The > older abi was just called arm. Take a look at > > https://wiki.debian.org/ArmEabiPort > > So, following the Debian convention, this might be interpreted as the older > abi. Distinguishing the two became an issue a while back and that's where > we get the ugly -gnueabi in the CHOST tupple for the current arm toolschain. > > Is it too late to switch to eabi? Not at all. Just please remember to update nss/nspr afterwards since the two use ${ABI} heavily. > > > CHOST_eabi=${CHOST} > > > LIBDIR_eabi="lib" > > > IUSE_IMPLICIT=abi_arm_eabi > > > > > > use.mask: -abi_arm_eabi > > > use.force: abi_arm_eabi > > > > I think we'd also want to fit arm64 in here somehow. > > I'm not sure what we should call it now. Let's not choose something stupid. > I'm cc-ing vapier who would know. Well, logically we'd have abi_arm_{32,64} like for other arches. But if we want eabi in there, it could be abi_arm{eabi,64} or sth. @mgorny. It looks like you've already taken care of mips. Anything else to do there? Well, I guess we can close this as FIXED already for the basic work is done. |
Since profiles is utter mess, I'd like to ask the relevant arch teams to revise their profiles and make sure they're ABI-friendly. I should note that this applies to all profiles of arches that can do multilib, not only those the actual multilib profiles. What needs to be set: 1. ABI and DEFAULT_ABI to the same value matching native ABI on particular profile, 2. MULTILIB_ABIS -- to all ABIs in multilib profiles, or single native ABI in non-multilib profiles, 3. CHOST_${ABI} & LIBDIR_${ABI} -- for each ABI in MULTILIB_ABIS. On non-multilib profiles, this goes as CHOST_${ABI}=${CHOST}, LIBDIR_${ABI}=lib, 4. IMPLICIT_IUSE set to flag corresponding to native ABI, 5. use.force & use.mask entries for the abi_* flags -- native ABI needs to be forced, other supported ABIs unmasked. At the same time, please do not add new ABIs or flags to multilib-build.eclass. The goal is to prepare the profiles first. For example, non-multilib x86 looks like: ABI=x86 DEFAULT_ABI=x86 MULTILIB_ABIS=x86 CHOST_x86=${CHOST} LIBDIR_x86=lib IUSE_IMPLICIT=abi_x86_32 use.mask: -abi_x86_32 use.force: abi_x86_32 Full conformity like this allows you to safely use dev-libs/foo[abi_x86_32(-)] to refer to x86 packages -- and the dep matches both multilib-capable packages on amd64 and any ebuild on x86 (thanks to the implicit flag). I would like to see the same behavior for other multilib arches. For reference, the complete arch-ABI-flag mapping for what has been tried so far: x86/amd64: - abi_x86_32 -> x86 - abi_x86_64 -> amd64 - abi_x86_x32 -> x32 mips: - abi_mips_o32 -> o32 - abi_mips_n32 -> n32 - abi_mips_n64 -> n64 ppc/ppc64: - abi_ppc_32 -> ppc - abi_ppc_64 -> ppc64 s390: - abi_s390_32 -> s390 - abi_s390_64 -> s390x (ppc and s390 were reverted from the eclass due to tree not being ready) Other possible multilibs: arm/arm64, sparc. Arch teams, please update your profiles and un-CC yourself. I'll hand this bug over to hardened and other forky teams afterwards.