Hello. I am doing cross compiling of portage using "x86_64-pc-linux-musl" toolchain. Sandbox was cross compiled using same toolchain. "LD_LIBRARY_PATH='/usr/x86_64-pc-linux-musl/usr/lib' ldd -v /usr/x86_64-pc-linux-musl/usr/lib/libsandbox.so" provides: linux-vdso.so.1 (0x00007ffc5c5cd000) libc.so => /usr/x86_64-pc-linux-musl/usr/lib/libc.so (0x00007f3b52c96000) "libc.so" is musl. "FEATURES='-usersandbox' x86_64-pc-linux-musl-emerge -v1 portage" works perfect. "x86_64-pc-linux-musl-emerge -v1 portage" returned segfault. Please see the following build.log. https://gist.github.com/andrew-aladev/6dd1efd9d6092acfb4ac94d48a6ebdea x86_64-pc-linux-musl-gcc -O2 -pipe -fPIC -I/usr/x86_64-pc-linux-musl/usr/include/python3.6m -c src/portage_util_libc.c -o /usr/x86_64-pc-linux-musl/tmp/portage/sys-apps/portage-2.3.79/work/portage-2.3.79-python3_6/temp.linux-x86_64-3.6/src/portage_util_libc.o -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE error: command 'x86_64-pc-linux-musl-gcc' terminated by signal 11 Than I am analyzing coredump: gdb /usr/x86_64-pc-linux-gnu/x86_64-pc-linux-musl/gcc-bin/9.2.0/x86_64-pc-linux-musl-gcc /usr/x86_64-pc-linux-musl/tmp/portage/sys-apps/portage-2.3.79/work/portage-2.3.79/core --batch --quiet -ex "thread apply all bt full" -ex "quit" Please see the following log https://gist.github.com/andrew-aladev/04fcb14af7b5c9ed4a363a3e95a8d9d7. We can see that some glibc call (/lib64/ld-linux-x86-64.so.2, it is glibc) was redirected by sandbox to musl "__dlsym" (ldso/dynlink.c:2235, it is musl) and musl provided segfault. I don't know whether sandbox can redirect calls between different libcs, so I am not sure whether it is bug or not. I want just to provide you with information. Thank you. Reproducible: Always
For now it is easy to workaround this bug: ``` "${TARGET}-emerge" -v1 sys-apps/sandbox rm "/usr/${TARGET}/usr/lib/libsandbox.so" "${TARGET}-emerge" -v1 sys-apps/portage build "${TARGET}-emerge" -v1 sys-apps/sandbox ``` Cross emerge will load native sandbox (even with LD_LIBRARY_PATH="/usr/${TARGET}/...") instead of cross compiled one.
> Cross emerge will load native sandbox (even with LD_LIBRARY_PATH="/usr/${TARGET}/...") instead of cross compiled one. That's expected. You are normally running only host's binaries when cross-compiling. If you are running both host's and target's binaries during cross-compilation you have to disable sandbox (it's arguably a bug to even attempt that). There is no way to safely preload same library into both.
Ok, thank you. I will note that it is not a bug.
(In reply to Andrew Aladjev from comment #3) > Ok, thank you. I will note that it is not a bug. I still don't think sandbox can do much here. If you'd like to fix a package or specific class of packages to prevent from executing target binaries on a host I suggest attaching example build log and direct the bug to specific maintainers.
