Created attachment 5468 [details] c++11 test case After building a buildroot toolchain based on GCC 4.8.3, it does not seem possible to build any packages that require C++11 support. Attached is a simple test case that compiles fine on my host machine with GCC 4.8.2 with -std=c+11, but fails to compile using the cross toolchain with the same flag.
Created attachment 5474 [details] Toolchain .config
Confirmed: - with a host gcc-4.8.3, this compiles fine: $ g++ -std=c++11 -c -o 5468.o 5468.cxx - with a crosstool-NG armv6 toolchain, compiles OK: $ armv6-rpi-linux-gnueabihf-g++ -std=c++11 -c -o 5468.o 5468.cxx - but fails with the Buildroot-built toolchain using gcc-4.8.3: $ arm-buildroot-linux-uclibcgnueabihf-g++ -std=c++11 -c -o 5468.o 5468.cxx ess.cxx: In function ‘int main()’: ess.cxx:5:5: error: ‘to_string’ is not a member of ‘std’ std::to_string(0); ^ C++ expert, anyone? ;-)
Thanks for the report. I'll try to have a look.
Basically, you're affected by https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393. uClibc does not implement C99 complex number computations (functions such as ccosf) and therefore libstdc++ concludes that there is no fully functional C99 support, and therefore it doesn't enable std::to_string() and many other methods. When building with uClibc: configure:16721: checking for ISO C99 support in <complex.h> [...] /tmp/cc2ksPYJ.o: In function `main': /home/test/outputs/arm-uclibc/build/host-gcc-final-4.8.3/build/arm-buildroot-linux-uclibcgnueabihf/libstdc++-v3/conftest.cpp:49: undefined reference to `ccosf' /home/test/outputs/arm-uclibc/build/host-gcc-final-4.8.3/build/arm-buildroot-linux-uclibcgnueabihf/libstdc++-v3/conftest.cpp:50: undefined reference to `ccoshf' [...] configure:16861: result: no configure:17182: checking for fully enabled ISO C99 support configure:17184: result: no When building with glibc: configure:17182: checking for fully enabled ISO C99 support configure:17184: result: yes And the std::to_string method is wrapped into a C99 conditional: #if ((__cplusplus >= 201103L) && defined(_GLIBCXX_USE_C99) \ && !defined(_GLIBCXX_HAVE_BROKEN_VSWPRINTF)) #include <ext/string_conversions.h> namespace std _GLIBCXX_VISIBILITY(default) { _GLIBCXX_BEGIN_NAMESPACE_VERSION [...] inline string to_string(int __val) { return __gnu_cxx::__to_xstring<string>(&std::vsnprintf, 4 * sizeof(int), "%d", __val); } So, for an immediate solution, use glibc. I'll try to see if we can integrate the patch proposed in the bug report.
Created attachment 5498 [details] gcc patch Could you put this patch in package/gcc/4.8.3/ in the Buildroot sources, rebuild the toolchain, and try again? Here it seems to fix the problem. It would be good if you could also test the runtime execution of the program. Thanks!
Created attachment 5510 [details] Patch to fix the issue for gcc 4.8 This time, here is a Buildroot patch that fixes the issue. Could you test it? I'm currently build-testing it (and similar patches for gcc 4.7 and 4.9) with gcc4.7/uclibc, gcc4.8/uclibc, gcc4.9/uclibc and gcc4.8/glibc. Thanks!
Hey, yeah, that patch works for me, package builds and runs fine. Thanks all,,
Thomas, has this patch already been sent to the list? I guess we should fix this in 2014.08?
Not yet, because the same patch needs to be made for gcc 4.7, 4.8, 4.9 and the special ARC version. I've already done that, and started building toolchains with those various gcc versions. But it takes some time, and I was busy with the maintenance. Now that Peter has taken over the maintenance, I'll focus on bug fixes, and I know I have this bug, and the one related to musl patches to fix. Those are my top priorities issues to fix for 2014.08.
Ok, thanks for the feedback!
Patch series sent at http://lists.busybox.net/pipermail/buildroot/2014-August/104150.html.
Patch series has now been applied: http://git.buildroot.net/buildroot/commit/?id=48f182ece057b8dedf72a0c601310d72b3d91a86