g++ does not provide std::fegetround

OpenSubmitted by Andreas Enge.
Details
6 participants
  • Andreas Enge
  • Brett Gilio
  • Ludovic Courtès
  • Maxim Cournoyer
  • Ricardo Wurmus
  • Miguel Ángel Arruga Vivas
Owner
unassigned
Severity
important
A
A
Andreas Enge wrote on 23 Sep 2020 18:21
(address . bug-guix@gnu.org)
20200923162121.GA28654@jurong
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> innamespace 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 beingdefined.

And when I look at the build log https://ci.guix.gnu.org/log/xpdy9vvqym9xv7praqkwsm3gdzn2kv1p-gcc-10.2.0for instance, there are the following lines:checking for ISO C99 support to TR1 in <fenv.h>... nochecking for ISO C99 support to TR1 in <stdint.h>... yeschecking for ISO C99 support to TR1 in <math.h>... yeschecking for ISO C99 support to TR1 in <inttypes.h>... yeswhereas in opensuse, there ischecking 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
A
A
Andreas Enge wrote on 23 Sep 2020 18:36
(address . 43579@debbugs.gnu.org)
20200923163632.GA7348@jurong
On Wed, Sep 23, 2020 at 06:21:21PM +0200, Andreas Enge wrote:
Toggle quote (2 lines)> 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 subdirectorylibstdc++-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 >&5configure:16490: $? = 0configure:16497: result: yes
This is when trying to compile gcc-10.2.0 with gcc-10.2.0; so somehowour bootstrapping process does something differently when creating thefinal user facing gcc.
Andreas
R
R
Ricardo Wurmus wrote on 23 Sep 2020 21:03
(name . Andreas Enge)(address . andreas@enge.fr)(address . 43579@debbugs.gnu.org)
875z84gvs5.fsf@elephly.net
Andreas Enge <andreas@enge.fr> writes:
Toggle quote (24 lines)> 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
A
A
Andreas Enge wrote on 23 Sep 2020 22:05
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 43579@debbugs.gnu.org)
20200923200543.GA9839@jurong
On Wed, Sep 23, 2020 at 09:03:54PM +0200, Ricardo Wurmus wrote:
Toggle quote (2 lines)> Is this perhaps related to https://issues.guix.gnu.org/42392?
It looks very similar indeed. But then the fix given there has not fixedmy problem, which occurs in a current gcc-toolchain.
Andreas
A
A
Andreas Enge wrote on 23 Sep 2020 22:20
(name . Ricardo Wurmus)(address . rekado@elephly.net)(address . 43579@debbugs.gnu.org)
20200923202011.GA17102@jurong
On Wed, Sep 23, 2020 at 10:05:43PM +0200, Andreas Enge wrote:
Toggle quote (3 lines)> 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 somehowmisconfiguring 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 notfor this one.
Andreas
R
R
Ricardo Wurmus wrote on 23 Sep 2020 23:28
(name . Andreas Enge)(address . andreas@enge.fr)(address . 43579@debbugs.gnu.org)
873638gp2z.fsf@elephly.net
Andreas Enge <andreas@enge.fr> writes:
Toggle quote (11 lines)> 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 witharm-none-eabi-nano-toolchain-7-2018-q2-update, which used to work sometime ago (in axoloti-patcher-next).
For that issue the hack also did not work.
-- Ricardo
M
M
Maxim Cournoyer wrote on 24 Sep 2020 06:48
control message for bug #43579
(address . control@debbugs.gnu.org)
87k0wjvkye.fsf@gmail.com
severity 43579 importantquit
L
L
Ludovic Courtès wrote on 1 Oct 2020 14:36
Re: bug#43579: g++ does not provide std::fegetround
(name . Andreas Enge)(address . andreas@enge.fr)(address . 43579@debbugs.gnu.org)
87wo0arulv.fsf@gnu.org
Hallo!
Andreas Enge <andreas@enge.fr> skribis:
Toggle quote (6 lines)> 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’.
B
B
Brett Gilio wrote on 2 Oct 2020 04:39
(name . Ludovic Courtès)(address . ludo@gnu.org)
87o8llxsew.fsf@debian
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (15 lines)> 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 theappropriate flag?
Brett Gilio
A
A
Andreas Enge wrote on 2 Oct 2020 20:06
(name . Brett Gilio)(address . brettg@gnu.org)
20201002180621.GA4862@jurong
Hello,
On Thu, Oct 01, 2020 at 09:39:35PM -0500, Brett Gilio wrote:
Toggle quote (8 lines)> >> 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.cppproducesround.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:
Toggle quote (3 lines)> 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.cppwith the same outcome.
The issue https://github.com/fplll/fplll/issues/444I referenced in my bug report provides more discussion; the outcome was thatit is a bug in Guix. I will try to summarise it in the following to make thisbug 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 intothe std:: namespace.
This should happen somewhere in a configure phase inside the gcc build, butI do not know how to obtain the config.log file easily (short of adding aphase "(const #f)" to the build recipe and doing a "guix build -K").
Andreas
#include <cfenv>int main () { return std::fegetround ();}
L
L
Ludovic Courtès wrote on 3 Oct 2020 12:02
(name . Andreas Enge)(address . andreas@enge.fr)
87362vhbkl.fsf@gnu.org
Hi,
(Cc’ing Maxim who’s looked into this before.)
Andreas Enge <andreas@enge.fr> skribis:
Toggle quote (4 lines)> 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 (thecurrent ‘gcc-final’) works:
Toggle snippet (26 lines)$ 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.cppt.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 describeGeneracio 162 Oct 01 2020 00:23:38 (nuna) guix 7607ace repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: 7607ace5091aea0157ba5c8a508129cc5fc4f931
It’s the same story as https://issues.guix.gnu.org/42392.
Toggle quote (5 lines)> 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:
Toggle snippet (11 lines)checking fenv.h usability... yeschecking fenv.h presence... yeschecking for fenv.h... yeschecking for complex.h... (cached) yeschecking for complex.h... (cached) yeschecking for ISO C99 support to TR1 in <complex.h>... yeschecking for ISO C99 support to TR1 in <ctype.h>... yeschecking for fenv.h... (cached) yeschecking for ISO C99 support to TR1 in <fenv.h>... no
Here’s the ‘prev-x86_64-unknown-linux-gnu/libstdc++-v3/config.log’excerpt:
Toggle snippet (175 lines)configure:16448: checking for fenv.hconfigure:16448: result: yesconfigure: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 >&5conftest.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; | ^~~~~~~~~ | exceptconftest.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: $? = 1configure: 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
The same program builds fine outside.
Turns out GCC provides <fenv.h>, too:
Toggle snippet (8 lines)$ 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
So this is again #include_next not picking the right <fenv.h> due tosearch path ordering issues and/or duplicate entries.
Thoughts anyone?
I think we need a proper fix but the feedback we got from GCC folks lasttime didn’t give me much insight as to what we should do.
Toggle quote (4 lines)> 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 checkwhat’s in /tmp/guix-build-gcc-10*). :-)
Thanks,Ludo’.
M
M
Miguel Ángel Arruga Vivas wrote on 13 Nov 2020 18:59
(name . Ludovic Courtès)(address . ludo@gnu.org)
87r1oxyw6e.fsf@gmail.com
Hi!
Ludovic Courtès <ludo@gnu.org> writes:
Toggle quote (11 lines)>[...]> 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 CPATHbecause 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 installedlibraries which could be raised to errors with -Werror. I personallydon't like that approach, as the included headers are being compiled inthat moment so I think the -Werror should apply too, but indeed Iunderstand the reasons behind the compatibility with FHS.
The problem comes to generalizing this approach: there should be inputsthat 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 willtake some time until I recompile the world to really test it. Also thisisn't the best approach as the manifests shouldn't include theseneither, but I still don't find where and how to mark these inputscleanly.
WDYT? Any idea is welcome. :-)
Happy hacking!Miguel
From ad2e859589ccbd5e9310a921355ef5e7f4926d80 Mon Sep 17 00:00:00 2001From: =?UTF-8?q?Miguel=20=C3=81ngel=20Arruga=20Vivas?= <rosen644835@gmail.com>Date: Fri, 13 Nov 2020 18:27:03 +0100Subject: [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.<body>: Select between input-directories, native-input-directories orinclude-directories, native-include-directories depending on theenvironment variable to set.--- guix/build/gnu-build-system.scm | 45 ++++++++++++++++++++++++--------- 1 file changed, 33 insertions(+), 12 deletions(-)
Toggle diff (80 lines)diff --git a/guix/build/gnu-build-system.scm b/guix/build/gnu-build-system.scmindex 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 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- native-input-directories- #:separator separator- #:type type- #:pattern pattern)))+ (if (include-var? env-var)+ native-include-directories+ native-input-directories)+ #:separator separator+ #:type type+ #:pattern pattern))) native-search-paths)) #t)-- 2.29.2
-----BEGIN PGP SIGNATURE-----
iQGzBAEBCgAdFiEEiIeExBRZrMuD5+hMY0xuiXn6vsIFAl+uyZsACgkQY0xuiXn6vsIT4QwAoOo38cqqc/DETdqpDr3eka+sZOFL5FaOLtEz+Gd9lOgFiizQJ2qQZttwIy8S0Ki0Atal/cOp3P9HHdWQB+BxP7ru3rQWjb7dS1ualUR1/t7zW/ygNYnYH6fSfLO3YLVlmfLcnjLqPk34yv9Y/ec/4qcLQC9gQnv4Bb2gBM2FG6nzXuNJcgJhBFQm/C7IEzIw8A7ykeEA/JE3UpO2dQkv00wu+yxoxBBnD7FPoe4z6ehvDtUnOJgN5qqnkM32swCrJU1P68qxd82m7gKeDKi+sgoEJDbABsqp4TepPvOHdT9JbXuvoXD7jOxjVQJ7TACUkbjEEYag9B7NPXYyhtEcPQK+8h9ahyDqO5ILRgaqmkX6oqZPWxKxipv6JohIfJHv/RjL9CbpKmMfAMWj0wdFRTwUgHIm4vzf7XqSgm8H/6F1jOctJz52thNpKLeUEzqecGKgXhCZAnTs/fMeYvq8HJU4vi45lalNz8JujLpbLYfRF6GhzPbnOsJFjuqQZsQD=q0jA-----END PGP SIGNATURE-----
?