On Mon, Feb 02, 2026 at 09:45:52AM -0800, Pierrick Bouvier wrote: > On 2/2/26 9:34 AM, Daniel P. Berrangé wrote: > > On Mon, Feb 02, 2026 at 09:30:31AM -0800, Pierrick Bouvier wrote: > > > On 2/2/26 8:55 AM, Mark Cave-Ayland wrote: > > > > On 02/02/2026 15:42, Cornelia Huck wrote: > > > > > > > > > On Mon, Feb 02 2026, Peter Maydell <[email protected]> wrote: > > > > > > > > > > > On Mon, 2 Feb 2026 at 04:04, Richard Henderson > > > > > > <[email protected]> wrote: > > > > > > > > > > > > > > On 1/30/26 04:41, Pierrick Bouvier wrote: > > > > > > > > On 1/29/26 9:37 AM, Pierrick Bouvier wrote: > > > > > > > > > contrib/plugins: add empty cpp plugin > > > > > > > > > > > > Hi; this fails to build for me on Linux (Ubuntu 24.04) with clang: > > > > > > > > > > > > In file included from ../../contrib/plugins/cpp.cpp:33: > > > > > > /usr/bin/../lib/gcc/x86_64-linux-gnu/14/../../../../include/c++/14/coroutine:38:3: > > > > > > error: "the <coroutine> header requires -fcoroutines" > > > > > > 38 | # error "the <coroutine> header requires -fcoroutines" > > > > > > | ^ > > > > > > 1 error generated. > > > > > > > > > > Fails for me as well on Fedora 42 (x86_64) with gcc: > > > > > > > > > > In file included from ../qemu/contrib/plugins/cpp.cpp:33: > > > > > /usr/include/c++/15/coroutine:43:3: error: #error "the <coroutine> > > > > > header requires -fcoroutines" > > > > > 43 | # error "the <coroutine> header requires -fcoroutines" > > > > > | ^~~~~ > > > > > > > > > > (It works for me on an aarch64 RHEL 9 system.) > > > > > > > > Is this with a clean build? I had exactly the same error message > > > > earlier, but I was able to fix it by destroying my build/ directory, > > > > then re-running configure followed again by make. > > > > > > > > > > Thanks for the reports everyone. > > > > > > I tried it on ubuntu LTS and didn't encounter this problem. > > > What is happening is that meson unfortunately caches default_options set, > > > including the C++ standard version in our case. > > > Thus, you indeed need to clean and rebuild once. > > > > > > The solution for this would be to not use default_options and add the flag > > > to qemu_cflags instead. It's the same limitation if we change the default > > > warning level, or any other option set with default_options. > > > > If that's correct as the root cause, then it feels like this is a meson bug > > that ought to be reported upstream. Any meson.build default_options changes > > that affect the compiler behaviour should invalidate cache in the same way > > as when we modify qemu_cflags. > > > > I totally agree with you Daniel, and I've been bitten by that in my previous > company when updating cpp standard we used. As you can see, it slipped out > of my mind for current series... > > I never understood why it had this counter intuitive behaviour, and didn't > bother to report to be honest, I simply switched to manual flags instead at > the time. > Meson devs usually have a strong opinion of how things should be, so I don't > expect this to be something that fell through the cracks but a deliberate > design choice. > > EDIT: after typing the answer above, did a quick search, and indeed, it's > how it's supposed to be. So be it. > https://github.com/mesonbuild/meson/issues/13556
That's been marked a dupe of: https://github.com/mesonbuild/meson/issues/2193 where Paolo says recent refactoring has (finally) made fixing this problem a pratical task.... but that was 6+ months ago still, so guess we'll have to wait a while yet. 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 :|
