Re: ABI compatibility between different -std options

[Jonathan Wakely <jwakely dot gcc at gmail dot com>]

On 10 August 2013 19:26, Sam Varshavchik wrote:
> Does the usage of -std introduce any ABI incompatibility between modules
> that are, otherwise, built with the same gcc/libstdc++.

For the core language, no, but for libstdc++, yes, sometimes. See
http://gcc.gnu.org/wiki/Cxx11AbiCompatibility

> I'm trying to write a Perl XS module for a library that's built with
> -std=c++11.
>
> Trying to build the Perl module directly as C++ generally works, but only up
> until the point that I introduce -std=c++11 into the mix. Although Perl's
> header files get wrapped inside an extern "C",

If you're implying that extern "C" should cause the headers to be
compiled as C, that's entirely wrong. It does nothing of the sort. It
simply says the functions use C calling conventions and no name
mangling. It doesn't mean they declarations don't need to be valid
C++.

> -std=c++11 results in a bunch
> of warnings, like:
>
> /usr/lib64/perl5/CORE/pad.h:143:19: warning: invalid suffix on literal;
> C++11 requires a space between literal and identifier [-Wliteral-suffix]
>  Perl_croak(aTHX_ "panic: illegal pad in %s: 0x%"UVxf"[0x%"UVxf"]",\

The Perl headers need to be updated to be C++11-compatible, see the
section on user-defined literals and whitespace at
http://gcc.gnu.org/gcc-4.7/porting_to.html

The warning has no effect on ABI. It's telling you invalid C++11 code
was interpreted as though the missing whitespace was present. That
just allows the code to compile, it doesn't make any difference to any
ABI.

> Seems harmless, but there's a bunch of these, which makes me a bit edgy. I'm
> thinking about building an XS shim without -std=c++11, and the rest of my
> glue code with -std=c++11, and link them together. Would there be any ABI
> issues with this approach. Basically:
>
> module1.C compiled to module1.o without -std=c++11
>
> module2.C compiled to module2.o using -std=c++11
>
> They'll share a header file, that declares classes without any C++11-isms.
>
> Linked together.
>
> Any pitfalls with that?

No, as long as the classes don't use any libstdc++ types that are
incompatible between C++03 and C++11 modes.