Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 676016 - [Future EAPI] Per-ABI include directory in profiles for multiarch support
Summary: [Future EAPI] Per-ABI include directory in profiles for multiarch support
Alias: None
Product: Gentoo Hosted Projects
Classification: Unclassified
Component: PMS/EAPI (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: PMS/EAPI
Depends on:
Blocks: future-eapi
  Show dependency tree
Reported: 2019-01-22 01:24 UTC by Samuel Holland
Modified: 2019-08-25 19:15 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---

Suggested implementation for sys-apps/portage (0001-Implement-7-multiarch-EAPI.patch,3.22 KB, patch)
2019-01-22 01:36 UTC, Samuel Holland
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Samuel Holland 2019-01-22 01:24:44 UTC
"Debian-style" multiarch involves putting headers in /usr/include/${triple} and libraries in /usr/lib/${triple}, where ${triple} is a simplified version of $CHOST (see Since musl does not support sharing 32/64-bit headers in the same directory, this is the only way to implement multilib on musl systems. Since it is more flexible than lib32/lib64, it is also useful on glibc systems, where you could for example have soft-float and hard-float libraries installed side-by-side, or have entirely foreign-architecture libraries usable with qemu-user.

Gentoo already has per-ABI LIBDIR in profiles, so something like:


gets halfway to what we need for a multiarch profile. However, there's currently no way to separate headers for each ABI (multilib.eclass can wrap individual headers as a workaround, but that requires explicit ebuild support).

I propose adding INCDIR, the equivalent of LIBDIR for the include directory, to the PMS. This would include an INCDIR_${ABI} variable for ABIs, as well as a get_incdir function. Finally, econf would be extended to pass


much like it does --libdir today.

I've attached a patch implementing these changes in sys-apps/portage as an experimental "7-multiarch" EAPI, and I hope this will be considered for a future stable EAPI

Reproducible: Always
Comment 1 Samuel Holland 2019-01-22 01:36:01 UTC
Created attachment 562498 [details, diff]
Suggested implementation for sys-apps/portage
Comment 2 Mike Gilbert gentoo-dev 2019-01-22 03:28:56 UTC
See MULTILIB_WRAPPED_HEADERS in multilib-build.eclass for a possible alternative that would not require updating econf and every other build system in the tree.
Comment 3 Samuel Holland 2019-01-22 04:15:31 UTC
I'm aware of MULTILIB_WRAPPED_HEADERS. It would work automagically with multiarch if it used the multiarch tuple instead of $CHOST directly. (And then you could omit the wrappers if you built gcc with --enable-multiarch, since gcc will search the subdirectory first and then fall back to /usr/include.)

However, that requires knowing and enumerating all of the headers that might change per-ABI. For sys-libs/musl, that's the entire contents of /usr/include/bits. For other packages, it may or may not be the same list of headers as with glibc (which may or may not already be in MULTILIB_WRAPPED_HEADERS in that package's ebuild). The nice thing about multiarch is that there are only a few build systems. Once those are configured correctly, you get everything else for free--you don't have to audit packages for which headers need to be wrapped.

Maybe MULTILIB_WRAPPED_HEADERS would work; I might try it sometime. Right now, I'm using a patch similar to the one in this bug, and it works okay. Most packages I have installed use econf. CMake was already being patched for LIBDIR, so I just added to that patch. I haven't looked at meson/waf/gyp/etc.

Of course I'm not suggesting that Gentoo go multiarch; but the possibility of a multiarch profile would be great (for the reasons I mentioned earlier).