Hello Ludovic! Thank you for the investigation, and sorry for not having been able to reply earlier!
Ludovic Courtès <[email protected]> writes: [...] >> >> __cplusplus >= 201103L and _GLIBCXX_USE_C99_MATH_TR1 and not >> _GLIBCXX_NO_C99_ROUNDING_FUNCS Thanks for pointing out this configuration time problem! [...] > Comparing ‘c++config.h’ from GCC 7 (which works) and GCC 8 (the first > one that exhibits this problem), we see: > > diff -ubBr --show-c-function > /gnu/store/93z2pmmpla1n47q3xivqyic4mwvy0r5q-gcc-toolchain-8.4.0/include/c\+\+/x86_64-unknown-linux-gnu/bits/c\+\+config.h > > /gnu/store/xa45bzcbib4zqa7gk70nb35dzzwyr376-gcc-toolchain-7.5.0/include/c\+\+/x86_64-unknown-linux-gnu/bits/c\+\+config.h > --- > /gnu/store/xa45bzcbib4zqa7gk70nb35dzzwyr376-gcc-toolchain-7.5.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h > 1970-01-01 01:00:01.000000000 +0100 > +++ > /gnu/store/93z2pmmpla1n47q3xivqyic4mwvy0r5q-gcc-toolchain-8.4.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h > 1970-01-01 01:00:01.000000000 +0100 > [...] Interesting! > /tmp/guix-build-gcc-10.1.0.drv-0/build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/config.log > reads this: > > configure:19924: checking for float trig functions Notes: This check is made by the GLIBCXX_CHECK_MATH_DECLS_AND_LINKAGES_1 m4 macro defined under in libstdc++-v3/linkage.m4. The macro definition hasn't changed since 2005, so it's not the cause of the problem. > configure:19948: /tmp/guix-build-gcc-10.1.0.drv-0/build/./gcc/xgcc > -shared-libgcc -B/tmp/guix-build-gcc-10.1.0.drv-0/build/./gcc -nostdinc++ > -L/tmp/guix-build-gcc-10.1.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/src > > -L/tmp/guix-build-gcc-10.1.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs > > -L/tmp/guix-build-gcc-10.1.0.drv-0/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs > > -B/gnu/store/jrzxs91zhpf6yr5fxisn3jjj7xai8zlk-gcc-10.1.0/x86_64-unknown-linux-gnu/bin/ > > -B/gnu/store/jrzxs91zhpf6yr5fxisn3jjj7xai8zlk-gcc-10.1.0/x86_64-unknown-linux-gnu/lib/ > -isystem > /gnu/store/jrzxs91zhpf6yr5fxisn3jjj7xai8zlk-gcc-10.1.0/x86_64-unknown-linux-gnu/include > -isystem > /gnu/store/jrzxs91zhpf6yr5fxisn3jjj7xai8zlk-gcc-10.1.0/x86_64-unknown-linux-gnu/sys-include > -fno-checking -c -fno-builtin -D_GNU_SOURCE conftest.cpp >&5 > In file included from > /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/math.h:36, > from conftest.cpp:122: > /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/cmath:41:10: > fatal error: bits/c++config.h: No such file or directory > 41 | #include <bits/c++config.h> > | ^~~~~~~~~~~~~~~~~~ > compilation terminated. > configure:19948: $? = 1 > configure: failed program was: Eh! I fail to see what changed between 7.5 and 8.1, that would have caused such a change in behavior. [...] > At this point, we have: > > export CPLUS_INCLUDE_PATH=\ > "/gnu/store/61pv34q6kad3cii1pngyairvxbxgdm1n-isl-0.22.1/include\ > :/gnu/store/35afkywncrr5xsb4cxcljf6rpjcb7f61-gmp-6.2.0/include\ > :/gnu/store/5jf395qa3v4amdi60850rz2a15zlsrza-mpfr-4.0.2/include\ > :/gnu/store/lgrnkwh7w5yawgqaglwj1pls5vwz1nz7-mpc-1.1.0/include\ > :/gnu/store/243algr6h60j46spn5dqhjc4mhkd0a0p-libelf-0.8.13/include\ > :/gnu/store/rykm237xkmq7rl1p0nwass01p090p88x-zlib-1.2.11/include\ > :/gnu/store/i8h2pcxqdq07ijm3ibkka8f4smn1w48v-bzip2-1.0.8/include\ > :/gnu/store/9860f1abqj8wjjnwl8a9v54pdcc3bhgf-xz-5.2.4/include\ > :/gnu/store/60g7r3l01fd7c58yjbm6krgcwj1jkpwg-file-5.38/include\ > :/gnu/store/swqdvwri9dbv6zssg6v0by7l05hd6wxp-gawk-5.0.1/include\ > :/gnu/store/hm40bxnv8jxmbc1lpb7zfimii4xm9m81-make-4.3/include\ > :/gnu/store/m1z7cdbqsqyp9xnjw5cvlb4a7gkcg3m4-binutils-2.34/include\ > :/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++\ > :/gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include\ > :/gnu/store/fa6wj5bxkj5ll1d7292a70knmyl7a0cr-glibc-2.31/include\ > :/gnu/store/gfapkk5c6hvl1d94m4sqnhn7f9l5gqyh-linux-libre-headers-5.4.20/include" > > > but <bits/c++config.h> is in a directory not listed here: > > $ find /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0 -name c++config.h > /gnu/store/rn75fm7adgx3pw5j8pg3bczfqq1y17lk-gcc-7.5.0/include/c++/x86_64-unknown-linux-gnu/bits/c++config.h > > > ‘gcc-final’ doesn’t have this problem because it depends on ‘libstdc++’ > (separate package) where: > > $ find /gnu/store/v507xkc5flnzqa49yp41w5y611p4lqbg-libstdc++-7.5.0 -name > c++config.h > /gnu/store/v507xkc5flnzqa49yp41w5y611p4lqbg-libstdc++-7.5.0/include/bits/c++config.h > > > So somehow the problems seems to be that ‘xgcc’ doesn’t search > ‘gcc-7.5.0/include/c++/x86_64-unknown-linux-gnu’. We could add it to > CPLUS_INCLUDE_PATH manually, but it seems to me we’re missing something. > > Thoughts? Great findings! But you got me curious as how the previous GCC version managed to eschew this problem :-). Sadly, a couple evening of eye-balling GCC logs and looking at include files haven't given me a clue. Oh well, thank you for fixing it! Maxim
