configuring out old ABI

[Jonathan Wakely]

On 06/06/18 10:45 +0200, Rasmus Villemoes wrote:
>On 2018-06-06 10:30, Jonathan Wakely wrote:
>> On 06/06/18 10:17 +0200, Rasmus Villemoes wrote:
>>> I naively attempted
>>>
>>> Â --disable-libstdcxx-dual-abi --with-default-libstdcxx-abi=cxx11
>>>
>>> and was a little surprised to find out that the second option is
>>> ignored, and I got the cxx98 ABI (only). Of course, it's documented if
>>> one reads the fine print in libstdc++-v3/acinclude.m4
>>>
>>> dnl --disable-libstdcxx-dual-abi will use old ABI for all types.
>>>
>>> or the logic a little further down that only honours
>>> default-libstdcxx-abi when x$enable_libstdcxx_dual_abi = xyes.
>>>
>>> Is there any chance of having a configuration combination completely
>>> disabling the old ABI?
>>
>> Not currently, this is
>> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65762
>>
>> If/when https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83077 gets
>> implemented you could get it via
>> --enable-symvers=gnu-versioned-namespace (but that also changes the
>> ABI to be completely incompatible, instead of just dropping the
>> non-cxx11 parts).
>
>Thanks for the quick reply. In my case, I only use the static libgcc and
>libstdc++ (I'm targeting vxworks), and don't even know if I could build
>a .so, so it seems that the logic in acinclude.m4 would complain loudly.
>How would/does symvers affect libstdc++.a?

When configured with --enable-symvers=gnu-versioned-namespace
everything in the standard library is defined in a different
namespace, so is completely ABI incompatible (even in a static
library, which doesn't have versioned symbols).