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/ > include/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 >>>>>> >>>>> >>>>> >>>> >>> >> >