Some (very small) questions / cleanups

1) Do you plan on supporting CXX11 ABI on C++03? There is some #if
__cplusplus < 201103L inside the new basic_string.

2) Is there a need for the #if 0 _M_mutate?


I tried bootstrapping on Mac OS X 10.10, and got lots of linking
issues, the relevant part is::

/bin/sh ../libtool --tag CXX   --mode=link
/Users/caj/progs/gcc/gcc-bin/./gcc/xgcc -shared-libgcc
-B/Users/caj/progs/gcc/gcc-bin/./gcc -nostdinc++
-L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src
-L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
-L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs
-B/gccbin/x86_64-apple-darwin14.0.0/bin/
-B/gccbin/x86_64-apple-darwin14.0.0/lib/ -isystem
/gccbin/x86_64-apple-darwin14.0.0/include -isystem
/gccbin/x86_64-apple-darwin14.0.0/sys-include     -Wl,-single_module
-fno-common -DPIC -fno-implicit-templates  -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi  -fdiagnostics-show-location=once
-fvisibility-inlines-hidden -ffunction-sections -fdata-sections
-frandom-seed=libstdc++.la  -o libstdc++.la -version-info 6:21:0
-Wl,-exported_symbols_list,libstdc++-symbols.explist -lm -rpath
/gccbin/lib compatibility.lo compatibility-debug_list.lo
compatibility-debug_list-2.lo  compatibility-c++0x.lo
compatibility-atomic-c++0x.lo compatibility-thread-c++0x.lo
compatibility-chrono.lo compatibility-condvar.lo
../libsupc++/libsupc++convenience.la
../src/c++98/libc++98convenience.la
../src/c++11/libc++11convenience.la
libtool: link:  /Users/caj/progs/gcc/gcc-bin/./gcc/xgcc -shared-libgcc
-B/Users/caj/progs/gcc/gcc-bin/./gcc -nostdinc++
-L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src
-L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
-L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs
-B/gccbin/x86_64-apple-darwin14.0.0/bin/
-B/gccbin/x86_64-apple-darwin14.0.0/lib/ -isystem
/gccbin/x86_64-apple-darwin14.0.0/include -isystem
/gccbin/x86_64-apple-darwin14.0.0/sys-include    -dynamiclib
-Wl,-undefined -Wl,dynamic_lookup -o .libs/libstdc++.6.dylib
.libs/compatibility.o .libs/compatibility-debug_list.o
.libs/compatibility-debug_list-2.o .libs/compatibility-c++0x.o
.libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o
.libs/compatibility-chrono.o .libs/compatibility-condvar.o
-Wl,-force_load,../libsupc++/.libs/libsupc++convenience.a
-Wl,-force_load,../src/c++98/.libs/libc++98convenience.a
-Wl,-force_load,../src/c++11/.libs/libc++11convenience.a
-L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/libsupc++/.libs
-L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src
-L/Users/caj/progs/gcc/gcc-bin/x86_64-apple-darwin14.0.0/libstdc++-v3/src/.libs
-lm  -Wl,-single_module -Wl,-exported_symbols_list
-Wl,libstdc++-symbols.explist   -install_name
/gccbin/lib/libstdc++.6.dylib -compatibility_version 7
-current_version 7.21 -Wl,-single_module
ld: warning: cannot export hidden symbol
__cxxabiv1::__pbase_type_info::__pointer_catch(__cxxabiv1::__pbase_type_info
const*, void**, unsigned int) const from
../libsupc++/.libs/libsupc++convenience.a(pbase_type_info.o)
ld: warning: cannot export hidden symbol
std::basic_stringbuf[abi:cxx11]<char, std::char_traits<char>,
std::allocator<char> >::~cxx11() from
../src/c++98/.libs/libc++98convenience.a(complex_io.o)
ld: warning: cannot export hidden symbol
std::basic_stringbuf[abi:cxx11]<wchar_t, std::char_traits<wchar_t>,
std::allocator<wchar_t> >::~cxx11() from
../src/c++98/.libs/libc++98convenience.a(complex_io.o)
ld: warning: cannot export hidden symbol construction vtable for
std::basic_istream<char, std::char_traits<char> >-in-std::istrstream
from ../src/c++98/.libs/libc++98convenience.a(strstream.o)
ld: warning: cannot export hidden symbol construction vtable for
std::basic_ostream<char, std::char_traits<char> >-in-std::ostrstream
from ../src/c++98/.libs/libc++98convenience.a(strstream.o)
....
duplicate symbol std::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::showmanyc() in:
    ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o)
    ../src/c++11/.libs/libc++11convenience.a(cow-string-inst.o)
duplicate symbol std::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::underflow() in:
    ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o)
    ../src/c++11/.libs/libc++11convenience.a(cow-string-inst.o)
duplicate symbol std::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::pbackfail(int) in:
    ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o)
    ../src/c++11/.libs/libc++11convenience.a(cow-string-inst.o)
duplicate symbol std::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::seekoff(long long, std::_Ios_Seekdir,
std::_Ios_Openmode) in:
    ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o)
    ../src/c++11/.libs/libc++11convenience.a(cow-string-inst.o)
duplicate symbol std::basic_stringbuf<char, std::char_traits<char>,
std::allocator<char> >::seekpos(std::fpos<__mbstate_t>,
std::_Ios_Openmode) in:
    ../src/c++11/.libs/libc++11convenience.a(cow-sstream-inst.o)
    ../src/c++11/.libs/libc++11convenience.a(cow-string-inst.o)

On 14 November 2014 15:43, Jonathan Wakely <jwak...@redhat.com> wrote:
> This is the long-awaited ABI break for std::string, replacing our
> venerable Copy-On-Write implementation with a C++11-conforming
> Small-String-Optimization implementation (based on Paolo's vstring).
>
> The gist of it is adding a second complete std::string implementation
> that is tagged with abi_tag("cxx11") so it mangles differently (as
> already done for std::list and std::ios_base::failure).
>
> Because strings are used pervasively through the library loads of
> functions need to be compiled twice, using the old and new string, so
> that both versions are exported from the library. That involved loads
> of shuffling things around within the libstdc++-v3/src directory so
> the right definitions could be included twice by different files and
> compiled with the right -std option and the right value of the
> _GLIBCXX_USE_CXX11_ABI macro.
>
> The stringstream classes are so tightly coupled to std::string that I
> just added the tag to them as well.
>
> The exception to the "compile it twice" rule are (fittingly) the
> exception classes. Because exceptions cross function/API/library
> boundaries without being "visible" to the linker simply adding the
> abi_tag to the exception types would have caused runtime failures
> where one module throws an old std::runtime_error and the code trying
> to catch it only handles the new std::runtime_error[abi:cxx11] type.
>
> So in order to avoid changing the exception types I have devised a
> horrible hack where the exception classes always use the old COW
> std::string type, even when the rest of the program doesn't. This is
> done by ensuring all constructing/copying/destroying of the exception
> classes is done in a context where the old std::string ABI is in
> effect. In practice that means the relevant functions are non-inline
> and exported from the library.
>
> This patch doesn't include all the testsuite fixes, which I'll send
> separately. We have lots of tests for features that are true for COW
> strings but not SSO strings so they need adjusting.
>
> There are also some failures in 22_locale and 28_regex which I'm
> investigating (with all the duplicated symbols and shuffling of code
> in the locale instantiations I'm amazed there arren't more failures!)
>
> This change *doesn't* resolve PRs 54354 and 60396, they require
> abi-tagging the time_get facet and ensuring that std::locale objects
> contain both the old and new time_get facets. That will require even
> more black magic than is usually involved with std::locale changes,
> but I still hope to have it done before stage 1 ends, if I can fix the
> testsuite problems I'm seeing now.
>
> Tested on x86_64-linux and powerpc64-linux, also with
> --disable-libstdcxx11-abi to verify all the incompatible changes can
> be disabled if needed.
>
> I plan to commit this today or tomorrow, but I'll check with Jakub and
> Richi if they'd prefer I wait until Sunday morning, to avoid causing
> massive churn for everyone else trying to get things in before stage 1
> ends.

Reply via email to