GNOME Bugzilla – Bug 786717
Build fails with gcc 7.1.0 (mingw-w64) due to a macro name conflict
Last modified: 2017-09-05 18:17:21 UTC
Build fails with the following error: CXX dispatcher.lo dispatcher.cc: In constructor 'Glib::DispatchNotifier::DispatchNotifier(Glib::RefPtr<Glib::MainContext>&)': dispatcher.cc:228:67: error: expected unqualified-id before ')' token const auto source = IOSource::create(fd, Glib::IOCondition::IN); This is because IN and OUT are defined as empty macros in minwindef.h: #ifndef IN #define IN #endif I think it started with windows 10 SDK. Not sure how to avoid it, as a temporary fix I used #undef after windows includes.
Created attachment 358819 [details] [review] patch: Glib::IOCondition: Add an IO_ prefix to the enumerator names This patch reintroduces the IO_ prefix. Before we used scoped enums (enum class) some of the enumerator names were Glib::IO_IN and Glib::IO_OUT. With this patch they become Glib::IOCondition::IO_IN and Glib::IOCondition::IO_OUT instead of Glib::IOCondition::IN and Glib::IOCondition::OUT. I leave the patch here for a while before I push it, so people can comment on it. Hopefully there is a better solution. Why are IN and OUT defined as empty macros? Preprocessor macros are so intrusive. The only scope they respect is quoted strings, where they don't replace anything.
On which compiler? At least in MSYS2, you can define _NO_W32_PSEUDO_MODIFIERS to avoid them: https://github.com/Alexpux/mingw-w64/blob/master/mingw-w64-headers/include/minwindef.h#L55 If your compiler differs, maybe that is a standard define option.
>Why are IN and OUT defined as empty macros? I believe that back in the day some people used to mark function parameters as IN and OUT, e. g. void do_stuff(char * IN data) > you can define _NO_W32_PSEUDO_MODIFIERS This is true for mingw, but this definition guard is not present in Windows 10 SDK installation, so some other compilers might not have it. I think MinGW people added it for sanity, because defining such a simple terms is really easy way to shoot yourself in the foot.
I guess we should apply the patch. We could work around it with clever undeffing, but I'd rather avoid that complication.
I have pushed the patch to the master branch.