Created attachment 547302 [details] output of emerge --info affected packages: sys-libs/glibc (src_install) sys-libs/musl (src_install) (to be continued) qemu is stable 2.12.1 dmesg is clean actual error (for the case of musl): ./tools/install.sh -D -m 644 include/values.h /var/tmp/portage/sys-libs/musl-1.1.20/image//usr/include/values.h ./tools/install.sh -D -m 644 include/wait.h /var/tmp/portage/sys-libs/musl-1.1.20/image//usr/include/wait.h ./tools/install.sh -D -m 644 include/wchar.h /var/tmp/portage/sys-libs/musl-1.1.20/image//usr/include/wchar.h ./tools/install.sh -D -m 644 include/wctype.h /var/tmp/portage/sys-libs/musl-1.1.20/image//usr/include/wctype.h ./tools/install.sh -D -m 644 include/wordexp.h /var/tmp/portage/sys-libs/musl-1.1.20/image//usr/include/wordexp.h ./tools/install.sh -D -l /usr/lib/libc.so /var/tmp/portage/sys-libs/musl-1.1.20/image//lib/ld-musl-armhf.so.1 || true * /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/trace.c:_do_ptrace():75: failure (Function not implemented): * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x00000000, 0x00000000): Function not implemented * ERROR: sys-libs/musl-1.1.20::gentoo failed (install phase): * (no error message) * * Call stack: * ebuild.sh, line 124: Called src_install * environment, line 2282: Called die * The specific snippet of code: * [[ -e "${D}"/lib/ld-musl-${arch}.so.1 ]] || die; * * If you need support, post the output of `emerge --info '=sys-libs/musl-1.1.20::gentoo'`, * the complete build log and the output of `emerge -pqv '=sys-libs/musl-1.1.20::gentoo'`. * The complete build log is located at '/var/tmp/portage/sys-libs/musl-1.1.20/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/sys-libs/musl-1.1.20/temp/environment'. * Working directory: '/var/tmp/portage/sys-libs/musl-1.1.20/work/musl-1.1.20' * S: '/var/tmp/portage/sys-libs/musl-1.1.20/work/musl-1.1.20'
more details about my qemu installation on the host: [ebuild R ] app-emulation/qemu-2.12.1::gentoo USE="aio alsa bzip2 caps curl fdt filecaps gtk jpeg lzo ncurses nls opengl pin-upstream-blobs png sasl sdl seccomp smartcard static-user usb vhost-net vnc xattr -accessibility -bluetooth -capstone -debug -glusterfs -gnutls -gtk2 -infiniband -iscsi -nfs -numa -pulseaudio -python -rbd -sdl2 (-selinux) -snappy -spice -ssh (-static) -systemtap -tci -test -usbredir -vde -virgl -virtfs -vte -xen -xfs" PYTHON_TARGETS="python2_7 python3_6 -python3_4 -python3_5" QEMU_SOFTMMU_TARGETS="arm i386 x86_64 -aarch64 -alpha -cris -hppa -lm32 -m68k -microblaze -microblazeel -mips -mips64 -mips64el -mipsel -moxie -nios2 -or1k -ppc -ppc64 -ppcemb -riscv32 -riscv64 -s390x -sh4 -sh4eb -sparc -sparc64 -tricore -unicore32 -xtensa -xtensaeb" QEMU_USER_TARGETS="aarch64 arm -aarch64_be -alpha -armeb -cris -hppa -i386 -m68k -microblaze -microblazeel -mips -mips64 -mips64el -mipsel -mipsn32 -mipsn32el -nios2 -or1k -ppc -ppc64 -ppc64abi32 -ppc64le -riscv32 -riscv64 -s390x -sh4 -sh4eb -sparc -sparc32plus -sparc64 -tilegx -x86_64 -xtensa -xtensaeb" 0 KiB which I install via 'cp /usr/bin/qemu-arch $CHROOT/usr/bin/' sandbox install on the host is: [ebuild R ] sys-apps/sandbox-2.13::gentoo ABI_X86="(32) (64) (-x32)" 0 KiB
Created attachment 547304 [details] compressed build.log for musl I'll attach the one for glibc soon.
Created attachment 547344 [details] compressed build.log for glibc this is the error for glibc: qemu: Unsupported syscall: 26 * /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/trace.c:_do_ptrace():75: failure (Function not implemented): * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x00000000, 0x00000000): Function not implemented /proc/7257/cmdline: /usr/bin/make -r PARALLELMFLAGS= -C /var/tmp/portage/sys-libs/glibc-2.26-r7/work/glibc-2.26 objdir=/var/tmp/portage/sys-libs/glibc-2.26-r7/work/build-arm-armv6j-unknown-linux-gnueabihf-nptl install
there are likely various other affected packages, for instance gcc or gtk+2: * /var/tmp/portage/sys-apps/sandbox-2.13/work/sandbox-2.13/libsandbox/trace.c:_do_ptrace():75: failure (Function not implemented): * ISE:_do_ptrace: ptrace(PTRACE_TRACEME, ..., 0x00000000, 0x00000000): Function not implemented but in the case of gcc or gtk+2 it doesn't make the build fail (this makes them harder to catch as well) so the two libc's are the most important ones now, can I use 'armv6j-unknown-linux-gnueabihf-emerge' (cross-emerge) to emerge glibc this way and install it later from within the CHROOT? cross-emerge does have FEATURES="buildpkg" activated by default, so that makes me think it is possible to copy over the package folder to the chroot and do an emerge --oneshot -av -K from within the armv6j-chroot.
The bug (or rather a missing features) is in qemu-arm (user emulation) that does not support ptrace() syscall. To work it around you can try to disable sandbox with FEATURES="-sandbox -usersandbox". The bug is not specific to package being built.
I'll try to disable sandboxing and be back with the results. If not, does the approach of using cross-emerge + binpkg give me a valid glibc? Or musl, for the sake of the argument?
(In reply to tt_1 from comment #6) > I'll try to disable sandboxing and be back with the results. > > If not, does the approach of using cross-emerge + binpkg give me a valid > glibc? Or musl, for the sake of the argument? Both binpkgs should work. If they don't it's a bug and should be reported/fixed.
FEATURES="-sandbox -usersandbox" allows to compile musl through qemu-static for the case of arm. Are there any negative side effects about disabling the sandbox? Also affected by the breakage is >=firefox-60.x, where the segfault occurs when testing for rust/cargo during src_configure. I may try to disable sandboxing for testing.
(In reply to tt_1 from comment #8) > FEATURES="-sandbox -usersandbox" allows to compile musl through qemu-static > for the case of arm. Are there any negative side effects about disabling the > sandbox? Less resilience against bugs in ebuild or package that can wipe your system out. Sandbox tries to make sure there are no mutating accesses outside the sandbox. In practice it should not matter much for ebuilds in ::gentoo. > Also affected by the breakage is >=firefox-60.x, where the segfault occurs > when testing for rust/cargo during src_configure. I may try to disable > sandboxing for testing. This might be different: bug #663690
I have same bug with qemu-user-arm + lxc (trying to build packages with that). Seems like qemu dont have ptrace() syscall
Would it be worth trying to use qemu-static built from within a musl env?
Should this bug be closed as can't fix, in favour of doing a real cross compile with cross-emerge? It seems to work just fine for glibc.
qemu doesn't have the syscall, and it's close to impossible that it will ever be implemented. Therefore closing as cantfix. A cross-compile of binutils, gcc and glibc or musl is possible with cross-emerge wrappers.
Hello. Qemu user has no support for ptrace and it is fine. Sandbox library has a special flag "SB_NO_TRACE". I think this issue means that this flag detection mechanism can to be improved. Personally I don't like autoconf, not using it, so I can't provide a proper patch for ptrace detection. But the method is very simple: 1. If we are doing cross compilation - "define SB_NO_TRACE". 2. Check that we can run compiled binary. 3. If we can't run binary - ptrace support is unknown, "define SB_NO_TRACE". 4. If we can't compile test file - "define SB_NO_TRACE". 5. If we've failed running test binary - "define SB_NO_TRACE". 6. "undef SB_NO_TRACE" If we are doing a cross compilation - we can use a quick patch that just replaces current ptrace detection mechanism with "define SB_NO_TRACE".
(In reply to Andrew Aladjev from comment #14) > Hello. Qemu user has no support for ptrace and it is fine. Sandbox library > has a special flag "SB_NO_TRACE". I think this issue means that this flag > detection mechanism can to be improved. > > Personally I don't like autoconf, not using it, so I can't provide a proper > patch for ptrace detection. But the method is very simple: > > 1. If we are doing cross compilation - "define SB_NO_TRACE". > 2. Check that we can run compiled binary. > 3. If we can't run binary - ptrace support is unknown, "define SB_NO_TRACE". > 4. If we can't compile test file - "define SB_NO_TRACE". > 5. If we've failed running test binary - "define SB_NO_TRACE". > 6. "undef SB_NO_TRACE" > > If we are doing a cross compilation - we can use a quick patch that just > replaces current ptrace detection mechanism with "define SB_NO_TRACE". Detection has to happen at runtime. It's fine to cross-compile sandbox and expect it to run on target system. https://bugs.gentoo.org/693582 should cover the case once fixed.
Yes, runtime detection will be much better, thank you.
Created attachment 602156 [details, diff] disable_trace.patch
I've added a small workaround for now. You can just put it into "/usr/arm-unknown-linux-gnueabi/etc/portage/patches/sys-apps/sandbox/disable_trace.patch" and it will work perfect.
