Hi, In Gentoo Prefix on amd64 host with a no-multilib profile, for packages that inherit multilib multilib-minimal, the multilib-build eclass wraps headers as if multilib were enabled.
One example is mpi.h header in sys-cluster/openmpi. I am using a custom modified ebuild, but the differences shouldn't be relevant to this issue. The wrapper is causing problems for me, for reasons that are not relevant here [1]. This question here is whether the wrapping should takes place at all with no-multilib profile. Wrapping happens on amd64 with this profile: gentoo:default/linux/amd64/17.1/no-multilib/prefix/kernel-3.2+ For reference, as expected, no wrapping happens on ppc64le with: gentoo:default/linux/ppc64le/17.0/prefix/kernel-3.2+ The above profile is a parent of my custom profile but this shouldn't be relevant, the custom profile is simple, it just sets compiler flags, package lists, use flags. Diagnosis: multilib-build.eclass wrapps the headers because it is detecting the "abi_flag" as set. So, as far as I understand, it (wrongly?) ends up on the code path for yes-multilib instead of no-multilib: multilib_prepare_wrappers() ... if [[ ${MULTILIB_WRAPPED_HEADERS[@]} ]]; then # If abi_flag is unset, then header wrapping is unsupported on # this ABI. This means the arch doesn't support multilib at all # -- in this case, the headers are not wrapped and everything # works as expected. ^ I want the case described in this comment, but not happening if [[ ${MULTILIB_ABI_FLAG} ]]; then ^ this is set to abi_x86_64.amd64... ...because MULTIBUILD_VARIANT is set ...because MULTIBUILD_VARIANTS contains the flag ...because multilib_get_enabled_abi_pairs() adds it there ...because 'use abi_x86_64' evaluates to true ...presumably because in gentoo/profies/sarch/amd64/ A. use.force contains abi_x86_64, and/or B. make.defaults sets IUSE_IMPLICIT="abi_x86_64" Workaround: override in my derived profile: 1. in make.defaults: USE="-abi_x86_64" 2. in use.force: -abi_x86_64 Then, 'use abi_x86_64' evals to false and the header is not wrapped. Before digging deeper, I figured I'd ask whether this is by design to end up doing multilib things with no-multilib profile, or if it's some issue with the way the ebuild is using multilib eclasses. What is the correct way to disable multilib for good? Thanks for any insights. [1] The wrapper does not cover the case when Clang is passed -target le64-unknown-unkown-unknown, which doesn't set the macros for x86_64 that the wrapper checks. I'm not faulting the wrapper, though.