Acknowledgement sent
to Andreas Enge <andreas@enge.fr>:
New bug report received and forwarded. Copy sent to bug-guix@gnu.org.
(Wed, 23 Sep 2020 16:23:02 GMT) (full text, mbox, link).
Hello,
this report is related to
https://github.com/fplll/fplll/issues/444
The following test file round.cpp does not compile with our g++-10.2.0:
#include <cfenv>
int main () {
return std::fegetround ();
}
Compilation (also when adding "--std=c++11") prints the error:
round.cpp: In function 'int main()':
round.cpp:4:16: error: 'fegetround' is not a member of 'std'; did you mean 'fegetround'?
4 | return std::fegetround ();
| ^~~~~~~~~~
In file included from /home/andreas/.guix-profile/include/c++/fenv.h:36,
from /home/andreas/.guix-profile/include/c++/cfenv:41,
from round.cpp:1:
/home/andreas/.guix-profile/include/fenv.h:104:12: note: 'fegetround' declared here
104 | extern int fegetround (void) __THROW __attribute_pure__;
| ^~~~~~~~~~
Compilation succeeds when replacing std::fegetround by fegetround; however,
the former is supposedly part of the C++11 standard.
The culprit is apparently cfenv, which contains the following:
#if _GLIBCXX_HAVE_FENV_H
#include_next <fenv.h>
#endif
#if _GLIBCXX_USE_C99_FENV_TR1
...
#undef fegetround
...
namespace std
{
...
using ::fegetround;
...
}
Our include/c++/x86_64-unknown-linux-gnu/bits/c++config.h has this:
#define _GLIBCXX_HAVE_FENV_H 1
/* Define if C99 functions in <fenv.h> should be imported in <tr1/cfenv> in
namespace std::tr1. */
/* #undef _GLIBCXX_USE_C99_FENV_TR1 */
whereas apparently on other distributions (opensuse, for instance),
_GLIBCXX_USE_C99_FENV_TR1 is defined and leads to std::fesetround being
defined.
And when I look at the build log
https://ci.guix.gnu.org/log/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0
for instance, there are the following lines:
checking for ISO C99 support to TR1 in <fenv.h>... no
checking for ISO C99 support to TR1 in <stdint.h>... yes
checking for ISO C99 support to TR1 in <math.h>... yes
checking for ISO C99 support to TR1 in <inttypes.h>... yes
whereas in opensuse, there is
checking for ISO C99 support to TR1 in <fenv.h>... yes
Now it would be interesting to have a look at config.log for gcc...
Andreas
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Wed, 23 Sep 2020 16:38:02 GMT) (full text, mbox, link).
Subject: Re: bug#43579: g++ does not provide std::fegetround
Date: Wed, 23 Sep 2020 18:36:32 +0200
On Wed, Sep 23, 2020 at 06:21:21PM +0200, Andreas Enge wrote:
> Now it would be interesting to have a look at config.log for gcc...
I did so with gcc-10.2.0 and executed ./configure in the subdirectory
libstdc++-v3. The relevant part of config.log is this:
configure:16462: checking for ISO C99 support to TR1 in <fenv.h>
configure:16490: g++ -c -std=c++98 conftest.cpp >&5
configure:16490: $? = 0
configure:16497: result: yes
This is when trying to compile gcc-10.2.0 with gcc-10.2.0; so somehow
our bootstrapping process does something differently when creating the
final user facing gcc.
Andreas
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Wed, 23 Sep 2020 19:03:02 GMT) (full text, mbox, link).
Subject: Re: bug#43579: g++ does not provide std::fegetround
Date: Wed, 23 Sep 2020 21:03:54 +0200
Andreas Enge <andreas@enge.fr> writes:
> Hello,
>
> this report is related to
> https://github.com/fplll/fplll/issues/444
>
> The following test file round.cpp does not compile with our g++-10.2.0:
> #include <cfenv>
> int main () {
> return std::fegetround ();
> }
>
>
> Compilation (also when adding "--std=c++11") prints the error:
> round.cpp: In function 'int main()':
> round.cpp:4:16: error: 'fegetround' is not a member of 'std'; did you mean 'fegetround'?
> 4 | return std::fegetround ();
> | ^~~~~~~~~~
> In file included from /home/andreas/.guix-profile/include/c++/fenv.h:36,
> from /home/andreas/.guix-profile/include/c++/cfenv:41,
> from round.cpp:1:
> /home/andreas/.guix-profile/include/fenv.h:104:12: note: 'fegetround' declared here
> 104 | extern int fegetround (void) __THROW __attribute_pure__;
> | ^~~~~~~~~~
Is this perhaps related to https://issues.guix.gnu.org/42392 ?
--
Ricardo
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Wed, 23 Sep 2020 20:07:01 GMT) (full text, mbox, link).
Subject: Re: bug#43579: g++ does not provide std::fegetround
Date: Wed, 23 Sep 2020 22:05:43 +0200
On Wed, Sep 23, 2020 at 09:03:54PM +0200, Ricardo Wurmus wrote:
> Is this perhaps related to https://issues.guix.gnu.org/42392 ?
It looks very similar indeed. But then the fix given there has not fixed
my problem, which occurs in a current gcc-toolchain.
Andreas
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Wed, 23 Sep 2020 20:22:02 GMT) (full text, mbox, link).
Subject: Re: bug#43579: g++ does not provide std::fegetround
Date: Wed, 23 Sep 2020 22:20:11 +0200
On Wed, Sep 23, 2020 at 10:05:43PM +0200, Andreas Enge wrote:
> It looks very similar indeed. But then the fix given there has not fixed
> my problem, which occurs in a current gcc-toolchain.
My impression is that the root cause is the same one, that we are somehow
misconfiguring our gcc builds, as discussed in this thread:
https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00096.html
And that the hacky fix works for the other problems, but apparently not
for this one.
Andreas
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Wed, 23 Sep 2020 21:28:01 GMT) (full text, mbox, link).
Subject: Re: bug#43579: g++ does not provide std::fegetround
Date: Wed, 23 Sep 2020 23:28:36 +0200
Andreas Enge <andreas@enge.fr> writes:
> On Wed, Sep 23, 2020 at 10:05:43PM +0200, Andreas Enge wrote:
>> It looks very similar indeed. But then the fix given there has not fixed
>> my problem, which occurs in a current gcc-toolchain.
>
> My impression is that the root cause is the same one, that we are somehow
> misconfiguring our gcc builds, as discussed in this thread:
> https://lists.gnu.org/archive/html/guix-devel/2020-06/msg00096.html
>
> And that the hacky fix works for the other problems, but apparently not
> for this one.
I’m having a different but possibly related problem with
arm-none-eabi-nano-toolchain-7-2018-q2-update, which used to work some
time ago (in axoloti-patcher-next).
For that issue the hack also did not work.
--
Ricardo
Severity set to 'important' from 'normal'
Request was from Maxim Cournoyer <maxim.cournoyer@gmail.com>
to control@debbugs.gnu.org.
(Thu, 24 Sep 2020 04:48:02 GMT) (full text, mbox, link).
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Thu, 01 Oct 2020 12:37:02 GMT) (full text, mbox, link).
Subject: Re: bug#43579: g++ does not provide std::fegetround
Date: Thu, 01 Oct 2020 14:36:28 +0200
Hallo!
Andreas Enge <andreas@enge.fr> skribis:
> The following test file round.cpp does not compile with our g++-10.2.0:
> #include <cfenv>
> int main () {
> return std::fegetround ();
> }
Could you provide detailed steps to reproduce it?
Thanks,
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Fri, 02 Oct 2020 02:40:01 GMT) (full text, mbox, link).
Cc: Andreas Enge <andreas@enge.fr>, 43579@debbugs.gnu.org
Subject: Re: bug#43579: g++ does not provide std::fegetround
Date: Thu, 01 Oct 2020 21:39:35 -0500
Ludovic Courtès <ludo@gnu.org> writes:
> Hallo!
>
> Andreas Enge <andreas@enge.fr> skribis:
>
>> The following test file round.cpp does not compile with our g++-10.2.0:
>> #include <cfenv>
>> int main () {
>> return std::fegetround ();
>> }
>
> Could you provide detailed steps to reproduce it?
>
> Thanks,
> Ludo’.
I believe `std::fegetround` was introduced in C++11, are you using the
appropriate flag?
Brett Gilio
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Fri, 02 Oct 2020 18:07:01 GMT) (full text, mbox, link).
Hello,
On Thu, Oct 01, 2020 at 09:39:35PM -0500, Brett Gilio wrote:
> >> The following test file round.cpp does not compile with our g++-10.2.0:
> >> #include <cfenv>
> >> int main () {
> >> return std::fegetround ();
> >> }
> >
> > Could you provide detailed steps to reproduce it?
well, just put these lines into a file called "round.cpp" (as attached),
and then
gcc round.cpp
produces
round.cpp: In function 'int main()':
round.cpp:3:16: error: 'fegetround' is not a member of 'std'; did you mean 'fegetround'?
3 | return std::fegetround ();
| ^~~~~~~~~~
In file included from /home/andreas/.guix-profile/include/c++/fenv.h:36,
from /home/andreas/.guix-profile/include/c++/cfenv:41,
from round.cpp:1:
/home/andreas/.guix-profile/include/fenv.h:104:12: note: 'fegetround' declared here
104 | extern int fegetround (void) __THROW __attribute_pure__;
| ^~~~~~~~~~
On Thu, Oct 01, 2020 at 09:39:35PM -0500, Brett Gilio wrote:
> I believe `std::fegetround` was introduced in C++11, are you using the
> appropriate flag?
And then you can use any of
gcc --std=c++17 round.cpp
gcc --std=c++14 round.cpp
gcc --std=c++11 round.cpp
with the same outcome.
The issue
https://github.com/fplll/fplll/issues/444
I referenced in my bug report provides more discussion; the outcome was that
it is a bug in Guix. I will try to summarise it in the following to make this
bug report self-contained; all file and directory names are relative to
`guix build gcc-toolchain`.
include/c++/cfenv does this around line 41:
#if _GLIBCXX_HAVE_FENV_H
# include <fenv.h>
#endif
include/c++/fenv.h has this in line 34:
#include <bits/c++config.h>
include/c++/x86_64-unknown-linux-gnu/bits/c++config.h has this around line 28:
/* Define if C99 functions in <fenv.h> should be imported in <tr1/cfenv> in
namespace std::tr1. */
/* #undef _GLIBCXX_USE_C99_FENV_TR1 */
And back to include/c++/fenv.h from line 41 on:
#if _GLIBCXX_USE_C99_FENV_TR1
#undef feclearexcept
#undef fegetexceptflag
#undef feraiseexcept
#undef fesetexceptflag
#undef fetestexcept
#undef fegetround
#undef fesetround
...
namespace std
{
...
using ::fegetround;
using ::fesetround;
...
}
#endif // _GLIBCXX_USE_C99_FENV_TR1
The difference to the Opensuse headers is that in bits/c++config.h,
they define _GLIBCXX_USE_C99_FENV_TR1, which, as I understand it,
removes the fe* functions from the global namespace to put them back into
the std:: namespace.
This should happen somewhere in a configure phase inside the gcc build, but
I do not know how to obtain the config.log file easily (short of adding a
phase "(const #f)" to the build recipe and doing a "guix build -K").
Andreas
Subject: Re: bug#43579: g++ does not provide std::fegetround
Date: Sat, 03 Oct 2020 12:02:18 +0200
Hi,
(Cc’ing Maxim who’s looked into this before.)
Andreas Enge <andreas@enge.fr> skribis:
> well, just put these lines into a file called "round.cpp" (as attached),
> and then
> gcc round.cpp
Ah yes, I wasn’t sure if this was ‘gcc-toolchain’ or not. Only 7.x (the
current ‘gcc-final’) works:
--8<---------------cut here---------------start------------->8---
$ cat t.cpp
#include <cfenv>
int main () {
return std::fegetround ();
}
$ guix environment -C --ad-hoc gcc-toolchain@7 -- g++ -Wall -c t.cpp
$ guix environment -C --ad-hoc gcc-toolchain -- g++ -Wall -c t.cpp
t.cpp: In function 'int main()':
t.cpp:3:16: error: 'fegetround' is not a member of 'std'; did you mean 'fegetround'?
3 | return std::fegetround ();
| ^~~~~~~~~~
In file included from /gnu/store/maa9v3r0l3kzi9y20mz5m5c1f83m75n5-profile/include/c++/fenv.h:36,
from /gnu/store/maa9v3r0l3kzi9y20mz5m5c1f83m75n5-profile/include/c++/cfenv:41,
from t.cpp:1:
/gnu/store/maa9v3r0l3kzi9y20mz5m5c1f83m75n5-profile/include/fenv.h:104:12: note: 'fegetround' declared here
104 | extern int fegetround (void) __THROW __attribute_pure__;
| ^~~~~~~~~~
$ guix describe
Generacio 162 Oct 01 2020 00:23:38 (nuna)
guix 7607ace
repository URL: https://git.savannah.gnu.org/git/guix.git
branch: master
commit: 7607ace5091aea0157ba5c8a508129cc5fc4f931
--8<---------------cut here---------------end--------------->8---
It’s the same story as <https://issues.guix.gnu.org/42392>.
> The difference to the Opensuse headers is that in bits/c++config.h,
> they define _GLIBCXX_USE_C99_FENV_TR1, which, as I understand it,
> removes the fe* functions from the global namespace to put them back into
> the std:: namespace.
Indeed, the build log of ‘gcc-10’ for instance has this:
--8<---------------cut here---------------start------------->8---
checking fenv.h usability... yes
checking fenv.h presence... yes
checking for fenv.h... yes
checking for complex.h... (cached) yes
checking for complex.h... (cached) yes
checking for ISO C99 support to TR1 in <complex.h>... yes
checking for ISO C99 support to TR1 in <ctype.h>... yes
checking for fenv.h... (cached) yes
checking for ISO C99 support to TR1 in <fenv.h>... no
--8<---------------cut here---------------end--------------->8---
Here’s the ‘prev-x86_64-unknown-linux-gnu/libstdc++-v3/config.log’
excerpt:
--8<---------------cut here---------------start------------->8---
configure:16448: checking for fenv.h
configure:16448: result: yes
configure:16462: checking for ISO C99 support to TR1 in <fenv.h>
configure:16490: /tmp/guix-build-gcc-10.2.0.drv-0/build/./gcc/xgcc -shared-libgcc -B/tmp/guix-build-gcc-10.2.0.drv-0/build/./gcc -nostdinc++ -L/tmp/guix-build-gcc-10.2.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/tmp/guix-build-gcc-10.2.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/tmp/guix-build-gcc-10.2.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/gnu/store/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0/x86_64-unknown-linux-gnu/bin/ -B/gnu/store/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0/x86_64-unknown-linux-gnu/lib/ -isystem /gnu/store/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0/x86_64-unknown-linux-gnu/include -isystem /gnu/store/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0/x86_64-unknown-linux-gnu/sys-include -fno-checking -c -g -O2 -D_GNU_SOURCE -std=c++98 conftest.cpp >&5
conftest.cpp: In function 'int main()':
conftest.cpp:102:7: error: 'fexcept_t' was not declared in this scope; did you mean 'except'?
102 | fexcept_t* pflag;
| ^~~~~~~~~
| except
conftest.cpp:102:18: error: 'pflag' was not declared in this scope
102 | fexcept_t* pflag;
| ^~~~~
conftest.cpp:103:7: error: 'fenv_t' was not declared in this scope
103 | fenv_t* penv;
| ^~~~~~
conftest.cpp:103:15: error: 'penv' was not declared in this scope
103 | fenv_t* penv;
| ^~~~
conftest.cpp:105:13: error: 'feclearexcept' was not declared in this scope
105 | ret = feclearexcept(except);
| ^~~~~~~~~~~~~
conftest.cpp:106:13: error: 'fegetexceptflag' was not declared in this scope
106 | ret = fegetexceptflag(pflag, except);
| ^~~~~~~~~~~~~~~
conftest.cpp:107:13: error: 'feraiseexcept' was not declared in this scope
107 | ret = feraiseexcept(except);
| ^~~~~~~~~~~~~
conftest.cpp:108:13: error: 'fesetexceptflag' was not declared in this scope
108 | ret = fesetexceptflag(pflag, except);
| ^~~~~~~~~~~~~~~
conftest.cpp:109:13: error: 'fetestexcept' was not declared in this scope
109 | ret = fetestexcept(except);
| ^~~~~~~~~~~~
conftest.cpp:110:13: error: 'fegetround' was not declared in this scope
110 | ret = fegetround();
| ^~~~~~~~~~
conftest.cpp:111:13: error: 'fesetround' was not declared in this scope
111 | ret = fesetround(mode);
| ^~~~~~~~~~
conftest.cpp:112:13: error: 'fegetenv' was not declared in this scope
112 | ret = fegetenv(penv);
| ^~~~~~~~
conftest.cpp:113:13: error: 'feholdexcept' was not declared in this scope
113 | ret = feholdexcept(penv);
| ^~~~~~~~~~~~
conftest.cpp:114:13: error: 'fesetenv' was not declared in this scope
114 | ret = fesetenv(penv);
| ^~~~~~~~
conftest.cpp:115:13: error: 'feupdateenv' was not declared in this scope
115 | ret = feupdateenv(penv);
| ^~~~~~~~~~~
configure:16490: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME "package-unused"
| #define PACKAGE_TARNAME "libstdc++"
| #define PACKAGE_VERSION "version-unused"
| #define PACKAGE_STRING "package-unused version-unused"
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_DLFCN_H 1
| #define LT_OBJDIR ".libs/"
| #define _GLIBCXX_HOSTED 1
| #define _GLIBCXX_VERBOSE 1
| #define _GLIBCXX_ATOMIC_BUILTINS 1
| #define HAVE_ATOMIC_LOCK_POLICY 1
| #define _GLIBCXX_USE_DECIMAL_FLOAT 1
| #define _GLIBCXX_USE_INT128 1
| #define HAVE_STRXFRM_L 1
| #define HAVE_STRERROR_L 1
| #define HAVE_STRERROR_R 1
| #define _GLIBCXX_USE_LONG_LONG 1
| #define HAVE_WCHAR_H 1
| #define HAVE_MBSTATE_T 1
| #define HAVE_WCTYPE_H 1
| #define _GLIBCXX_USE_WCHAR_T 1
| #define _GLIBCXX98_USE_C99_MATH 1
| #define HAVE_TGMATH_H 1
| #define HAVE_COMPLEX_H 1
| #define _GLIBCXX98_USE_C99_COMPLEX 1
| #define _GLIBCXX98_USE_C99_STDIO 1
| #define _GLIBCXX98_USE_C99_STDLIB 1
| #define HAVE_VFWSCANF 1
| #define HAVE_VSWSCANF 1
| #define HAVE_VWSCANF 1
| #define HAVE_WCSTOF 1
| #define HAVE_ISWBLANK 1
| #define _GLIBCXX98_USE_C99_WCHAR 1
| #define _GLIBCXX_USE_C99 1
| #define _GLIBCXX11_USE_C99_MATH 1
| #define HAVE_TGMATH_H 1
| #define HAVE_COMPLEX_H 1
| #define _GLIBCXX11_USE_C99_COMPLEX 1
| #define _GLIBCXX11_USE_C99_STDIO 1
| #define _GLIBCXX11_USE_C99_STDLIB 1
| #define HAVE_VFWSCANF 1
| #define HAVE_VSWSCANF 1
| #define HAVE_VWSCANF 1
| #define HAVE_WCSTOF 1
| #define HAVE_ISWBLANK 1
| #define _GLIBCXX11_USE_C99_WCHAR 1
| #define _GLIBCXX_FULLY_DYNAMIC_STRING 0
| #define HAVE_GETS 1
| #define HAVE_EOWNERDEAD 1
| #define HAVE_ENOTRECOVERABLE 1
| #define HAVE_ENOLINK 1
| #define HAVE_EPROTO 1
| #define HAVE_ENODATA 1
| #define HAVE_ENOSR 1
| #define HAVE_ENOSTR 1
| #define HAVE_ETIME 1
| #define HAVE_EBADMSG 1
| #define HAVE_ECANCELED 1
| #define HAVE_EOVERFLOW 1
| #define HAVE_ENOTSUP 1
| #define HAVE_EIDRM 1
| #define HAVE_ETXTBSY 1
| #define HAVE_ECHILD 1
| #define HAVE_ENOSPC 1
| #define HAVE_EPERM 1
| #define HAVE_ETIMEDOUT 1
| #define HAVE_EWOULDBLOCK 1
| #define HAVE_UCHAR_H 1
| #define _GLIBCXX_USE_C11_UCHAR_CXX11 1
| #define HAVE_INT64_T 1
| #define HAVE_INT64_T_LONG 1
| #define _GLIBCXX_USE_LFS 1
| #define HAVE_SYS_IOCTL_H 1
| #define HAVE_POLL 1
| #define HAVE_S_ISREG 1
| #define HAVE_SYS_UIO_H 1
| #define HAVE_WRITEV 1
| #define HAVE_FENV_H 1
| #define HAVE_COMPLEX_H 1
| #define HAVE_COMPLEX_H 1
| #define _GLIBCXX_USE_C99_COMPLEX_TR1 1
| #define _GLIBCXX_USE_C99_CTYPE_TR1 1
| #define HAVE_FENV_H 1
| /* end confdefs.h. */
| #include <fenv.h>
| int
| main ()
| {
| int except, mode;
| fexcept_t* pflag;
| fenv_t* penv;
| int ret;
| ret = feclearexcept(except);
| ret = fegetexceptflag(pflag, except);
| ret = feraiseexcept(except);
| ret = fesetexceptflag(pflag, except);
| ret = fetestexcept(except);
| ret = fegetround();
| ret = fesetround(mode);
| ret = fegetenv(penv);
| ret = feholdexcept(penv);
| ret = fesetenv(penv);
| ret = feupdateenv(penv);
|
| ;
| return 0;
| }
configure:16497: result: no
--8<---------------cut here---------------end--------------->8---
The same program builds fine outside.
Turns out GCC provides <fenv.h>, too:
--8<---------------cut here---------------start------------->8---
$ find /tmp/guix-build-gcc-10.2.0.drv-0/ -name fenv.h
/tmp/guix-build-gcc-10.2.0.drv-0/gcc-10.2.0/fixincludes/tests/base/bits/fenv.h
/tmp/guix-build-gcc-10.2.0.drv-0/gcc-10.2.0/libstdc++-v3/include/tr1/fenv.h
/tmp/guix-build-gcc-10.2.0.drv-0/gcc-10.2.0/libstdc++-v3/include/c_compatibility/fenv.h
/tmp/guix-build-gcc-10.2.0.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/tr1/fenv.h
/tmp/guix-build-gcc-10.2.0.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/fenv.h
--8<---------------cut here---------------end--------------->8---
So this is again #include_next not picking the right <fenv.h> due to
search path ordering issues and/or duplicate entries.
Thoughts anyone?
I think we need a proper fix but the feedback we got from GCC folks last
time didn’t give me much insight as to what we should do.
> This should happen somewhere in a configure phase inside the gcc build, but
> I do not know how to obtain the config.log file easily (short of adding a
> phase "(const #f)" to the build recipe and doing a "guix build -K").
I do:
guix build -e '(@ (gnu packages gcc) gcc-10)' --no-grafts --check -K
Then I hit C-c once the relevant ‘configure’ has run (you can check
what’s in /tmp/guix-build-gcc-10*). :-)
Thanks,
Ludo’.
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Fri, 13 Nov 2020 18:01:01 GMT) (full text, mbox, link).
Hi!
Ludovic Courtès <ludo@gnu.org> writes:
>[...]
> It’s the same story as <https://issues.guix.gnu.org/42392>.
>[...]
> So this is again #include_next not picking the right <fenv.h> due to
> search path ordering issues and/or duplicate entries.
>
> Thoughts anyone?
>
> I think we need a proper fix but the feedback we got from GCC folks last
> time didn’t give me much insight as to what we should do.
AFAIR, the issue comes from using XXX_INCLUDE_PATH instead of CPATH
because it includes gcc predefined paths:
1. The order matters.
2. The internal order may need duplicated paths.
3. Even providing the right duplicated paths through these variables
may not be supported may not work, it's an implementation detail after
all.
This was changed because we wanted to avoid warnings on installed
libraries which could be raised to errors with -Werror. I personally
don't like that approach, as the included headers are being compiled in
that moment so I think the -Werror should apply too, but indeed I
understand the reasons behind the compatibility with FHS.
The problem comes to generalizing this approach: there should be inputs
that must not enter the realm of these variables, mainly gcc and libc,
libc:static, libstdc++, and so on.
The attached WIP-patch would be a rough approach to that, but it will
take some time until I recompile the world to really test it. Also this
isn't the best approach as the manifests shouldn't include these
neither, but I still don't find where and how to mark these inputs
cleanly.
WDYT? Any idea is welcome. :-)
Happy hacking!
Miguel
Hi,
I just rediscovered this issue by adding “gcc-7” to a package’s input
without also adjusting the variable that determines the order of
includes. (I ended up not needing to use GCC 7 in the end.)
Seeing that issue #42392 (“GCC includes ordering issue? g++: error:
'round' is not a member of 'std'”) has since been solved, should we
close this issue, too?
Or are there still reasons to want an adjustment of the
gnu-build-system? What do you think, Miguel?
--
Ricardo
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Mon, 13 Jun 2022 17:04:01 GMT) (full text, mbox, link).
After removing the patch that works around this problem in fplll
with commit 5dec5f65ec3c7371dde309a101b85b930e423a46, I noticed that it
actually still does occur.
We used to have the problem with gcc-toolchain@10.2 that with test.cpp equal to
#include <cfenv>
int main() {
std::fesetround (FE_TONEAREST);
return 1;
}
the compilation "g++ test.cpp" fails. With gcc-toolchain@10.3 it actually
succeeds.
But with gcc-toolchain@11.3 or @12.1 it fails again.
Indeed,
/gnu/store/bxh206gz379wkn8cvb2ghlkvpqgwfd2v-gcc-toolchain-10.3.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h
contains in line 1572:
#define _GLIBCXX_USE_C99_FENV_TR1 1
whereas
/gnu/store/c17nwiafb01pig2r3mjm1jznfpas61np-gcc-toolchain-12.1.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h
contains in line 1759:
/* #undef _GLIBCXX_USE_C99_FENV_TR1 */
Did we change anything between 10.2 and 10.3, and then revert it with
11.3? Or is it a transient thing that depends on some random ordering of
include files? The latter looks more plausible, since the change from
10.2 and 10.3 really just changes the version and the hash.
What can we do?
Andreas
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Sun, 29 Jan 2023 23:20:02 GMT) (full text, mbox, link).
Hi,
Adding more petrol to ther fire:
I try to upgrade casacore to 3.5.0 which failed due to mentined
problem with C++:
---------------------------------------------------
[ 36%] Building CXX object
tables/Dysco/CMakeFiles/tDysco.dir/tests/runtests.cc.o
[5/1881]
cd /tmp/guix-build-casacore-3.5.0.drv-0/build/tables/Dysco &&
/gnu/store/069aq2v993kpc41yabp5b6vm4wb9jkhg-gcc-10.3.0/bin/c++
-DBOOST_ALL_NO_LIB -DBOOST_ATOMIC_DYN_LINK -DBOOST_FILESYSTEM_DYN_LINK
-DBOOST_SYSTEM_DYN_LINK -DCFITSIO_VERSION_MAJOR=4
-DCFITSIO_VERSION_MINOR=200
-DHAVE_DYSCO -DHAVE_FFTW3 -DHAVE_FFTW3_THREADS -DHAVE_HDF5
-DHAVE_O_DIRECT -DHAVE_READLINE -DUSE_THREADS -DWCSLIB_VERSION_MAJOR=7
-DWCSLIB_VERSION_MINOR=12
-I/tmp/guix-build-casacore-3.5.0.drv-0/source
-I/tmp/guix-build-casacore-3.5.0.drv-0/build
-I/gnu/store/c2rz0vskpib35i
7jwx8s3i92fh8m5izq-wcslib-7.12/include
-I/gnu/store/s3kcslq2kycphdpzdjc93dnlmxrk599h-cfitsio-4.2.0/include
-I/gnu/store/imz1fhpcg603a4ny7k9yla72d6y302aw-hdf5-1.10.7/include
-I/gnu/store/hc7gxhfrawmwhqp7wf2xqxpkn3zx9mba-fftw-3.3.8/include
-I/tmp/guix-build-casacore-3.5.0.drv
-0/build/tables -isystem
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include
-fcx-fortran-rules -Wextra -Wall -W -Wpointer-arith
-Woverloaded-virtual -Wwrite-strings -pedantic -Wno-long-long
-std=c++11 -pthread -O2 -g -DNDEBUG -O3 -Wall -DNDEBUG -march=native -
std=c++11 -MD -MT
tables/Dysco/CMakeFiles/tDysco.dir/tests/runtests.cc.o -MF
CMakeFiles/tDysco.dir/tests/runtests.cc.o.d -o
CMakeFiles/tDysco.dir/tests/runtests.cc.o -c
/tmp/guix-build-casacore-3.5.0.drv-0/source/tables/Dysco/tests/runtests.cc
In file included from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/detail/fenv.hpp:97,
from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/execution_monitor.hpp:64,
from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/impl/compiler_log_formatter.ipp:22,
from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/included/unit_test.hpp:18,
from
/tmp/guix-build-casacore-3.5.0.drv-0/source/tables/Dysco/tests/runtests.cc:4:
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:58:11:
error: ‘fenv_t’ has not been declared in ‘::’
58 | using ::fenv_t;
| ^~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:59:11:
error: ‘fexcept_t’ has not been declared in ‘::’
59 | using ::fexcept_t;
| ^~~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:62:11:
error: ‘feclearexcept’ has not been declared in ‘::’
62 | using ::feclearexcept;
| ^~~~~~~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:63:11:
error: ‘fegetexceptflag’ has not been declared in ‘::’
63 | using ::fegetexceptflag;
| ^~~~~~~~~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:64:11:
error: ‘feraiseexcept’ has not been declared in ‘::’
64 | using ::feraiseexcept;
| ^~~~~~~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:65:11:
error: ‘fesetexceptflag’ has not been declared in ‘::’
65 | using ::fesetexceptflag;
| ^~~~~~~~~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:66:11:
error: ‘fetestexcept’ has not been declared in ‘::’
66 | using ::fetestexcept;
| ^~~~~~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:68:11:
error: ‘fegetround’ has not been declared in ‘::’
68 | using ::fegetround;
| ^~~~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:69:11:
error: ‘fesetround’ has not been declared in ‘::’
69 | using ::fesetround;
| ^~~~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:71:11:
error: ‘fegetenv’ has not been declared in ‘::’
71 | using ::fegetenv;
| ^~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:72:11:
error: ‘feholdexcept’ has not been declared in ‘::’
72 | using ::feholdexcept;
| ^~~~~~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:73:11:
error: ‘fesetenv’ has not been declared in ‘::’
73 | using ::fesetenv;
| ^~~~~~~~
/gnu/store/9dfwr7gh59iwg2wary3w853rnjzzk3r7-gfortran-10.3.0/include/c++/fenv.h:74:11:
error: ‘feupdateenv’ has not been declared in ‘::’
74 | using ::feupdateenv;
| ^~~~~~~~~~~
In file included from
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/included/unit_test.hpp:23,
from
/tmp/guix-build-casacore-3.5.0.drv-0/source/tables/Dysco/tests/runtests.cc:4:
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/impl/execution_monitor.ipp:
In function ‘unsigned int boost::fpe::enable(unsigned int)’:
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/impl/execution_monitor.ipp:1473:5:
error: ‘feclearexcept’ was not declared in this scope
1473 | feclearexcept(BOOST_FPE_ALL);
| ^~~~~~~~~~~~~
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/impl/execution_monitor.ipp:1474:15:
error: ‘feenableexcept’ was not declared in this scope
1474 | int res = feenableexcept( mask );
| ^~~~~~~~~~~~~~
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/impl/execution_monitor.ipp:
In function ‘unsigned int boost::fpe::disable(unsigned int)’:
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/impl/execution_monitor.ipp:1509:5:
error: ‘feclearexcept’ was not declared in this scope
1509 | feclearexcept(BOOST_FPE_ALL);
| ^~~~~~~~~~~~~
/gnu/store/hm6dlgzkqz33fbiba07jjh8yzdikn7pp-boost-1.77.0/include/boost/test/impl/execution_monitor.ipp:1510:15:
error: ‘fedisableexcept’ was not declared in this scope
1510 | int res = fedisableexcept( mask );
| ^~~~~~~~~~~~~~~
make[2]: *** [tables/Dysco/CMakeFiles/tDysco.dir/build.make:79:
tables/Dysco/CMakeFiles/tDysco.dir/tests/runtests.cc.o] Error 1
make[2]: Leaving directory '/tmp/guix-build-casacore-3.5.0.drv-0/build'
make[1]: *** [CMakeFiles/Makefile2:6253:
tables/Dysco/CMakeFiles/tDysco.dir/all] Error 2
make[1]: Leaving directory '/tmp/guix-build-casacore-3.5.0.drv-0/build'
make: *** [Makefile:149: all] Error 2
error: in phase 'build': uncaught exception:
%exception #<&invoke-error program: "make" arguments: () exit-status:
2 term-signal: #f stop-signal: #f>
phase `build' failed after 804.3 seconds
command "make" failed with status 2
builder for `/gnu/store/9prrnvzixy0kcsnnyzav947l4ysznzfs-casacore-3.5.0.drv'
failed with exit code 1
build of /gnu/store/9prrnvzixy0kcsnnyzav947l4ysznzfs-casacore-3.5.0.drv failed
View build log at
'/var/log/guix/drvs/9p/rrnvzixy0kcsnnyzav947l4ysznzfs-casacore-3.5.0.drv.gz'.
guix build: error: build of
`/gnu/store/9prrnvzixy0kcsnnyzav947l4ysznzfs-casacore-3.5.0.drv'
failed
---------------------------------------------------
--
… наш разум - превосходная объяснительная машина которая способна
найти смысл почти в чем угодно, истолковать любой феномен, но
совершенно не в состоянии принять мысль о непредсказуемости.
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Sat, 25 Jan 2025 17:09:03 GMT) (full text, mbox, link).
This issue is preventing me to use guix to do c++ developement on
projects using boost test module. Is there a way around it so I can use
my machine for compiling these projects (I mean how does guix itself compile
boost otherwise)?
```
In file included from libs/test/src/execution_monitor.cpp:16:
./boost/test/impl/execution_monitor.ipp: In function ‘unsigned int boost::fpe::enable(unsigned int)’:
./boost/test/impl/execution_monitor.ipp:1473:5: error: ‘feclearexcept’ was not declared in this scope
1473 | feclearexcept(BOOST_FPE_ALL);
| ^~~~~~~~~~~~~
```
Thank you
Information forwarded
to bug-guix@gnu.org: bug#43579; Package guix.
(Mon, 27 Jan 2025 14:12:01 GMT) (full text, mbox, link).
For those who faces this issue and ends up here. The solution that
worked for me was to do this before running make:
```
$ export CPLUS_INCLUDE_PATH=/home/user/.guix-profile/include/
```
It somehow removes the toxic headers from the reach of the toolchain. I
guess it dependes what you have installed in your profile but probably,
it is more likely that the headrs aree purely coming from g++ toolchain
rather than weird stuff from Guix OS in the default inculde path.
Debbugs is free software and licensed under the terms of the
GNU Public License version 2. The current version can be
obtained from https://bugs.debian.org/debbugs-source/.