uclibc conforms to C99 standards and requires _GLIBCXX_USE_C99 to be define when making use of c++ standards. rather than doing a -D_GLIBCXX_USE_C99 everywhere, we've been patching gcc with 90_all_302-c99-snprintf.patch. with the c++11 standards, we need to expand this. for example, g++ fails to find stod in namespace std: #include <string> int main() { std::stod("42.0"); } [i686-uclibc] cyan ~ # g++ -std=c++11 -o yy yy.c yy.c: In function 'int main()': yy.c:2:14: error: 'stod' is not a member of 'std' int main() { std::stod("42.0"); } ^ of course adding -D_GLIBCXX_USE_C99 would fix this, but its better to expand our patch.
Created attachment 428072 [details, diff] 90_all_302-c99-c++11.patch This patch follows the suggestion of the openadk team, but I believe their patch is missing one instance of _GLIBCXX_USE_C99. http://cgit.openadk.org/cgi/cgit/openadk.git/tree/toolchain/gcc/patches/4.9.3/libstdcxx-uclibc-c99.patch Also note that libstdc++-v3 makes use of an lot of defines of the form _GLIBCXX_USE_C99_XXX but these are set by tests defined in acinclude.m4 in a function called GLIBCXX_CHECK_C99_TR1 included in the configure.ac. ie, we don't need to bother with them.
(In reply to Anthony Basile from comment #1) > Created attachment 428072 [details, diff] [details, diff] > 90_all_302-c99-c++11.patch > > This patch follows the suggestion of the openadk team, but I believe their > patch is missing one instance of _GLIBCXX_USE_C99. > > http://cgit.openadk.org/cgi/cgit/openadk.git/tree/toolchain/gcc/patches/4.9. > 3/libstdcxx-uclibc-c99.patch > > Also note that libstdc++-v3 makes use of an lot of defines of the form > _GLIBCXX_USE_C99_XXX but these are set by tests defined in acinclude.m4 in a > function called GLIBCXX_CHECK_C99_TR1 included in the configure.ac. ie, we > don't need to bother with them. sorry that patch only applies cleanly for 4.x. I'll prepare a clean patch for 5.x.
Created attachment 428080 [details, diff] 90_all_302-c99-c++11-gcc-4.8.patch We need to update this patch for 4.8 because of bug #544756
Created attachment 428082 [details, diff] 90_all_302-c99-c++11-gcc-4.9.patch This is identical to my first patch, I just changed the name so its clear that its for 4.9.
Created attachment 428084 [details, diff] 90_all_302-c99-c++11-gcc-5.patch This applies to 5.1.0, 5.2.0 and 5.3.0.
we should fix/update uClibc so that _GLIBCXX_USE_C99 gets defined. we want the headers to be C99 compliant. then this patch won't be needed.
(In reply to SpanKY from comment #6) > we should fix/update uClibc so that _GLIBCXX_USE_C99 gets defined. we want > the headers to be C99 compliant. then this patch won't be needed. Actually there's a fix in gcc. The idea is to break up the C99 features check and replace _GLIBCXX_USE_C99 with _GLIBCXX_USE_C99_{STDIO,WCHAR,MATH}, so that we can get the wide string functions, std::to_w?string (WCHAR) without requiring MATH. Globbing all the features together made it an all or nothing deal. As an addendum, we could build up uclibc so that it provides everything C99 needs. According to the bug report that means complex math which could be ported over from glibc and enabled/disabled by a config option to avoid unwanted bloat. Something for the future maybe. Bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58393 git commit: bdb62e6a5583c7e41c438d1c29789aee41f8d519 I'm testing it out now to see how cleanly it will backport.
Created attachment 434986 [details] 90_all_302_gcc-4.9-compat-c99.patch Okay this (and the following patch) are big, ~1700 lines. Most of this is due to `configure`. So I stripped it down. Here's what I did: 1. I dropped the changes to ChangeLog and acinclude.m4. We won't be autoreconf-ing so we don't need acinclude.m4 2. 4.9 doesn't have DragonFly BSD stuff, so the patches to dragonfly/c_locale.h and dragonfly/os_defines.h are useless. Similarly util/testsuite_fs.h isn't in 4.9.3. 3. There were a lot of whitespace diff's in configure of the form /* end confdefs.h. */ #include <math.h> - volatile double d1, d2; - volatile int i; + volatile double d1, d2; + volatile int i; which I collapsed by editing the whitespace in the plus lines to match the - lines. I then used some git magic to get clean patches. 4. I made no changes to the other diff's, but line numbers were cleaned up. 5. I tested on glibc and uclibc and everything appears to be working.
Created attachment 434988 [details] 90_all_302_gcc-5.3-compat-c99.patch
In my opinion, while these last two patches are backported from upstream, I think its safest to go with my original patches because the former simply add || defined(__UCLIBC__) which can't make any difference on glibc, while the latter add a more complex testing of a "sharded" _GLIBCXX_USE_C99 which could introduce an error.
i'm fine with extending the hack for <6 versions since upstream seems to have cleaned things up, and the backport is kind of a pita
(In reply to SpanKY from comment #11) > i'm fine with extending the hack for <6 versions since upstream seems to > have cleaned things up, and the backport is kind of a pita okay i'll add that to the patchset.
(In reply to Anthony Basile from comment #12) i'm handling it now w/the gcc-5.4 upgrade. the updated patch had a typo too which breaks compiling ;).
(In reply to SpanKY from comment #13) > (In reply to Anthony Basile from comment #12) > > i'm handling it now w/the gcc-5.4 upgrade. the updated patch had a typo too > which breaks compiling ;). thanks :)
This patch may no longer be needed for gcc-6.2.0: # cat yy.cpp #include <string> int main() { std::stod("42.0"); } # g++ -std=c++11 -o yy yy.cpp # ./yy # echo $? 0 # gcc --version gcc (Gentoo 6.2.0-r1 p1.1) 6.2.0 Copyright (C) 2016 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. # ldd /usr/mips-unknown-linux-uclibc/gcc-bin/6.2.0/gcc libiconv.so.2 => /lib/libiconv.so.2 (0x77c70000) libc.so.0 => /lib/libc.so.0 (0x77bb0000) ld-uClibc.so.0 => /lib/ld-uClibc.so.0 (0x77db0000) I have a working, gcc-6.2.x/binutils-2.27/uclibc-ng-1.0.19 with everything but pkgconfig rebuilt using gcc-6.2.x if anyone wants to test things. It's MIPS-III, Big Endian, though.
(In reply to Joshua Kinard from comment #15) > This patch may no longer be needed for gcc-6.2.0: > it isn't needed in gcc-6. upstream has a fix, see comment #7. its just that backporting that particular fix would be a pita, so my original patch was the easier stop gap for gcc-4.9.
Gentoo's gcc 6.2 don't have this patch included in the patchset.
> > it isn't needed in gcc-6. upstream has a fix, see comment #7. its just > that backporting that particular fix would be a pita, so my original patch > was the easier stop gap for gcc-4.9. closing since <=gcc-5 is masked
