Bug 1200611

Summary: RFE: Remove ABI comparison check
Product: [Fedora] Fedora Reporter: Orion Poplawski <orion>
Component: wxGTKAssignee: Dan Horák <dan>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: urgent Docs Contact:
Priority: unspecified    
Version: 22CC: dan, jengelh, jfrieben, juliocampagnolo, mmueller, mtasaka, ppisar, swt, vadim, zanetu, zeratul976
Target Milestone: ---Keywords: Reopened
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: wxGTK-2.8.12-16.fc22 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-03-26 21:33:01 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Orion Poplawski 2015-03-10 23:48:11 UTC
Description of problem:

wxGTK apps fail with:

107: Fatal Error: Mismatch between the program and library build versions detected.
107: The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.4,compatible with 2.6),
107: and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1008,wx containers,compatible with 2.4,compatible with 2.6).

Jakub is of the opinion that this check is broken and should be removed.

Version-Release number of selected component (if applicable):

Comment 1 Petr Pisar 2015-03-11 11:40:15 UTC

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

Comment 2 Orion Poplawski 2015-03-11 15:22:46 UTC
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


Comment 3 Dan Horák 2015-03-12 16:51:30 UTC
I have converted the abort on ABI mismatch to a warning.

Comment 4 Fedora Update System 2015-03-12 19:47:03 UTC
wxGTK-2.8.12-16.fc22 has been submitted as an update for Fedora 22.

Comment 5 Dan Horák 2015-03-13 16:08:27 UTC
*** Bug 1192921 has been marked as a duplicate of this bug. ***

Comment 6 Fedora Update System 2015-03-13 16:59:53 UTC
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:
then log in and leave karma (feedback).

Comment 7 Fedora Update System 2015-03-26 21:33:01 UTC
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.

Comment 8 Julio Campagnolo 2015-04-25 02:24:04 UTC
This bug occurs too in the wxGTK3 package. Apply the same 2.8 patch to the 3.0 package fix the problem.

Comment 9 zeratul976 2015-06-13 08:44:06 UTC
Will this fix be submitted upstream to wxWidgets?

Comment 10 Vadim Zeitlin 2015-06-14 12:21:46 UTC
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.

Comment 11 Jan Engelhardt 2016-02-20 12:28:02 UTC
Removing the ABI check is downright idiotic. Consider:

class mystring {
    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.

Comment 12 Scott Talbert 2016-02-20 16:11:37 UTC
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.

Comment 13 Marcus Müller 2016-03-15 10:21:45 UTC
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?

Comment 14 Jan Engelhardt 2016-03-15 10:26:37 UTC
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?

Comment 15 Marcus Müller 2016-03-15 11:19:45 UTC
Currently rebuilding from srpm; if this fixes things, what to do? Open another bug requesting rebuild of the binary package?

Comment 16 Marcus Müller 2016-03-15 12:29:22 UTC
Confirmation: rpmbuild --rebuild generates packages that, when installed, don't exhibit the aborting behaviour.

Comment 17 Scott Talbert 2016-03-16 02:52:07 UTC
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.

Comment 18 Marcus Müller 2016-03-16 08:39:50 UTC
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1318171