For the MIPS platforms that I support, I am still using the 5.4.x LTS kernels and have locked the kernel headers to 5.4 accordingly. I won't be moving to 5.10+ for some time (requires porting kernel stuff for some of the SGI systems), so I need a pax-utils that is compatible with 5.4 LTS, which will be pax-utils-1.2.8. Can this version get restored and locked to kernels <=5.4.x?
(In reply to Joshua Kinard from comment #0) > For the MIPS platforms that I support, I am still using the 5.4.x LTS > kernels and have locked the kernel headers to 5.4 accordingly. Using new kernel headers should be fine with old kernels: https://wiki.gentoo.org/wiki/Project:Toolchain/sys-kernel/linux-headers#new_linux-headers_.2F_old_linux_kernel > I won't be > moving to 5.10+ for some time (requires porting kernel stuff for some of the > SGI systems), so I need a pax-utils that is compatible with 5.4 LTS, which > will be pax-utils-1.2.8. Can this version get restored and locked to > kernels <=5.4.x? We might consider adding a few workarounds to latest version. For example USE=-seccomp should not require new kernel headers (DEPENDs might need an update to express that).
(In reply to Sergei Trofimovich from comment #1) > (In reply to Joshua Kinard from comment #0) > > For the MIPS platforms that I support, I am still using the 5.4.x LTS > > kernels and have locked the kernel headers to 5.4 accordingly. > > Using new kernel headers should be fine with old kernels: > > https://wiki.gentoo.org/wiki/Project:Toolchain/sys-kernel/linux- > headers#new_linux-headers_.2F_old_linux_kernel Okay, this is good to know. I guess I was being too cautious. That said, the reason I tried using an older version was because I am seeing this non-fatal error in the 'install' phase: /var/tmp/portage/._portage_reinstall_.aytfea_e/bin/estrip: line 393: 3796 Bad system call scanelf -yqRBF '#k%F' -k '.symtab' "$@" Running scanelf by itself with those arguments seems to work fine, so I am stumped on a way to debug this w/ strace to try and find what syscall it is complaining about. I thought it was tied to linux-headers being old and newer pax-utils trying to reference a non-existent syscall. However, even with linux-headers-5.10 installed and pax-utils-1.2.9, I still get this same non-fatal error. pax-utils-1.3.1 does not build on MIPS right now it looks: mips64-unknown-linux-gnu-gcc -O2 -pipe -march=mips4 -mtune=mips4 -mabi=n32 -mplt -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DWANT_SECCOMP -DVERSION="v1.3.1" -DVCSID="" -o xfuncs.o -c xfuncs.c In file included from security.c:9: seccomp-bpf.h:40:28: error: redefinition of _seccomp_bpf_blks_base_ 40 | static const unsigned char seccomp_bpf_blks_base[] = { | ^~~~~~~~~~~~~~~~~~~~~ In file included from security.c:9: seccomp-bpf.h:29:28: note: previous definition of _seccomp_bpf_blks_base_ was here 29 | static const unsigned char seccomp_bpf_blks_base[] = { | ^~~~~~~~~~~~~~~~~~~~~ <<<repeat for several other variables>>>
(In reply to Joshua Kinard from comment #2) > (In reply to Sergei Trofimovich from comment #1) > > (In reply to Joshua Kinard from comment #0) > > > For the MIPS platforms that I support, I am still using the 5.4.x LTS > > > kernels and have locked the kernel headers to 5.4 accordingly. > > > > Using new kernel headers should be fine with old kernels: > > > > https://wiki.gentoo.org/wiki/Project:Toolchain/sys-kernel/linux- > > headers#new_linux-headers_.2F_old_linux_kernel > > Okay, this is good to know. I guess I was being too cautious. > > That said, the reason I tried using an older version was because I am seeing > this non-fatal error in the 'install' phase: > > /var/tmp/portage/._portage_reinstall_.aytfea_e/bin/estrip: line 393: 3796 > Bad system call scanelf -yqRBF '#k%F' -k '.symtab' "$@" > > Running scanelf by itself with those arguments seems to work fine, so I am > stumped on a way to debug this w/ strace to try and find what syscall it is > complaining about. I thought it was tied to linux-headers being old and > newer pax-utils trying to reference a non-existent syscall. However, even > with linux-headers-5.10 installed and pax-utils-1.2.9, I still get this same > non-fatal error. It's probably an interaction with sandbox which injects extra code into library overrides. Something like: tmp $ sandbox sandbox $ strace scanelf -yqRBF '#k%F' -k '.symtab' ... > pax-utils-1.3.1 does not build on MIPS right now it looks: > > mips64-unknown-linux-gnu-gcc -O2 -pipe -march=mips4 -mtune=mips4 -mabi=n32 > -mplt -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -DWANT_SECCOMP -DVERSION="v1.3.1" > -DVCSID="" -o xfuncs.o -c xfuncs.c > In file included from security.c:9: > seccomp-bpf.h:40:28: error: redefinition of _seccomp_bpf_blks_base_ > 40 | static const unsigned char seccomp_bpf_blks_base[] = { > | ^~~~~~~~~~~~~~~~~~~~~ > In file included from security.c:9: > seccomp-bpf.h:29:28: note: previous definition of _seccomp_bpf_blks_base_ > was here > 29 | static const unsigned char seccomp_bpf_blks_base[] = { > | ^~~~~~~~~~~~~~~~~~~~~ > > <<<repeat for several other variables>>> I suggest filing a separate bug with a full build.log. It looks like a bug in sys-libs/libseccomp.
Someone else filed bug #795075 with a fix.
(In reply to Sergei Trofimovich from comment #4) > Someone else filed bug #795075 with a fix. Confirmed that pax-utils-1.3.2 fixes both the build failure and the scanelf error (bad system call) that I was seeing. Thanks!
