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 <boskov...@gmail.com>:
> 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 <boskov...@gmail.com>:
>
>> 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 <boskov...@gmail.com>:
>>
>>> 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 <boskov...@gmail.com>:
>>>
>>>> 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 <boskov...@gmail.com>:
>>>>
>>>>> 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 <boskov...@gmail.com>:
>>>>>
>>>>>> This minimal file reproduces the problem in icu4c 60.1 in guix
>>>>>> environment icu4c on current core-updates.
>>>>>>
>>>>>> #include <cmath>
>>>>>>
>>>>>> 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 <boskov...@gmail.com>:
>>>>>>
>>>>>>> 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 <boskov...@gmail.com>:
>>>>>>>
>>>>>>>> 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 <boskov...@gmail.com>:
>>>>>>>>
>>>>>>>>> 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 <boskov...@gmail.com>:
>>>>>>>>>
>>>>>>>>>> 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 <cmmarus...@gmail.com>:
>>>>>>>>>>
>>>>>>>>>>> Gábor Boskovits <boskov...@gmail.com> 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:
>>>>>>>>>>> <built-in>: 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:
>>>>>>>>>>> <built-in>: 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
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
