On Wed, 6 Aug 2014, Jakub Jelinek wrote:
On Wed, Aug 06, 2014 at 12:31:57PM +0200, Richard Biener wrote:
Ok, so the problematical case is
struct X { std::string s; };
void foo (X&);
Yeah.
then. OTOH I remember that then mangling of X changes as well?
Only if you add abi_tag attribute to X.
Note that -Wabi-tag can tell you where it is needed.
struct __attribute__((abi_tag("marc"))) X {};
struct Y { X x; };
a.cc:2:8: warning: 'Y' does not have the "marc" abi tag that 'X' (used in
the type of 'Y::x') has [-Wabi-tag]
struct Y { X x; };
^
a.cc:2:14: note: 'Y::x' declared here
struct Y { X x; };
^
a.cc:1:41: note: 'X' declared here
struct __attribute__((abi_tag("marc"))) X {};
^
I hope the libstdc++ folks will add some macro which will
include the right abi_tag attribute for the std::list/std::string
cases, so you'd in the end just add
#ifndef _GLIBCXX_ABI_TAG_SOMETHING
#define _GLIBCXX_ABI_TAG_SOMETHING
#endif
...
struct X _GLIBCXX_ABI_TAG_SOMETHING { std::string s; };
void foo (X&);
or similar.
So we only need to patch every project out there...
A clean .so.7 break would be significantly worse nightmare. We've been
there many years ago, e.g. 3.2/3.3 vs. 3.4, there has been significantly
fewer C++ plugins etc. in packages and it still it was unsolvable.
With the abi_tag stuff, you have the option to make stuff interoperable
when mixing compiler, either with no effort at all, or some limited
effort. With .so.7, you have no option, nothing will be interoperable.
I disagree that it is worse, but you have more experience, I guess we
will see the results in a few years...
--
Marc Glisse
