Bug 1200611

*** This bug has been marked as a duplicate of bug 1190971 ***

From devel list:

That is a WxGTK bug.  __GXX_ABI_VERSION can change, but usually the result
is still ABI compatible, g++ emits just some aliases when mangling has
changed.

	Jakub

I have converted the abort on ABI mismatch to a warning.

wxGTK-2.8.12-16.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/wxGTK-2.8.12-16.fc22

*** Bug 1192921 has been marked as a duplicate of this bug. ***

Package wxGTK-2.8.12-16.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing wxGTK-2.8.12-16.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-3630/wxGTK-2.8.12-16.fc22
then log in and leave karma (feedback).

wxGTK-2.8.12-16.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.

This bug occurs too in the wxGTK3 package. Apply the same 2.8 patch to the 3.0 package fix the problem.

Will this fix be submitted upstream to wxWidgets?

This bug has just been pointed to me and I completely disagree that removing the check was the right thing to do. I admit I don't know the exact rules for determining/changing __GXX_ABI_VERSION, so I can only trust the comment:2 here, but it says "_usually_ is still ABI compatible" and surely "usually" is not good enough. By removing this check you make it possible to build applications using ABI-incompatible library build which can result in very difficult to find bugs.

The ideal solution would be to detect which versions of g++ are really ABI incompatible, but unfortunately I don't know how to do it (I tried but failed to find any documentation for this). But if this can't be done, forcing the use of the same compiler to build the library and the applications using it seems like a much lesser evil than removing the check completely.

Removing the ABI check is downright idiotic. Consider:

class mystring {
  private:
    std::string z;
};
class myotherstring : public std::string {};

*Even if* std::string itself is properly handled ABI-wise by g++/libstdc++, as in

 extern void foo(std::string);
 //102: _Z3fooSs or so
 //108: _Z3fooNSt7__cxx11Ss or so

such mangling gets lost in compositions and derivations despite sizeof(mystring) changing:

 extern void foo(mystring);
 //102: _Z3foo8mystring
 //108: _Z3foo8mystring

This is also the reason why one has to ensure that an entire real-world system is consistently compiled either with -D_GLIBCXX_USE_CXX11_ABI=[0|1], because composition is used in almost every other library there is.

Sure, the string ABI change was a big one, but there have been several other __GXX_ABI_VERSION changes that have slipped into Fedora stable releases without any fanfare or announcement.

Until the ABI check is improved to check for truly incompatible changes, changing it to a warning instead of a failure seems like a reasonable compromise.

To understand this more precisely: Why does that happen?

I'm currently building an application that links against wxwidgets-GTK3, and upon launching I'm greeted with the abort due to C++ API mismatch; as far as I can see, this would be instantly fixable by rebuilding the library with the same compiler/linker version FC22 currently ships.

Is that understanding correct?

Exactly. Isn't there supposed to be at least one mass rebuild every cycle anyway so that this [everything rebuilt with current gcc] is guaranteed?

Currently rebuilding from srpm; if this fixes things, what to do? Open another bug requesting rebuild of the binary package?

Confirmation: rpmbuild --rebuild generates packages that, when installed, don't exhibit the aborting behaviour.

Yes, there is usually a mass rebuild during Fedora development cycles, but there have been g++ upgrades _post release_ that have changed the __GXX_ABI_VERSION in other cases.

Marcus, yes, if you are seeing a problem in a fully updated stable release, please open a new bug.

Done: https://bugzilla.redhat.com/show_bug.cgi?id=1318171