Bug 1200611 - RFE: Remove ABI comparison check
RFE: Remove ABI comparison check
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: wxGTK (Show other bugs)
22
All Linux
unspecified Severity urgent
: ---
: ---
Assigned To: Dan Horák
Fedora Extras Quality Assurance
: Reopened
: 1192921 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-03-10 19:48 EDT by Orion Poplawski
Modified: 2016-03-16 04:39 EDT (History)
11 users (show)

See Also:
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 17:33:01 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Orion Poplawski 2015-03-10 19:48:11 EDT
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):
wxGTK-devel-2.8.12-13.fc22.x86_64
Comment 1 Petr Pisar 2015-03-11 07:40:15 EDT

*** This bug has been marked as a duplicate of bug 1190971 ***
Comment 2 Orion Poplawski 2015-03-11 11:22:46 EDT
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
Comment 3 Dan Horák 2015-03-12 12:51:30 EDT
I have converted the abort on ABI mismatch to a warning.
Comment 4 Fedora Update System 2015-03-12 15:47:03 EDT
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
Comment 5 Dan Horák 2015-03-13 12:08:27 EDT
*** Bug 1192921 has been marked as a duplicate of this bug. ***
Comment 6 Fedora Update System 2015-03-13 12:59:53 EDT
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).
Comment 7 Fedora Update System 2015-03-26 17:33:01 EDT
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-24 22:24:04 EDT
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 04:44:06 EDT
Will this fix be submitted upstream to wxWidgets?
Comment 10 Vadim Zeitlin 2015-06-14 08:21:46 EDT
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 07:28:02 EST
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.
Comment 12 Scott Talbert 2016-02-20 11:11:37 EST
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 06:21:45 EDT
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 06:26:37 EDT
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 07:19:45 EDT
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 08:29:22 EDT
Confirmation: rpmbuild --rebuild generates packages that, when installed, don't exhibit the aborting behaviour.
Comment 17 Scott Talbert 2016-03-15 22:52:07 EDT
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 04:39:50 EDT
Done: https://bugzilla.redhat.com/show_bug.cgi?id=1318171

Note You need to log in before you can comment on or make changes to this bug.