ABI compatibility between different -std options

[Sam Varshavchik]

Does the usage of -std introduce any ABI incompatibility between modules  
that are, otherwise, built with the same gcc/libstdc++.

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", -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"]",\

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?

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/libstdc++/attachments/20130810/445be5e9/attachment.sig>