While releng build on the January 30th worked fine [1], when I try exactly the same sources today it fails [2]. Does it also mean the mass rebuild was actually not a mass rebuild against rawhide packages? The error: /usr/include/c++/11/type_traits:56:3: error: template with C linkage 56 | template<typename _Tp, _Tp __v> | ^~~~~~~~ src/backends/gnome/GNOMEPlatform.cpp:24:1: note: 'extern "C"' linkage started here 24 | extern "C" { | ^~~~~~~~~~ [1] https://koji.fedoraproject.org/koji/buildinfo?buildID=1695235 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=61596950
This has nothing to do with gcc, apparently glib2 decided to include <type_traits> in one of its headers and several packages errorneously include glib2 headers inside extern "C" blocks. Don't do that.
This is likely a fallout from: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1715 I think it's not a good idea to have C++ consumers patch this individually. Thread on the devel list: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/J3P4TRHLWNDIKXF76OLYZNAPTABCZ3U5/
See https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1715 or https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/J3P4TRHLWNDIKXF76OLYZNAPTABCZ3U5/
Aha, nice, I can fix it on the syncevolution side easily and it makes it build again. In fact, I tried th eold version aonly because I had trouble to build the upcoming syncevolution 2.0 (this particular error wuth the extern "C" is fixed there already). The problem is that the 1.99.2 fails to build [3] with a different error in koji for me and with a very different error in an up to date rawhide machine when I try to build the 1.99.2 locally. The local build ends with: {standard input}: Assembler messages: {standard input}:2634072: Warning: end of file not at end of a line; newline inserted {standard input}:2634901: Warning: zero assumed for missing expression g++: fatal error: Terminated signal terminated program cc1plus compilation terminated. [3] https://lists.syncevolution.org/hyperkitty/list/syncevolution@syncevolution.org/message/HRDFW7LV5E27XKG7ISFS2IMJSACAZ453/
(In reply to Florian Weimer from comment #2) > This is likely a fallout from: > > https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1715 > > I think it's not a good idea to have C++ consumers patch this individually. > > Thread on the devel list: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/ > message/J3P4TRHLWNDIKXF76OLYZNAPTABCZ3U5/ I went ahead and posted an upstream MR to work it around in glib headers so we can avoid patching it in all consumers: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1935 I'll backport it to Fedora if it gets merged upstream.
The glib upstream MR got rejected, which means all consumers are going to have to fix their use of glib headers to not include them in an extern "C" block.
(In reply to Kalev Lember from comment #6) > The glib upstream MR got rejected, which means all consumers are going to > have to fix their use of glib headers to not include them in an extern "C" > block. I can't comment on the upstream merge request, sorry. Please tell them this essentially blocks any use of libraries that use the glib headers from C++ until they have added extern "C++" blocks to their headers, around the function declarations (but not around other header inclusions). That is, all glib-related library headers need to be enhanced for C++ compatibility due to this change. This affects plasma-discover via flatpak, see bug 1927439. The flatpak public headers do not use G_BEGIN_DECLS/G_END_DECLS consistently.
Done: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/1935#note_1034039