"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 https://wiki.debian.org/Multiarch/Tuples). 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: LIBDIR_amd64="lib/x86_64-gentoo-linux-musl" LIBDIR_x86="lib/i686-gentoo-linux-musl" 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 --includedir=${EPREFIX}/usr/$(get_incdir) 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
Created attachment 562498 [details, diff] Suggested implementation for sys-apps/portage
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.
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).
