Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1926239 - glib2: C++ headers need to be included in extern "C++" blocks
Summary: glib2: C++ headers need to be included in extern "C++" blocks
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: glib2
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Matthias Clasen
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-08 13:38 UTC by Milan Crha
Modified: 2021-02-12 10:48 UTC (History)
20 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2021-02-09 10:08:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Milan Crha 2021-02-08 13:38:59 UTC
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

Comment 1 Jakub Jelinek 2021-02-08 13:42:33 UTC
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.

Comment 2 Florian Weimer 2021-02-08 13:43:31 UTC
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/

Comment 4 Milan Crha 2021-02-08 14:05:38 UTC
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/

Comment 5 Kalev Lember 2021-02-09 08:52:33 UTC
(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.

Comment 6 Kalev Lember 2021-02-09 10:08:29 UTC
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.

Comment 7 Florian Weimer 2021-02-12 07:57:14 UTC
(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.


Note You need to log in before you can comment on or make changes to this bug.