In upstream Budgie magpie v1 (Wayland compositor) development, the latest commits fail on Fedora Rawhide with some baffling errors about every method of the std namespace missing. I was able to reproduce this in COPR as well[0] on x86_64[1] and AArch64[2]. This works on GCC 13[3][4], so I'm confused what's going on and I think GCC may be miscompiling things here. [0]: https://copr.fedorainfracloud.org/coprs/ngompa/magpie-wlr/build/6926719/ [1]: https://download.copr.fedorainfracloud.org/results/ngompa/magpie-wlr/fedora-rawhide-x86_64/06926719-magpie-wlr/builder-live.log.gz [2]: https://download.copr.fedorainfracloud.org/results/ngompa/magpie-wlr/fedora-rawhide-aarch64/06926719-magpie-wlr/builder-live.log.gz [3]: https://download.copr.fedorainfracloud.org/results/ngompa/magpie-wlr/fedora-39-x86_64/06926719-magpie-wlr/builder-live.log.gz [4]: https://download.copr.fedorainfracloud.org/results/ngompa/magpie-wlr/fedora-39-aarch64/06926719-magpie-wlr/builder-live.log.gz Reproducible: Always Steps to Reproduce: 1. Build magpie v1 (https://github.com/BuddiesOfBudgie/magpie/tree/v1) on Rawhide Actual Results: Fails to build with errors about all the methods missing Expected Results: Builds properly Magpie v1 is a wlroots-based compositor written in C++ targeting C++20. In upstream CI and in COPR for Fedora, this is built against the wlroots package (currently at wlroots-0.17.1).
My guess is that <stdlib.h> is no longer included before #define namespace _namespace in src/wlr-wrap-start.hpp, and is now implicitly included when that “namespace” macro definition is active. Since <stdlib.h> The workaround is to include <stdlib.h> before defining “namespace”: diff --git a/src/wlr-wrap-start.hpp b/src/wlr-wrap-start.hpp index 0ef0297..afd17b8 100644 --- a/src/wlr-wrap-start.hpp +++ b/src/wlr-wrap-start.hpp @@ -5,6 +5,7 @@ static_assert(0 == 1, "wlroots include wrap started and not ended"); #define WLROOTS_INCLUDE_WRAP_STARTED #include <pthread.h> +#include <stdlib.h> #include <wayland-server-core.h> #ifdef __clang__
(In reply to Neal Gompa from comment #0) > In upstream Budgie magpie v1 (Wayland compositor) development, the latest > commits fail on Fedora Rawhide with some baffling errors about every method > of the std namespace missing. I don't think so. The first error is: ../src/server.cpp: In member function ‘void Server::focus_view(View*, wlr_surface*)’: ../src/server.cpp:64:39: error: cannot convert ‘std::__cxx11::list<View*>::iterator’ to ‘const char*’ 64 | (void) std::remove(views.begin(), views.end(), view); | ~~~~~~~~~~~^~ | | | std::__cxx11::list<View*>::iterator This happens when the std::remove algorithm from the <algorithm> header is not visible, but the std::remove(const char*) function from <cstdio> is declared. The problem is 100% guaranteed to be that <algorithm> was not included. See https://gcc.gnu.org/gcc-14/porting_to.html#header-dep-changes The second error is: In file included from ../src/xwayland.hpp:9, from ../src/xwayland.cpp:1: ../src/wlr-wrap-start.hpp:16:19: error: ‘_namespace’ does not name a type 16 | #define namespace _namespace | ^~~~~~~~~~ I have no idea what this is trying to do, but it's undefined behaviour to define a macro with the same name as a keyword. This code is bad and should feel bad.
(In reply to Jonathan Wakely from comment #2) > (In reply to Neal Gompa from comment #0) > > In upstream Budgie magpie v1 (Wayland compositor) development, the latest > > commits fail on Fedora Rawhide with some baffling errors about every method > > of the std namespace missing. > > I don't think so. > > The first error is: > > > ../src/server.cpp: In member function ‘void Server::focus_view(View*, > wlr_surface*)’: > ../src/server.cpp:64:39: error: cannot convert > ‘std::__cxx11::list<View*>::iterator’ to ‘const char*’ > 64 | (void) std::remove(views.begin(), views.end(), view); > | ~~~~~~~~~~~^~ > | | > | > std::__cxx11::list<View*>::iterator > > > This happens when the std::remove algorithm from the <algorithm> header is > not visible, but the std::remove(const char*) function from <cstdio> is > declared. The problem is 100% guaranteed to be that <algorithm> was not > included. See https://gcc.gnu.org/gcc-14/porting_to.html#header-dep-changes You're correct, that error was caused by <algorithm> not being included. GCC 13 compiled that code just fine with <utility>, but I checked soon after this ticket was created and realized the mistake. > The second error is: > > In file included from ../src/xwayland.hpp:9, > from ../src/xwayland.cpp:1: > ../src/wlr-wrap-start.hpp:16:19: error: ‘_namespace’ does not name a type > 16 | #define namespace _namespace > | ^~~~~~~~~~ > > I have no idea what this is trying to do, but it's undefined behaviour to > define a macro with the same name as a keyword. This code is bad and should > feel bad. Believe me, I wouldn't have written it if it weren't necessary - it's there because the C code that wlr-wrap-start guards against uses "namespace" as a parameter name, so it has to be redefined temporarily to avoid compiler errors.
(In reply to Florian Weimer from comment #1) > My guess is that <stdlib.h> is no longer included before > > #define namespace _namespace > > in src/wlr-wrap-start.hpp, and is now implicitly included when that > “namespace” macro definition is active. Since <stdlib.h> > > The workaround is to include <stdlib.h> before defining “namespace”: > > diff --git a/src/wlr-wrap-start.hpp b/src/wlr-wrap-start.hpp > index 0ef0297..afd17b8 100644 > --- a/src/wlr-wrap-start.hpp > +++ b/src/wlr-wrap-start.hpp > @@ -5,6 +5,7 @@ static_assert(0 == 1, "wlroots include wrap started and not > ended"); > #define WLROOTS_INCLUDE_WRAP_STARTED > > #include <pthread.h> > +#include <stdlib.h> > #include <wayland-server-core.h> > > #ifdef __clang__ This fixed it, thanks.
(In reply to Campbell Jones from comment #3) > Believe me, I wouldn't have written it if it weren't necessary - it's there > because the C code that wlr-wrap-start guards against uses "namespace" as a > parameter name, so it has to be redefined temporarily to avoid compiler > errors. Oh yuck, that does seem unavoidable though.