On 10/22/2016 03:55 PM, Paul Howarth wrote:
On Fri, 21 Oct 2016 16:20:32 -0600 Orion Poplawski <orion@xxxxxxxxxxxxx> wrote:FYI - I'm starting to see more builds fail with errors like the following in rawhide: In file included from /usr/include/c++/6.2.1/cmath:45:0, from /usr/include/c++/6.2.1/math.h:36, from /usr/include/cubew/cubew_report_layouts_types.h:28, from /usr/include/cubew/cubew_types.h:31, from /usr/include/cubew/cubew_metric.h:28, from ../../build-backend/../src/scout/Pattern.h:24, from ../../build-backend/../src/scout/OmpPattern.h:21, from ../../build-backend/../src/scout/OmpPattern.cpp:20: /usr/include/math.h:346:1: error: template with C linkage template <class __T> inline bool ^~~~~~~~ The problem seems to be in various C libraries wrapping system #includes inside of extern "C" {} blocks. I've just fixed cube and grib_api, but there may be others out there.Does this one mean perl needs fixing? https://apps.fedoraproject.org/koschei/package/perl-Text-Hunspell?collection=f26 In file included from /usr/include/c++/6.2.1/cmath:45:0, from /usr/include/c++/6.2.1/math.h:36, from /usr/lib/perl5/CORE/perl.h:2109, from Hunspell.xs:9: /usr/include/math.h:346:1: error: template with C linkage
There is no immediate need, glibc-2.24.90-13.fc26 ought to hit rawhide in a couple of hours and should be compatible with extern "C" wrappers again.
(Some non-glibc system headers might still need an externally supplied extern "C", and working out which ones do and which ones don't seems a lot of trouble, so I expect that we will strive to keep compatibility with a blanket extern "C" wrapper in glibc at least.)
Thanks, Florian _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
