Created attachment 404600 [details] Full build log With linux-headers-3.11, I get this failure: /tmp/portage/sys-libs/libseccomp-2.2.0/work/libseccomp-2.2.0/tools/scmp_bpf_disasm.c:322:12: error: ‘EM_ARM’ undeclared (first use in this function) arch = AUDIT_ARCH_ARM; ^ /tmp/portage/sys-libs/libseccomp-2.2.0/work/libseccomp-2.2.0/tools/scmp_bpf_disasm.c:322:12: note: each undeclared identifier is reported only once for each function it appears in In file included from /tmp/portage/sys-libs/libseccomp-2.2.0/work/libseccomp-2.2.0/tools/scmp_bpf_disasm.c:35:0: /tmp/portage/sys-libs/libseccomp-2.2.0/work/libseccomp-2.2.0/tools/util.h:46:29: error: ‘EM_AARCH64’ undeclared (first use in this function) #define AUDIT_ARCH_AARCH64 (EM_AARCH64|__AUDIT_ARCH_64BIT|__AUDIT_ARCH_LE) ^ /tmp/portage/sys-libs/libseccomp-2.2.0/work/libseccomp-2.2.0/tools/scmp_bpf_disasm.c:324:12: note: in expansion of macro ‘AUDIT_ARCH_AARCH64’ arch = AUDIT_ARCH_AARCH64; ^ Makefile:491: recipe for target 'scmp_bpf_disasm.o' failed
should be all set now in the tree; thanks for the report! Commit message: Force recent kernel header versions http://sources.gentoo.org/sys-libs/libseccomp/libseccomp-2.2.0.ebuild?r1=1.1&r2=1.2
*** Bug 553626 has been marked as a duplicate of this bug. ***
I need to use latest LTS kernel (4.1.x). I had linux-headers-4.2 and higher masked. That means I now get blockers. Is it safe to use linux-headers-4.4 while the system is running kernel 4.1?
Btw, I just modified the ebuild locally: DEPEND=">=sys-kernel/linux-headers-4.1" And it builds just fine. I can maintain my own ebuild of course, but given that kernel 4.1 is the latest LTS, I think it might be better to depend on it in the portage ebuild for people who want or need to run the latest LTS.
(In reply to Nikos Chantziaras from comment #4) linux-headers and your kernel do not need to match. It is fine to build against newer headers and run an older kernel.
I know this is true for glibc, but are we sure every other package is just as backwards compatible?
If they are not, bugs should be reported against them.
Well, OK. I'm not gonna risk it though and maintain yet another ebuild locally. For the record, libseccomp 2.3.0 works fine with linux-headers 4.1.
Please see: https://github.com/seccomp/libseccomp/issues/25 Quote: It wouldn't make much sense to build and/or use libseccomp on Linux Kernel's earlier than v3.5 (the first version where seccomp mode 2 was available) but other than that restriction, no, you should be able to build and use libseccomp regardless of the kernel version. If you run into problems on a specific kernel version let us know as I would consider that a bug. /Quote I was able to build with kernel 3.18.27 on amd64. The >4.3 hard requirement of the ebuild is not necessary I would suggest reverting this change that was introduced from 2.2.0 to 2.3.0 in the ebuild.
vapier: Your thoughts here? There seem to be some people who do not want to use the latest/greatest headers.
Also keep in mind that not being aggressive with the dependency potentially allows easier stabilization of the package.
(In reply to Darko Luketic from comment #9) you're conflating the runtime kernel and the build time kernel headers. that description is focusing on the runtime kernel. as you can clearly see in this report, newer kernel headers are needed. as for the headers dep, Mike already covered that in comment #5 (In reply to Nikos Chantziaras from comment #11) then it's a good thing i picked an already stable version to depend on
Just wanted to let you know, that libseccomp-2.2.3 builds fine with linux-headers-3.14. So I suggest to change the dependency to: DEPEND=">=sys-kernel/linux-headers-3.14"
(In reply to cilly from comment #13) please read the comments already posted to the bug
