Now that this problem around glibc is resolved, I think I will do some history rewrite, so that these reverts, reverting the revert.... does not show up. I 'm also willing to rename the branch to have wip in the name, as this seems to be standard for longer runnig parts. WDYT? 2017-12-04 15:19 GMT+01:00 Gábor Boskovits : > Ok, so it seems, that the latest glibc update was made to fix the icu4c > thing. > It just broke the locales. > Fix for that has just been pushed, making core-updates usable again. > I pushed to my icedtea branch also. > I'm now building it to see what we have now. > > 2017-12-04 13:59 GMT+01:00 Gábor Boskovits : > >> Upstream corrected the issue in commit 6913ad65e00bb32417ad39c41d292b >> 976171e27e. >> >> It is not yet included in 2.26. >> >> The patch is basically the same as I proposed. >> >> I think we should get the upstream version. >> >> 2017-12-04 13:33 GMT+01:00 Gábor Boskovits : >> >>> 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 >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> >