https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53429
Jonathan Wakely <redi at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> --- (In reply to Jeffrey Yasskin from comment #3) > Richard, I'm not asking that it be possible to link together code compiled > in C++98 and C++11 mode. I'm asking that gcc be able to build in C++11 mode > at all. Even if we build GCC in C++11 (or C++14) mode, some pieces of libstdc++ get built with -std=gnu++98 explicitly. That's why they're in the libstdc++-v3/src/c++98 directory. > If libstdc++.so exposed the c++98 version of complex::real(), then > all C++11 programs that used complex would be potentially broken. I don't think this is true now, because those functions are abi-tagged for C++11 and later, so C++11 programs would not use the symbols exported from the library (assuming such symbols existed, and if they did the check-abi testsuite target would fail for our primary targets, so we'd notice and it wouldn't just happen silently due to bad luck and different inlining decisions). So I think this was fixed for 4.8.0 by r193445, but please reopen if I'm missing something and a potential problem still exists. > Another way to fix this would, of course, be to either expose a > configuration option to build libstdc++.so in C++11 mode or to install two > different .so files in parallel, but doing that seems unnecessarily hostile > to users when it would be pretty easy to guarantee that the one .so works > for both versions of the language. We definitely don't want two libs.