On Fri, Jul 11, 2025 at 12:00:24PM +0100, Daniel P. Berrangé wrote:
> 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.

The issue turned out to already be fixed in libfuse git master. So given
that the problem only appears in one single release, IMHO, the best thing
is to ignore it. Any distro which ships the broken libfuse should either
update it, or cherry-pick the trivial header file bugfix from git.


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 :|


Reply via email to