On Fri, Jul 11, 2025 at 11:45:08AM +0100, Peter Maydell wrote:
> On Tue, 17 Jun 2025 at 21:35, Bernhard Beschow <shen...@gmail.com> wrote:
> >
> > When compiling QEMU against fuse3-3.17.1 with --enable-werror the build
> > fails
> > with:
> >
> > In file included from ../src/block/export/fuse.c:33:
> > /usr/include/fuse3/fuse.h:959:5: error: redundant redeclaration of
> > ‘fuse_main_real_versioned’ [-Werror=redundant-decls]
> > 959 | int fuse_main_real_versioned(int argc, char *argv[],
> > | ^~~~~~~~~~~~~~~~~~~~~~~~
> > /usr/include/fuse3/fuse.h:885:5: note: previous declaration of
> > ‘fuse_main_real_versioned’ with type ‘int(int, char **, const struct
> > fuse_operations *, size_t, struct libfuse_version *, void *)’ {aka
> > ‘int(int, char **, const struct fuse_operations *, long unsigned int,
> > struct libfuse_version *, void *)’}
> > 885 | int fuse_main_real_versioned(int argc, char *argv[],
> > | ^~~~~~~~~~~~~~~~~~~~~~~~
> > cc1: all warnings being treated as errors
> >
> > That is, a fuse header triggers a warning within itself. Since QEMU adds the
> > fuse3 include path via `-I`, the compiler thinks that the header is part of
> > the
> > QEMU project, and thus raises a warning. The compiler can be told to ignore
> > warnings within 3rd party headers by adding these paths via `-isystem`. Fix
> > the
> > above build failure by marking fuse as system dependency. While at it mark
> > every 3rd-party dependency as system dependency to prevent similar issues
> > in the
> > future but skip glib since that results in glib include paths to be omitted
> > from
> > bindgen in case of a Rust build.
>
> The problem with this is that -isystem does not only do "suppress
> warnings in these headers" -- it also alters the search order
> for includes, in a way that can sometimes cause problems:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70129
> So this isn't completely risk-free, though I think meson tries to
> avoid some of this by doing something a bit more complex than a
> pure 's/-I/-isystem/'.
>
> We would also lose the warnings about e.g. use of deprecated
> functions in our dependencies.
>
> All that said, this might still be the best tradeoff.
FWIW, the actual bug mentioned here is a clear regression & mistake in
libfuse3 3.17.1 only, that they really should fix. I've filed this:
https://github.com/libfuse/libfuse/issues/1282
and will likely send a PR too later.
With 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 :|
