On Wed, Apr 03, 2019 at 02:49:48PM +0200, Helge Deller wrote: > On a non-release architecture, the configure program aborts if the > --enable-seccomp flag was given (with no way to work around it on the > command line): > > ERROR: User requested feature libseccomp > configure was not able to find it. > libseccomp is not supported for host cpu parisc64 > > Instead of aborting, fall back to require libseccomp version 2.2.0 > (or any higher version currently installed) which should be OK for > non-release architectures. > > Signed-off-by: Helge Deller <[email protected]> > > diff --git a/configure b/configure > index 1c563a7027..8632267049 100755 > --- a/configure > +++ b/configure > @@ -2389,7 +2389,6 @@ if test "$seccomp" != "no" ; then > libseccomp_minver="2.3.0" > ;; > *) > - libseccomp_minver="" > ;; > esac
This makes sense to me. From a QEMU source POV we are able to build with libseccomp >= 2.2.0, which our default libseccomp_minver= env expresses a few lines earlier. If libseccomp isn't supported on a platform, then I think we should just assume that libseccomp won't be present in the OS install we are building against. I don't think QEMU needs to second-guess whether or not it is supported on the given architecture. In fact I'd go as far as to say we could probably just remove all this per-arch checking and just have a generic >= 2.2.0 check, and just rely on fact libseccomp won't exist on a s390/ppc/etc host if the distro had version < 2.3.0 Anyway, this particular patch is better than what we have so on that basis I think we can just apply this as-is: Reviewed-by: Daniel P. Berrangé <[email protected]> Regards, Daniel -- |: https://berrange.com -o- https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o- https://fstop138.berrange.com :| |: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
