[-- Attachment #1: Type: text/plain, Size: 3340 bytes --] Hello guix-devel, I've run into a quirk in the various gcc toolchains that seems somewhat unique to guix builds of them. I'd like to understand if this is intentional. Initially, I found that string to numeric conversion functions that are enabled by _GLIBCXX_USE_C99_STDLIB are not available on guix gcc toolchains for gcc 8, 9, and 10. This is a minimal test case to reproduce the problem: Code: #include <iostream> #include <string> uint64_t _parse_number(std::string::const_iterator& c, const std::string::const_iterator& end) { std::string::const_iterator s = c; while (c != end and isdigit(*c)) ++c; if (c > s) { return std::stoull(std::string(s,c)); } else { return 0; } } int main(int argc, char** argv) { std::string s(argv[1]); std::string::const_iterator b = s.begin(); std::string::const_iterator e = s.end(); std::cout << _parse_number(b, e) << std::endl; return 0; } Compiling with (g++ --version == 10.1.0), /gnu/store/3kvnslc16sy7kwi2c5r7r5k6bbv2p03f-gcc-toolchain-10.1.0/bin/g++ g++ test-stoull.cpp -o test-stoull Yields this error: test-stoull.cpp: In function ‘uint64_t _parse_number(std::__cxx11::basic_string<char>::const_iterator&, const const_iterator&)’: test-stoull.cpp:13:33: error: invalid initialization of reference of type ‘const wstring&’ {aka ‘const std::__cxx11::basic_string<wchar_t>&’} from expression of type ‘std::string’ {aka ‘std::__cxx11::basic_string<char>’} 13 | return std::stoull(std::string(s,c)); | ^~~~~~~~~~~ In file included from /home/erikg/.guix-profile/include/c++/string:55, from /home/erikg/.guix-profile/include/c++/bits/locale_classes.h:40, from /home/erikg/.guix-profile/include/c++/bits/ios_base.h:41, from /home/erikg/.guix-profile/include/c++/ios:42, from /home/erikg/.guix-profile/include/c++/ostream:38, from /home/erikg/.guix-profile/include/c++/iostream:39, from test-stoull.cpp:1: /home/erikg/.guix-profile/include/c++/bits/basic_string.h:6697:25: note: in passing argument 1 of ‘long long unsigned int std::__cxx11::stoull(const wstring&, std::size_t*, int)’ 6697 | stoull(const wstring& __str, size_t* __idx = 0, int __base = 10) | ~~~~~~~~~~~~~~~^~~~~ I understand that there might be concern about my particular .guix-profile, but it's possible to reproduce this in containers. I can provide more test cases if needed, but I just wanted to clarify in general what I'm seeing. This behavior appears to be similar to this issue: http://freebsd.1045724.x6.nabble.com/base-gcc-and-GLIBCXX-USE-C99-td5781697.html. It's also similar to this report, https://stackoverflow.com/questions/40779611/g-compile-error-invalid-initialization-of-reference-of-type-stdstod . It may be more correct to require wstring in these kinds of conversions. However, I'm concerned that if gcc is built differently in guix than it typically is in other distributions, we will need to patch many libraries when building them on guix. It's probably better to match typical expectations of developers about the behavior of gcc. Thanks in advance, Erik [-- Attachment #2: Type: text/html, Size: 4107 bytes --]
Hi, Erik Garrison <erik.garrison@gmail.com> skribis: > I've run into a quirk in the various gcc toolchains that seems somewhat > unique to guix builds of them. I'd like to understand if this is > intentional. > > Initially, I found that string to numeric conversion functions that are > enabled by _GLIBCXX_USE_C99_STDLIB are not available on guix gcc toolchains > for gcc 8, 9, and 10. > > This is a minimal test case to reproduce the problem: > > Code: > > #include <iostream> > #include <string> > > uint64_t _parse_number(std::string::const_iterator& c, const > std::string::const_iterator& end) { > std::string::const_iterator s = c; > while (c != end and isdigit(*c)) ++c; > if (c > s) { > return std::stoull(std::string(s,c)); > } else { > return 0; > } > } > > int main(int argc, char** argv) { > std::string s(argv[1]); > std::string::const_iterator b = s.begin(); > std::string::const_iterator e = s.end(); > std::cout << _parse_number(b, e) << std::endl; > return 0; > } > > Compiling with (g++ --version == 10.1.0), > /gnu/store/3kvnslc16sy7kwi2c5r7r5k6bbv2p03f-gcc-toolchain-10.1.0/bin/g++ > > g++ test-stoull.cpp -o test-stoull I can reproduce it: --8<---------------cut here---------------start------------->8--- $ guix describe Generacio 147 Jun 08 2020 00:30:31 (nuna) guix e782756 repository URL: https://git.savannah.gnu.org/git/guix.git branch: master commit: e78275608065ef073775fabb9f1a757da65851f2 $ guix environment --ad-hoc gcc-toolchain -C -- g++ num.cpp num.cpp: In function 'uint64_t _parse_number(std::__cxx11::basic_string<char>::const_iterator&, const const_iterator&)': num.cpp:9:33: error: invalid initialization of reference of type 'const wstring&' {aka 'const std::__cxx11::basic_string<wchar_t>&'} from expression of type 'std::string' {aka 'std::__cxx11::basic_string<char>'} 9 | return std::stoull(std::string(s,c)); | ^~~~~~~~~~~ --8<---------------cut here---------------end--------------->8--- This is indeed fixed with: guix environment --ad-hoc gcc-toolchain@9 -C -- g++ -D_GLIBCXX_USE_C99_STDLIB=1 num.cpp > This behavior appears to be similar to this issue: > http://freebsd.1045724.x6.nabble.com/base-gcc-and-GLIBCXX-USE-C99-td5781697.html. > It's also similar to this report, > https://stackoverflow.com/questions/40779611/g-compile-error-invalid-initialization-of-reference-of-type-stdstod > . > > It may be more correct to require wstring in these kinds of conversions. > However, I'm concerned that if gcc is built differently in guix than it > typically is in other distributions, we will need to patch many libraries > when building them on guix. It's probably better to match typical > expectations of developers about the behavior of gcc. I agree, it seems we have a misconfiguration issue leading to this in our c++config.h: --8<---------------cut here---------------start------------->8--- /* Define if C99 functions or macros in <stdlib.h> should be imported in <cstdlib> in namespace std for C++11. */ /* #undef _GLIBCXX11_USE_C99_STDLIB */ --8<---------------cut here---------------end--------------->8--- The check appears to be this: --8<---------------cut here---------------start------------->8--- # Check for the existence in <stdlib.h> of lldiv_t, et. al. AC_MSG_CHECKING([for ISO C99 support in <stdlib.h> for C++11]) AC_CACHE_VAL(glibcxx_cv_c99_stdlib_cxx11, [ GCC_TRY_COMPILE_OR_LINK( [#include <stdlib.h> volatile float f; volatile long double ld; volatile unsigned long long ll; lldiv_t mydivt;], [char* tmp; f = strtof("gnu", &tmp); ld = strtold("gnu", &tmp); ll = strtoll("gnu", &tmp, 10); ll = strtoull("gnu", &tmp, 10); ll = llabs(10); mydivt = lldiv(10,1); ll = mydivt.quot; ll = mydivt.rem; ll = atoll("10"); _Exit(0); ], [glibcxx_cv_c99_stdlib_cxx11=yes], [glibcxx_cv_c99_stdlib_cxx11=no]) ]) AC_MSG_RESULT($glibcxx_cv_c99_stdlib_cxx11) if test x"$glibcxx_cv_c99_stdlib_cxx11" = x"yes"; then AC_DEFINE(_GLIBCXX11_USE_C99_STDLIB, 1, [Define if C99 functions or macros in <stdlib.h> should be imported in <cstdlib> in namespace std for C++11.]) fi --8<---------------cut here---------------end--------------->8--- We should check what’s going on! Thanks, Ludo’.
[-- Attachment #1: Type: text/plain, Size: 5163 bytes --] Hi Ludo, Thanks for reproducing this. Did you take a look at a resolution beyond your analysis in this message? It would seem that the attempted compilation isn't working during the configure phase. Erik On Wed, Jun 10, 2020, 17:18 Ludovic Courtès <ludo@gnu.org> wrote: > Hi, > > Erik Garrison <erik.garrison@gmail.com> skribis: > > > I've run into a quirk in the various gcc toolchains that seems somewhat > > unique to guix builds of them. I'd like to understand if this is > > intentional. > > > > Initially, I found that string to numeric conversion functions that are > > enabled by _GLIBCXX_USE_C99_STDLIB are not available on guix gcc > toolchains > > for gcc 8, 9, and 10. > > > > This is a minimal test case to reproduce the problem: > > > > Code: > > > > #include <iostream> > > #include <string> > > > > uint64_t _parse_number(std::string::const_iterator& c, const > > std::string::const_iterator& end) { > > std::string::const_iterator s = c; > > while (c != end and isdigit(*c)) ++c; > > if (c > s) { > > return std::stoull(std::string(s,c)); > > } else { > > return 0; > > } > > } > > > > int main(int argc, char** argv) { > > std::string s(argv[1]); > > std::string::const_iterator b = s.begin(); > > std::string::const_iterator e = s.end(); > > std::cout << _parse_number(b, e) << std::endl; > > return 0; > > } > > > > Compiling with (g++ --version == 10.1.0), > > /gnu/store/3kvnslc16sy7kwi2c5r7r5k6bbv2p03f-gcc-toolchain-10.1.0/bin/g++ > > > > g++ test-stoull.cpp -o test-stoull > > I can reproduce it: > > --8<---------------cut here---------------start------------->8--- > $ guix describe > Generacio 147 Jun 08 2020 00:30:31 (nuna) > guix e782756 > repository URL: https://git.savannah.gnu.org/git/guix.git > branch: master > commit: e78275608065ef073775fabb9f1a757da65851f2 > $ guix environment --ad-hoc gcc-toolchain -C -- g++ num.cpp > num.cpp: In function 'uint64_t > _parse_number(std::__cxx11::basic_string<char>::const_iterator&, const > const_iterator&)': > num.cpp:9:33: error: invalid initialization of reference of type 'const > wstring&' {aka 'const std::__cxx11::basic_string<wchar_t>&'} from > expression of type 'std::string' {aka 'std::__cxx11::basic_string<char>'} > 9 | return std::stoull(std::string(s,c)); > | ^~~~~~~~~~~ > --8<---------------cut here---------------end--------------->8--- > > This is indeed fixed with: > > guix environment --ad-hoc gcc-toolchain@9 -C -- g++ > -D_GLIBCXX_USE_C99_STDLIB=1 num.cpp > > > This behavior appears to be similar to this issue: > > > http://freebsd.1045724.x6.nabble.com/base-gcc-and-GLIBCXX-USE-C99-td5781697.html > . > > It's also similar to this report, > > > https://stackoverflow.com/questions/40779611/g-compile-error-invalid-initialization-of-reference-of-type-stdstod > > . > > > > It may be more correct to require wstring in these kinds of conversions. > > However, I'm concerned that if gcc is built differently in guix than it > > typically is in other distributions, we will need to patch many libraries > > when building them on guix. It's probably better to match typical > > expectations of developers about the behavior of gcc. > > I agree, it seems we have a misconfiguration issue leading to this in > our c++config.h: > > --8<---------------cut here---------------start------------->8--- > /* Define if C99 functions or macros in <stdlib.h> should be imported in > <cstdlib> in namespace std for C++11. */ > /* #undef _GLIBCXX11_USE_C99_STDLIB */ > --8<---------------cut here---------------end--------------->8--- > > The check appears to be this: > > --8<---------------cut here---------------start------------->8--- > # Check for the existence in <stdlib.h> of lldiv_t, et. al. > AC_MSG_CHECKING([for ISO C99 support in <stdlib.h> for C++11]) > AC_CACHE_VAL(glibcxx_cv_c99_stdlib_cxx11, [ > GCC_TRY_COMPILE_OR_LINK( > [#include <stdlib.h> > volatile float f; > volatile long double ld; > volatile unsigned long long ll; > lldiv_t mydivt;], > [char* tmp; > f = strtof("gnu", &tmp); > ld = strtold("gnu", &tmp); > ll = strtoll("gnu", &tmp, 10); > ll = strtoull("gnu", &tmp, 10); > ll = llabs(10); > mydivt = lldiv(10,1); > ll = mydivt.quot; > ll = mydivt.rem; > ll = atoll("10"); > _Exit(0); > ], [glibcxx_cv_c99_stdlib_cxx11=yes], > [glibcxx_cv_c99_stdlib_cxx11=no]) > ]) > AC_MSG_RESULT($glibcxx_cv_c99_stdlib_cxx11) > if test x"$glibcxx_cv_c99_stdlib_cxx11" = x"yes"; then > AC_DEFINE(_GLIBCXX11_USE_C99_STDLIB, 1, > [Define if C99 functions or macros in <stdlib.h> should be imported > in <cstdlib> in namespace std for C++11.]) > fi > --8<---------------cut here---------------end--------------->8--- > > We should check what’s going on! > > Thanks, > Ludo’. > [-- Attachment #2: Type: text/html, Size: 6870 bytes --]
Hi Erik,
Erik Garrison <erik.garrison@gmail.com> skribis:
> Thanks for reproducing this. Did you take a look at a resolution beyond
> your analysis in this message? It would seem that the attempted compilation
> isn't working during the configure phase.
Unfortunately I haven’t dug further. Help welcome!
Thanks,
Ludo’.
Hi,
On Monday, July 13, 2020 4:21 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Unfortunately I haven’t dug further. Help welcome!
>
> Thanks,
> Ludo’.
I'd like to help but I don't know where to start (yet).
I've found the same issue in older gcc-toolchains. 9.3.0 and 8.4.0 also fail.
Many functions are affected, strtol, stoi... all have the same issue.
Looks _GLIBCXX_USE_C99_STDLIB is not set as you said so it fails to make any of these conversions from std::string.
Do you know any gcc version where this works?
Thanks
On Mon, Jul 13, 2020 at 04:21:33PM +0200, Ludovic Courtès wrote:
> Hi Erik,
>
> Erik Garrison <erik.garrison@gmail.com> skribis:
>
> > Thanks for reproducing this. Did you take a look at a resolution beyond
> > your analysis in this message? It would seem that the attempted compilation
> > isn't working during the configure phase.
>
> Unfortunately I haven’t dug further. Help welcome!
_GLIBCXX_USE_C99_STDLIB is a build setting. This is not failing for
many Guix packages because we are building by default with an older
gcc. I have been building with newer gcc's for ages, without issue,
and this appears to be recently introduced.