After disabling kernel options for 32bit emulation sys-apps/sandbox fails during configure when using multilib profile. .config reads: # CONFIG_IA32_EMULATION is not set # CONFIG_X86_X32 is not set Machine architecture is amd64 Profile is ... [4] default/linux/amd64/17.1/hardened/selinux (stable) [5] default/linux/amd64/17.1/desktop (stable) * [6] default/linux/amd64/17.1/desktop/gnome (stable) ... gcc is: gcc (Gentoo 10.2.0-r5 p6) 10.2.0 I know that multilib with the kernel config as given above does not make sense. It happened to me in a transition phase on a single machine that once used multilib. I could fix this locally/ easily by simply using one of the no-multilib profiles instead. Nevertheless other ebuilds complain or even fail about missing/ wrong kernel configuration. On the other hand I'm uncertain what the purpose of sandbox' configure step invoking x86_64-pc-linux-gnu-gcc -m32 should be. In turn it recommends to try FEATURE="-sandbox -usersandbox" emerge sandbox instead which fails the same way. Will this improve with >2.21 or during #787530?
Multilib profile assumes all ABIs multilib provides are directly executable. sandbox is not special here. It just breaks first. The correct sequence of events is to switch to non-multilib profile first, then disable kernel support for multiple ABIs.
I am aware of the order (now) but I changed the kernel months ago. After searching through the past of this package I recognized that the checks could be improved=my point. Other packages complain more sophisticated. QEmu for example notifies about missing KVM-options yet compiles & installs. My only request is to wrap the -m32 compiler call with a kernel option check. If this kernel option check fails skip the compiler call & output a warning about it. History shows that I could operate this machine fine for at least 6 months incl. sandbox but without any 32bit compiling (removed that over 2years ago). And some of my machines are booted with different kernels depending on the task. So it could happen basically happen that anyone runs into the same problem accidentially doing a rare sandbox update on the wrong kernel.
it isn't sandbox specific. any package that would build 32-bit libs would fail. see bug 322453 as an example. adding the same check to every package that supports multilib to make sure the user hasn't misconfigured their system isn't the right approach.
