bug#43579: g++ does not provide std::fegetround

[Ricardo Wurmus]

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

bug#43579: g++ does not provide std::fegetround

[Miguel Ángel Arruga Vivas]

Hi!

Ludovic Courtès  writes:
>[...]
> It’s the same story as .
>[...]
> So this is again #include_next not picking the right  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
From ad2e859589ccbd5e9310a921355ef5e7f4926d80 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?=
 
Date: Fri, 13 Nov 2020 18:27:03 +0100
Subject: [PATCH] build-system/gnu: Remove libc, libstdc++ and gcc from include
 paths.

* guix/build/gnu-build-system.scm (set-paths)[include-input?]
[include-var?]: New predicates.
[inputs->directories, native-inputs->directories]: Extract code from ...
[input-directories, native-input-directories]: ... here.
[include-directories, native-include-directories]: New variables.
: Select between input-directories, native-input-directories or
include-directories, native-include-directories depending on the
environment variable to set.
---
 guix/build/gnu-build-system.scm | 45 -
 1 file changed, 33 insertions(+), 12 deletions(-)

diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scm
index 2e7dff2034..2f8da33066 100644
--- a/guix/build/gnu-build-system.scm
+++ b/guix/build/gnu-build-system.scm
@@ -72,18 +72,35 @@ See https://reproducible-builds.org/specs/source-date-epoch/.;
 (define* (set-paths #:key target inputs native-inputs
 (search-paths '()) (native-search-paths '())
 #:allow-other-keys)
-  (define input-directories
-(match inputs
+  (define (include-input? input)
+(let ((compiler-internals '("libc" "libc:static" "libstdc++" "gcc")))
+  (match input
+((name . _)
+ (not (member name compiler-internals))
+
+  (define (inputs->directories obj)
+(match obj
   (((_ . dir) ...)
dir)))
 
-  (define native-input-directories
-(match native-inputs
+  (define (native-inputs->directories obj)
+(match obj
   (((_ . dir) ...)
dir)
   (#f ; not cross compiling
'(
 
+  (define input-directories (inputs->directories inputs))
+  (define native-input-directories (native-inputs->directories native-inputs))
+
+  (define (include-var? var)
+(string-suffix? var "_INCLUDE_PATH"))
+  (define include-directories
+(inputs->directories (filter include-input? inputs)))
+  (define native-include-directories
+(native-inputs->directories (filter include-input? native-inputs)))
+
+
   ;; Tell 'ld-wrapper' to disallow non-store libraries.
   (setenv "GUIX_LD_WRAPPER_ALLOW_IMPURITIES" "no")
 
@@ -98,10 +115,12 @@ See https://reproducible-builds.org/specs/source-date-epoch/.;
   (for-each (match-lambda
  ((env-var (files ...) separator type pattern)
   (set-path-environment-variable env-var files
- input-directories
- #:separator separator
- #:type type
- #:pattern pattern)))
+ (if (include-var? env-var)
+ include-directories
+ input-directories)
+ #:separator separator
+ #:type type
+ #:pattern pattern)))
 search-paths)
 
   (when native-search-paths
@@ -109,10 +128,12 @@ See 

bug#43579: g++ does not provide std::fegetround

[Ludovic Courtès]

Hi,

(Cc’ing Maxim who’s looked into this before.)

Andreas Enge  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 
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 .

> 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 ... yes
checking for ISO C99 support to TR1 in ... yes
checking for fenv.h... (cached) yes
checking for ISO C99 support to TR1 in ... 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 
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 

bug#43579: g++ does not provide std::fegetround

[Andreas Enge]

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 
> >> 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 
#endif

include/c++/fenv.h has this in line 34:
#include 

include/c++/x86_64-unknown-linux-gnu/bits/c++config.h has this around line 28:
/* Define if C99 functions in  should be imported in  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

#include 
int main () {
   return std::fegetround ();
}

bug#43579: g++ does not provide std::fegetround

[Brett Gilio]

Ludovic Courtès  writes:

> Hallo!
>
> Andreas Enge  skribis:
>
>> The following test file round.cpp does not compile with our g++-10.2.0:
>> #include 
>> 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

bug#43579: g++ does not provide std::fegetround

[Ludovic Courtès]

Hallo!

Andreas Enge  skribis:

> The following test file round.cpp does not compile with our g++-10.2.0:
> #include 
> int main () {
>return std::fegetround ();
> }

Could you provide detailed steps to reproduce it?

Thanks,
Ludo’.

bug#43579: g++ does not provide std::fegetround

[Ricardo Wurmus]

Andreas Enge  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

bug#43579: g++ does not provide std::fegetround

[Andreas Enge]

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

bug#43579: g++ does not provide std::fegetround

[Andreas Enge]

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

bug#43579: g++ does not provide std::fegetround

[Ricardo Wurmus]

Andreas Enge  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 
> 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

bug#43579: g++ does not provide std::fegetround

[Andreas Enge]

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

bug#43579: g++ does not provide std::fegetround

[Andreas Enge]

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 
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 
#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  should be imported in  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 ... no
checking for ISO C99 support to TR1 in ... yes
checking for ISO C99 support to TR1 in ... yes
checking for ISO C99 support to TR1 in ... yes
whereas in opensuse, there is
checking for ISO C99 support to TR1 in ... yes

Now it would be interesting to have a look at config.log for gcc...

Andreas