I think it should look like this: --- cdefs.h 2017-12-04 13:27:55.640000000 +0100 +++ cdefs.new.h 2017-12-04 13:31:53.820000000 +0100 @@ -1,4 +1,4 @@ -/* Copyright (C) 1992-2017 Free Software Foundation, Inc. +y/* Copyright (C) 1992-2017 Free Software Foundation, Inc. This file is part of the GNU C Library. The GNU C Library is free software; you can redistribute it and/or @@ -471,10 +471,10 @@ testing __STDC_VERSION__ for generic selection support. On the other hand, Clang also defines __GNUC__, so a clang-specific check is required to enable the use of generic selection. */ -#if __GNUC_PREREQ (4, 9) \ +#if !defined __cplusplus && (__GNUC_PREREQ (4, 9) \ || __glibc_clang_has_extension (c_generic_selections) \ || (!defined __GNUC__ && defined __STDC_VERSION__ \ - && __STDC_VERSION__ >= 201112L) + && __STDC_VERSION__ >= 201112L)) # define __HAVE_GENERIC_SELECTION 1 #else # define __HAVE_GENERIC_SELECTION 0 2017-12-04 13:21 GMT+01:00 Gábor Boskovits : > We also have this in bits/floatn.h, but this seems right. > > #if (defined __x86_64__ \ > ? __GNUC_PREREQ (4, 3) \ > : (defined __GNU__ ? __GNUC_PREREQ (4, 5) : __GNUC_PREREQ (4, 4))) > # define __HAVE_FLOAT128 1 > #else > # define __HAVE_FLOAT128 0 > #endif > > /* Defined to 1 if __HAVE_FLOAT128 is 1 and the type is ABI-distinct > > > from the default float, double and long double types in this glibc. */ > #if __HAVE_FLOAT128 > # define __HAVE_DISTINCT_FLOAT128 1 > #else > # define __HAVE_DISTINCT_FLOAT128 0 > #endif > > I think the problem is caused by HAVE_GENERIC_SELECTION defined when we > are in C++. > > > 2017-12-04 13:18 GMT+01:00 Gábor Boskovits : > >> We have this in cdefs.h: >> #if __GNUC_PREREQ (4, 9) \ >> || __glibc_clang_has_extension (c_generic_selections) \ >> || (!defined __GNUC__ && defined __STDC_VERSION__ \ >> && __STDC_VERSION__ >= 201112L) >> # define __HAVE_GENERIC_SELECTION 1 >> #else >> # define __HAVE_GENERIC_SELECTION 0 >> #endif >> >> This does not seem right. >> >> We should not have this defined when compiling c++. >> WDYT? >> >> 2017-12-04 13:03 GMT+01:00 Gábor Boskovits : >> >>> This minimal file reproduces the problem in icu4c 60.1 in guix >>> environment icu4c on current core-updates. >>> >>> #include >>> >>> int main(int argc, char **argv) >>> { >>> std::signbit(1); >>> return 0; >>> } >>> >>> It seems, that it is some problem with cmath.h >>> >>> /gnu/store/2wzijwwgpcdb1msmn3wgq9zmrbrkpx2h-gcc-5.5.0/includ >>> e/c++/cmath:44:0 >>> >>> The definition is in glibc 2.26 math.h, looks like this: >>> >>> #elif __HAVE_DISTINCT_FLOAT128 >>> # if __HAVE_GENERIC_SELECTION >>> # define __MATH_TG(TG_ARG, FUNC, ARGS) \ >>> _Generic ((TG_ARG), \ >>> float: FUNC ## f ARGS, \ >>> default: FUNC ARGS, \ >>> long double: FUNC ## l ARGS, \ >>> _Float128: FUNC ## f128 ARGS) >>> >>> >>> >>> 2017-12-03 23:25 GMT+01:00 Gábor Boskovits : >>> >>>> It seems, that the fix is already included in the 60.1 release for the >>>> xlocal problem. I think we can ignore that. >>>> >>>> 2017-12-03 23:20 GMT+01:00 Gábor Boskovits : >>>> >>>>> It seems, that they issued that already: >>>>> http://bugs.icu-project.org/trac/changeset/40603 >>>>> >>>>> 2017-12-03 23:08 GMT+01:00 Gábor Boskovits : >>>>> >>>>>> Ok, I found this one: >>>>>> https://sourceware.org/glibc/wiki/Release/2.26#Removal_of_.2 >>>>>> 7xlocale.h.27 >>>>>> >>>>>> It seems, that xlocale.h should not be used as an include, and glibc >>>>>> removed that. >>>>>> >>>>>> So this is ok. >>>>>> >>>>>> The question is if this issue was addressed by icu4c, so we can just >>>>>> go to the next step, or should we do something about this. >>>>>> >>>>>> >>>>>> 2017-12-03 23:04 GMT+01:00 Gábor Boskovits : >>>>>> >>>>>>> I've found that simply reverting the update to icu4c 60 commit >>>>>>> brings up the issue you just mentioned, with missing xlocale.h. >>>>>>> So it seems, that the one you found introduced the xlocale problem, >>>>>>> while 4e080fbb0bb73e4444181599676f4e1ef5fdc2ba introduces the new >>>>>>> error. >>>>>>> I think we should deal with the one you find first, the see what's >>>>>>> with this newer one. >>>>>>> >>>>>>> We also have a long running discussion on a bug introduced by a >>>>>>> later glibc update, ee3ebf1a357bd4eb36a2fa1790a7b549cffb305a which >>>>>>> broke a lot of packages. Might these be somehow related? >>>>>>> https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29537 >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2017-12-03 22:46 GMT+01:00 Chris Marusich : >>>>>>> >>>>>>>> Gábor Boskovits writes: >>>>>>>> >>>>>>>> > Any news on this icu4c thing? >>>>>>>> >>>>>>>> After about 2 days of running git bisect, my computer has informed >>>>>>>> me >>>>>>>> that the first bad commit is 67d527e35e367c9e9e89ec01cda2ce >>>>>>>> 32cabd2d89. >>>>>>>> This is the first commit where icu4c fails to build on core-updates. >>>>>>>> The build failure at this commit is as follows: >>>>>>>> >>>>>>>> --8<---------------cut here---------------start------------->8--- >>>>>>>> g++ ... decimfmt.cpp >>>>>>>> g++ ... decimalformatpattern.cpp >>>>>>>> g++ ... dcfmtsym.cpp >>>>>>>> g++ ... digitlst.cpp >>>>>>>> g++ ... fmtable_cnv.cpp >>>>>>>> digitlst.cpp:67:24: fatal error: xlocale.h: No such file or >>>>>>>> directory >>>>>>>> compilation terminated. >>>>>>>> *** Failed compilation command follows: >>>>>>>> ---------------------------------------------------------- >>>>>>>> g++ -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 >>>>>>>> -DU_HAVE_STRTOD_L=1 -I. -I../common -DU_ATTRIBUTE_DEPRECATED= >>>>>>>> -DU_I18N_IMPLEMENTATION -O2 -W -Wall -pedantic -Wpointer-arith >>>>>>>> -Wwrite-strings -Wno-long-long --std=c++0x -c -DPIC -fPIC -o digitlst.o >>>>>>>> digitlst.cpp >>>>>>>> --- ( rebuild with "make VERBOSE=1 all" to show all parameters ) >>>>>>>> -------- >>>>>>>> make[1]: *** [../config/mh-linux:51: digitlst.o] Error 1 >>>>>>>> make[1]: *** Waiting for unfinished jobs.... >>>>>>>> make[1]: Leaving directory '/tmp/guix-build-icu4c-58.2.dr >>>>>>>> v-0/icu/source/i18n' >>>>>>>> make: *** [Makefile:143: all-recursive] Error 2 >>>>>>>> phase `build' failed after 59.0 seconds >>>>>>>> builder for `/gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv' >>>>>>>> failed with exit code 1 >>>>>>>> @ build-failed /gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv >>>>>>>> - 1 builder for `/gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv' >>>>>>>> failed with exit code 1 >>>>>>>> guix build: error: build failed: build of >>>>>>>> `/gnu/store/mdd6glhc0dg65y4wd11y0b7sbky9cwv6-icu4c-58.2.drv' failed >>>>>>>> --8<---------------cut here---------------end--------------->8--- >>>>>>>> >>>>>>>> Note that this is NOT the same error as the one that occurs at >>>>>>>> commit >>>>>>>> d6adba786cf2ab1b26ff083928b64262281ff106 (which is the commit on >>>>>>>> core-updates from which Gábor's branch change-default-icedtea-8 >>>>>>>> branch >>>>>>>> begins). That error is: >>>>>>>> >>>>>>>> --8<---------------cut here---------------start------------->8--- >>>>>>>> g++ ... number_decimalquantity.cpp >>>>>>>> g++ ... number_decimfmtprops.cpp >>>>>>>> number_decimalquantity.cpp: In member function >>>>>>>> ‘icu_60::number::impl::DecimalQuantity& >>>>>>>> icu_60::number::impl::DecimalQuantity::setToDouble(double)’: >>>>>>>> number_decimalquantity.cpp:333:9: error: ‘_Generic’ is not a >>>>>>>> member of ‘std’ >>>>>>>> if (std::signbit(n) != 0) { >>>>>>>> ^ >>>>>>>> In file included from /gnu/store/nz2m4gdvgzcrkqa4xwv >>>>>>>> 360iskh7syj7i-gcc-5.5.0/include/c++/cmath:44:0, >>>>>>>> from number_decimalquantity.cpp:9: >>>>>>>> number_decimalquantity.cpp:333:14: error: expected >>>>>>>> primary-expression before ‘float’ >>>>>>>> if (std::signbit(n) != 0) { >>>>>>>> ^ >>>>>>>> number_decimalquantity.cpp:333:14: error: expected >>>>>>>> primary-expression before ‘default’ >>>>>>>> if (std::signbit(n) != 0) { >>>>>>>> ^ >>>>>>>> number_decimalquantity.cpp:333:14: error: expected >>>>>>>> primary-expression before ‘long’ >>>>>>>> if (std::signbit(n) != 0) { >>>>>>>> ^ >>>>>>>> number_decimalquantity.cpp:333:14: error: expected >>>>>>>> primary-expression before ‘:’ token >>>>>>>> if (std::signbit(n) != 0) { >>>>>>>> ^ >>>>>>>> number_decimalquantity.cpp:337:9: error: ‘__builtin_isnan’ is not >>>>>>>> a member of ‘std’ >>>>>>>> if (std::isnan(n) != 0) { >>>>>>>> ^ >>>>>>>> number_decimalquantity.cpp:337:9: note: suggested alternative: >>>>>>>> : note: ‘__builtin_isnan’ >>>>>>>> number_decimalquantity.cpp:339:16: error: ‘__builtin_isfinite’ is >>>>>>>> not a member of ‘std’ >>>>>>>> } else if (std::isfinite(n) == 0) { >>>>>>>> ^ >>>>>>>> number_decimalquantity.cpp:339:16: note: suggested alternative: >>>>>>>> : note: ‘__builtin_isfinite’ >>>>>>>> *** Failed compilation command follows: >>>>>>>> ---------------------------------------------------------- >>>>>>>> g++ -D_REENTRANT -DU_HAVE_ELF_H=1 -DU_HAVE_ATOMIC=1 >>>>>>>> -DU_HAVE_STRTOD_L=1 -DU_HAVE_XLOCALE_H=0 -I. -I../common >>>>>>>> -DU_ATTRIBUTE_DEPRECATED= -DU_I18N_IMPLEMENTATION -O2 -W -Wall -pedantic >>>>>>>> -Wpointer-arith -Wwrite-strings -Wno-long-long -std=c++11 -c -DPIC -fPIC -o >>>>>>>> number_decimalquantity.o number_decimalquantity.cpp >>>>>>>> --- ( rebuild with "make VERBOSE=1 all" to show all parameters ) >>>>>>>> -------- >>>>>>>> make[1]: *** [../config/mh-linux:51: number_decimalquantity.o] >>>>>>>> Error 1 >>>>>>>> make[1]: *** Waiting for unfinished jobs.... >>>>>>>> make[1]: Leaving directory '/tmp/guix-build-icu4c-60.1.dr >>>>>>>> v-0/icu/source/i18n' >>>>>>>> make: *** [Makefile:149: all-recursive] Error 2 >>>>>>>> phase `build' failed after 122.2 seconds >>>>>>>> builder for `/gnu/store/8s6q5cll4knh7y0wfrbjqs2dai0x4sm2-icu4c-60.1.drv' >>>>>>>> failed with exit code 1 >>>>>>>> @ build-failed /gnu/store/8s6q5cll4knh7y0wfrbjqs2dai0x4sm2-icu4c-60.1.drv >>>>>>>> - 1 builder for `/gnu/store/8s6q5cll4knh7y0wfrbjqs2dai0x4sm2-icu4c-60.1.drv' >>>>>>>> failed with exit code 1 >>>>>>>> guix build: error: build failed: build of >>>>>>>> `/gnu/store/8s6q5cll4knh7y0wfrbjqs2dai0x4sm2-icu4c-60.1.drv' failed >>>>>>>> --8<---------------cut here---------------end--------------->8--- >>>>>>>> >>>>>>>> The fact that these errors are different suggests that more than one >>>>>>>> problem may have been introduced... >>>>>>>> >>>>>>>> I haven't tried any more recent commits on core-updates. I am not >>>>>>>> sure >>>>>>>> what the best way is to debug this, so I would appreciate any advice >>>>>>>> anyone has. >>>>>>>> >>>>>>>> I hope that information helps. Hopefully, together, we can untangle >>>>>>>> this! >>>>>>>> >>>>>>>> -- >>>>>>>> Chris >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >