The ebuild handles building for multiple ABIs by itself. Nevertheless, configure of the package does it's own tricks to build for multiple ABIs - it hardcodes a configure option called 'schizo' to being enabled by default. This in turn triggers building for an X32_ABI always _if_ the host_alias matches x86_64*linux*. The relevant lines triggering this behavior are in configure.ac at line 47: if test "x$enable_schizo" = "xyes" ; then case $host_alias in x86_64*linux*) SB_SCHIZO_SETTINGS="x86_64:-m64 x86:-m32 x32:-mx32";; esac fi This will not work if the host does not make use of X32 ABI, the system will miss x32 specific header files that are tried to be read at compile time: CC libsandbox_la-trace.lo In file included from /usr/include/features.h:390:0, from /usr/include/dirent.h:25, from ./../../sandbox-2.6/headers.h:15, from <command-line>:0: /usr/include/gnu/stubs.h:13:28: fatal error: gnu/stubs-x32.h: No such file or directory # include <gnu/stubs-x32.h> ^ compilation terminated. (See attached build log for context.) To make things even worse: Portage/Paludis will NOT die because of this error (even though it is fatal). Instead they continue to merge the build image to the live system. Reproducible: Always
Created attachment 393956 [details] build log note that I have modified the ebuild to die unconditionally after compilation stages have finished. i did this to preserve the output log that normally is removed by the package manager on completion. neither LTO nor the gold linker have been used. just using standard flags exhibits this bugs problem.
Created attachment 393958 [details, diff] sandbox-2.6-r1.ebuild.patch
(In reply to cmuelle8 from comment #2) > Created attachment 393958 [details, diff] [details, diff] > sandbox-2.6-r1.ebuild.patch IMHO: Aside from this fix the ebuild should further be modified to make the package manager fail if fatal errors arise during compile stage (as is expected for such cases).
the code is not failing in the way you think it is. it is attempting to generate a list of syscalls for ptracing. if the ABI isn't usable at compile time, then you won't get a list of syscalls, and you won't be able to sandbox that ABI. since you've already made x32 not available, this isn't a problem.
(In reply to SpanKY from comment #4) > it is attempting to generate a list of syscalls for ptracing. > [..] > since you've already made x32 not available, this isn't a problem. ACK, but imho if this is an error that the programmer expects or is known to be generated, then there is no need to show it during the build process. Also, the code does not _need_ to probe for X32, if it is _known_ we are not building for it (wrt to active abi use flags). To me it looks as if these lines of code are a reminiscence to the days when ebuilds did not 'make' the package for each ABI individually (or better, when PMS/eclass were not ready for it). It's also noteworthy that this 'schizo' thing has been implemented for x86_64 _only_. For the sake of consistency: If the ebuild handles multiple ABIs itself for other archs, it should do so for x86_64. You also point out that 'this isn't a problem', if 'x32 not available'. What about the case where x32 actually _is_ available, but the x32 abi use flag is disabled (intently, for testing purpose or other reason)? In the latter case, for x86_64, the build will not result in what the admin/pkg builder expects - i.e. a sandbox without support of x32. imho the ebuild behavior should be streamlined to that found for other archs. There'll be less source of error and more predictability in the attempts to find such. This is easy to have, since by using the configure option, we do not need to modify upstream source.
(In reply to cmuelle8 from comment #5) you're confusing enabled ABIs with possible kernel ABIs. any libsandbox library can be called on to execute static programs of a different ABI which is why a single build must know about all of them. as for ABI support, things happen when developers actually invest time in implementing things. the fact that only x86_64/x86/x32 is currently supported is because that's what i've gotten around to coding. if you want other ABIs, then you should contribute to the effort. otherwise, tbh, complaining about missing functionality is simply obnoxious. not having x32 headers but x32 support in the kernel is something that should be addressed, but again, that's only possible when someone implements it. most likely it'll come about by pregenerating the headers ahead of time & committing them to the source repo. as for user configurations, i don't think that's relevant. user's rarely understand what's going on at this level, and there's no real need to even allow them to dive in this far. the expectation is the sandbox catches bad code and that's it.
the build no longer generates warnings with: http://gitweb.gentoo.org/proj/sandbox.git/commit/?id=46fe624223cfe62fb6c2fbb609be42f2f1d1734b i'll probably precompile things ahead of time at some point, but don't need a bug open for that
