From: "Gábor Boskovits" <boskovits@gmail.com>
To: Chris Marusich <cmmarusich@gmail.com>
Cc: guix-devel <guix-devel@gnu.org>
Subject: Re: java: switch to icedtea-8 as default JDK
Date: Mon, 4 Dec 2017 15:19:12 +0100 [thread overview]
Message-ID: <CAE4v=pjvQYeiKMzFn9dEjvP4bV1B4ay77SuK_NxwfGKbptj-Fg@mail.gmail.com> (raw)
In-Reply-To: <CAE4v=ph-Va86W31h3u06C=+hhUB31695Axfe7KzuFkT8V03X6A@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 12956 bytes --]
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 <boskovits@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 <boskovits@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 <boskovits@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 <boskovits@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 <boskovits@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 <boskovits@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 <boskovits@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 <boskovits@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 <boskovits@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 <cmmarusich@gmail.com>:
>>>>>>>>>
>>>>>>>>>> Gábor Boskovits <boskovits@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
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
[-- Attachment #2: Type: text/html, Size: 18858 bytes --]
next prev parent reply other threads:[~2017-12-04 14:19 UTC|newest]
Thread overview: 76+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-17 22:02 java: switch to icedtea-8 as default JDK Ricardo Wurmus
2017-11-22 8:57 ` Chris Marusich
2017-11-22 12:09 ` Ricardo Wurmus
2017-11-22 17:03 ` Chris Marusich
2017-11-24 7:01 ` Gábor Boskovits
2017-11-24 10:15 ` Ricardo Wurmus
2017-11-24 11:46 ` Gábor Boskovits
2017-11-29 6:48 ` Chris Marusich
2017-11-29 7:12 ` Chris Marusich
2017-11-29 19:05 ` Gábor Boskovits
2017-11-29 19:58 ` Ricardo Wurmus
2017-11-30 6:58 ` Chris Marusich
2017-11-30 19:27 ` Efraim Flashner
2017-12-01 20:41 ` Gábor Boskovits
2017-12-02 7:06 ` Chris Marusich
2017-12-03 9:58 ` Gábor Boskovits
2017-12-03 11:30 ` Gábor Boskovits
2017-12-03 21:46 ` Chris Marusich
2017-12-03 22:04 ` Gábor Boskovits
2017-12-03 22:08 ` Gábor Boskovits
2017-12-03 22:20 ` Gábor Boskovits
2017-12-03 22:25 ` Gábor Boskovits
2017-12-04 12:03 ` Gábor Boskovits
2017-12-04 12:18 ` Gábor Boskovits
2017-12-04 12:21 ` Gábor Boskovits
2017-12-04 12:33 ` Gábor Boskovits
2017-12-04 12:59 ` Gábor Boskovits
2017-12-04 14:19 ` Gábor Boskovits [this message]
2017-12-04 15:44 ` Gábor Boskovits
2017-12-04 16:34 ` Gábor Boskovits
2017-12-04 16:35 ` Gábor Boskovits
2017-12-04 19:15 ` Leo Famulari
2017-12-05 7:07 ` Gábor Boskovits
2017-12-07 17:50 ` Gábor Boskovits
2017-12-08 6:13 ` Gábor Boskovits
2017-12-08 6:55 ` Chris Marusich
2017-12-08 7:01 ` Gábor Boskovits
2017-12-10 15:56 ` Gábor Boskovits
2017-12-12 11:30 ` Gábor Boskovits
2017-12-12 12:27 ` Gábor Boskovits
2017-12-13 2:06 ` Chris Marusich
2017-12-13 8:53 ` Gábor Boskovits
2017-12-13 9:54 ` Gábor Boskovits
2017-12-13 9:59 ` Gábor Boskovits
2017-12-13 10:03 ` Gábor Boskovits
2017-12-13 10:32 ` Efraim Flashner
2017-12-13 11:07 ` Gábor Boskovits
2017-12-13 18:04 ` Gábor Boskovits
2017-12-13 22:50 ` Gábor Boskovits
2017-12-15 13:52 ` Gábor Boskovits
2017-12-15 14:21 ` Gábor Boskovits
2017-12-15 14:33 ` Gábor Boskovits
2017-12-17 7:39 ` Gábor Boskovits
2017-12-17 14:26 ` Ricardo Wurmus
2017-12-17 18:59 ` Gábor Boskovits
2017-12-18 10:02 ` Gábor Boskovits
2017-12-18 12:33 ` Ricardo Wurmus
2017-12-19 8:07 ` Chris Marusich
2017-12-19 9:11 ` Gábor Boskovits
2017-12-19 20:58 ` Gábor Boskovits
2017-12-19 22:11 ` Ricardo Wurmus
2017-12-20 10:34 ` Gábor Boskovits
2017-12-20 12:29 ` Gábor Boskovits
2017-12-21 7:53 ` Gábor Boskovits
2018-01-03 13:06 ` Gábor Boskovits
2018-01-05 15:44 ` Ricardo Wurmus
2018-01-05 16:01 ` Gábor Boskovits
2018-01-06 19:29 ` Chris Marusich
2018-01-06 20:16 ` Gábor Boskovits
2018-01-07 14:52 ` Gábor Boskovits
2018-01-07 17:25 ` Ricardo Wurmus
2018-01-07 18:19 ` Gábor Boskovits
2018-01-08 2:54 ` Chris Marusich
[not found] ` <87d13jhoka.fsf@gmail.com>
2017-12-12 22:49 ` Gábor Boskovits
2017-12-12 22:50 ` Gábor Boskovits
2017-11-29 19:59 ` Ricardo Wurmus
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAE4v=pjvQYeiKMzFn9dEjvP4bV1B4ay77SuK_NxwfGKbptj-Fg@mail.gmail.com' \
--to=boskovits@gmail.com \
--cc=cmmarusich@gmail.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.