std::to_string fails in GCC 4.8.4

[haiqu]

Just ran into this one while compiling QtCreator.

../3rdparty/cplusplus/Bind.cpp:503:35: error: 'to_string' is not a member of 'std'
                                 = std::to_string(static_cast<long long>(constantValueAsInt));
                                   ^
make[2]: *** [.obj/release-shared/Bind.o] Error 1

[bonefish]

Your bug reports tend to lack essential information. Please always provide the Haiku version (hrev, hybrid type) and in case of compilation issues the command line and full output.

[korli]

Seems related to ​https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393

_GLIBCXX_USE_C99 doesn't indeed seem to be enabled, which in return guards the declaration of std:to_string(). We should investigate libstdc++ configure step and finds out why the macro is just disabled. This might very well be that we don't provide a valid complex.h header.

​http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/complex.h.html

[pulkomandy]

You can force enabling of it by using -D_GLIBCXX_USE_C99 in you command line arguments, if the implementation of std::to_string is inlined in header files. I did something similar with _GLIBCXX_USE_C99_MATH in the WebKit port (​https://github.com/haiku/webkit/blob/rebased/Source/cmake/OptionsHaiku.cmake) so I could use std::isinf and a few other methods from #include <math>.

[haiqu]

Replying to bonefish:

Your bug reports tend to lack essential information. Please always provide the Haiku version (hrev, hybrid type) and in case of compilation issues the command line and full output.

I've often wondered why some of this information isn't a required field in the bug report form. In any case it wasn't required here, it was a generic error in any version of GCC 4.8.4 on Haiku.

For future reference you can always assume a GCC2 hybrid system (unless otherwise specified), and the latest hrev at the time of the report. For this one I was on hrev49364. I'm rarely more than 15 revisions behind the head, which is about 2-3 days' worth of changes.

[haiqu]

Replying to pulkomandy:

You can force enabling of it by using -D_GLIBCXX_USE_C99 in you command line arguments, if the implementation of std::to_string is inlined in header files. I did something similar with _GLIBCXX_USE_C99_MATH in the WebKit port (​https://github.com/haiku/webkit/blob/rebased/Source/cmake/OptionsHaiku.cmake) so I could use std::isinf and a few other methods from #include <math>.

Interesting, I'll give that a try. The compiler is already being passed -std=c++0x and I thought that would have been sufficient.

[haiqu]

Yep, that worked. Thanks to Pulkomandy!

[bonefish]

Replying to pulkomandy:

You can force enabling of it by using -D_GLIBCXX_USE_C99 in you command line arguments, if the implementation of std::to_string is inlined in header files. I did something similar with _GLIBCXX_USE_C99_MATH in the WebKit port (​https://github.com/haiku/webkit/blob/rebased/Source/cmake/OptionsHaiku.cmake) so I could use std::isinf and a few other methods from #include <math>.

Aren't the _GLIBCXX_* only meant to be set via the configuration (created when building gcc/the std C++ lib) or as a side effect of -std compiler flags? After googling a bit, korli's explanation seems very plausible.

Replying to haiqu:

Replying to bonefish:

Your bug reports tend to lack essential information. Please always provide the Haiku version (hrev, hybrid type) and in case of compilation issues the command line and full output.

I've often wondered why some of this information isn't a required field in the bug report form.

Since the bug tracker is also used for website and sysadmin issues, that wouldn't work.

In any case it wasn't required here, it was a generic error in any version of GCC 4.8.4 on Haiku.

Possibly, but unless you are an expert in the respective area, it is hard to assess such things. So please just provide the info. E.g. in this case, assuming the issue is indeed the complex.h header and we fix it and rebuild the gcc packages, the general gcc version (4.8.4, you failed to specify the exact one) will remain the same. So having at least the Haiku hrev would be helpful information.

For future reference you can always assume a GCC2 hybrid system (unless otherwise specified), and the latest hrev at the time of the report.

Besides that not everyone will read this or recall it, that isn't helpful when a ticket grows older. Having to guess basic infos like the Haiku revision after a few month is an unnecessary annoyance. Having all the relevant information available, may save the developers time and helps to get the issue fixed faster. If you haven't yet, please have a look at ReportingBugs.

[korli]

Replying to bonefish:

Aren't the _GLIBCXX_* only meant to be set via the configuration (created when building gcc/the std C++ lib) or as a side effect of -std compiler flags? After googling a bit, korli's explanation seems very plausible.

I have locally tried and the macro is then correctly enabled with a complex.h provided. I'll check a bit what's missing in glibc though, and push then this change.

[pulkomandy]

Replying to bonefish:

Replying to pulkomandy:

You can force enabling of it by using -D_GLIBCXX_USE_C99 in you command line arguments, if the implementation of std::to_string is inlined in header files. I did something similar with _GLIBCXX_USE_C99_MATH in the WebKit port (​https://github.com/haiku/webkit/blob/rebased/Source/cmake/OptionsHaiku.cmake) so I could use std::isinf and a few other methods from #include <math>.

Aren't the _GLIBCXX_* only meant to be set via the configuration (created when building gcc/the std C++ lib) or as a side effect of -std compiler flags? After googling a bit, korli's explanation seems very plausible.

Yes, that's how it should work. Setting them manually is only an ugly way to workaround the problem, in the cases where the macro is used to "protect" inline code in headers.

I had tried to enable the define properly in the compiler build but I didn't manage to do it the right way. I don't know how complete it needs the C99 implementation to be.

[korli]

x86_64 gcc package is updated with 4.8.5. Sadly x86 fails to build on stage 2 with an ICE (a workaround would be to build with O0 or maybe O1 this particular file).

[korli]

I assume it's fixed in hrev49408. Please check.