On Thursday, April 09, 2015 10:21:52 AM Eduardo Otubo wrote:
> On Thu, Apr 09, 2015 at 05=01=31AM +0200, Andreas Färber wrote:
> > Hello,
> >
> > I am seeing the following build failure on openSUSE Tumbleweed armv7l
> > with --enable-seccomp in v2.3.0-rc2:
> >
> > [ 551s] In file included from qemu-seccomp.c:16:0:
> > [ 551s] /usr/include/libseccomp/seccomp.h:177:23: error: '__NR_mmap'
> > undeclared here (not in a function)
> > [ 551s] #define SCMP_SYS(x) (__NR_##x)
> > [ 551s] ^
> > [ 551s] qemu-seccomp.c:36:7: note: in expansion of macro 'SCMP_SYS'
> > [ 551s] { SCMP_SYS(mmap), 247 },
> > [ 551s] ^
> > [ 551s] /usr/include/libseccomp/seccomp.h:177:23: error:
> > '__NR_getrlimit' undeclared here (not in a function)
> > [ 551s] #define SCMP_SYS(x) (__NR_##x)
> > [ 551s] ^
> > [ 551s] qemu-seccomp.c:57:7: note: in expansion of macro 'SCMP_SYS'
> > [ 551s] { SCMP_SYS(getrlimit), 245 },
> > [ 551s] ^
> > [ 551s] /home/abuild/rpmbuild/BUILD/qemu-2.3.0-rc2/rules.mak:57: recipe
> > for target 'qemu-seccomp.o' failed
> > [ 551s] make: *** [qemu-seccomp.o] Error 1
> >
> > Is this a problem with libseccomp 2.2.0 / master and needs to be fixed
> > in the library? Or do we need to #ifdef some syscalls in qemu-seccomp.c?
>
> This should be already fixed in the library as mentioned by the
> maintainer in this[0] thread. Adding Paul Moore in CC. There's also a
> bug entry on launchpad[1] for that. I provided the patch (before the
> pull reuqest) requesting for some review and testing but never heard
> back again. Also CC'ing Karl-Philipp Richter (bug owner) for some
> opinions on that as well.
>
> Regards,
>
> [0] http://sourceforge.net/p/libseccomp/mailman/message/32955831/
> [1] https://bugs.launchpad.net/qemu/+bug/1363641
This should be fixed with libseccomp v2.2.0; if you are still seeing problems
using v2.2.0 let me know.
--
paul moore
security @ redhat
