Bug 660438

Or other way around:

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

The openSUSE package uses default build options (neither --enable-compat24 nor --disable-compat26 are specified in the openSUSE spec file, 2.6 compatibility being on and 2.4 compatibility being off by default). It must be Fedora that uses non-default build options. Changing this would make openSUSE compatible with Fedora, but incompatible with previous openSUSE releases (will cause upgrade problems because the SONAMEs of the libraries are the same, but the libraries are still incompatible) and Debian, which does not seem to use --enable-compat24 either (--enable-compat24 does not exist anymore in wxWidgets-2.9.1, btw.).

I think the solution should be change in runtime check, which should allow running program compiled with a library supporting 2.8 and 2.6 on a system where the library supports 2.8, 2.6 and 2.4 - i.e. wider compatibility features. The runtime should not interrupt program execution in this case.

Maybe even to remove the runtime che4ck altogether, and resolve thr problem by the standard dependency checks during installation as with any other toolkit.

P.S. Sompatibility with Debian is not really important here because packaging for Debian would anyway involve rebuilding. But compatibility with other RPM-based distros would allow developers to make cross-distribution packages (like those compatible with LSB).

I haven't looked at how the run-time checks work, I'm just commenting the packaging side and potential upgrade problems.

In the Fedora package there is:

%configure \
  --enable-compat24

* Thu Dec 14 2006 Matthew Miller <mattdm@mattdm.org> - 2.8.0-2.8.0.0.1
- compatibility with wxWidgets 2.2 is now gone; add flag to build 2.4 with
  compatibility, though (now off by default)

=> I don't think it's good idea to change this in the existing wxGTK-2.8 packages, but it may be worth striving for compatibility with Fedora in the wxWidgets-2.9 packages - which are not yet part of the distribution, but under preparation in the Build Service: https://build.opensuse.org/project/show?project=X11:wxWidgets. Problem: Fedora does not seem to be preparing any wxWidgets-2.9 packages yet.

It's right that compatibility with Fedora is more important than compatibility with Debian/Ubuntu, but the latter is still worth something (binaries are not necessarily packaged as rpm or deb) and compatibility with Fedora cannot be achieved in the 2.8 packages without either modifying the code (should better be done upstream, unlikely to happen for the 2.8 codebase now that wxWidgets-2.9 is being developed) or becoming self-incompatible.

What can I say, runtime dependency check is anyway contrary to RPM principles. We should either disable it if possible or submit a patch upstream.

(changed during the 2011-02-20 Open-Bugs-Day about bugs for obsolete versions of openSUSE)

Agree, there shouldn't be a problem running a binary built for wx 2.6-2.8 against wx 2.4-2.6-2.8 libs. Report to upstream.

In the meantime, one could just build separate binaries for openSUSE and Fedora.

Still the same problem under openSUSE 12.1

I seen some problems with --enable-compat26 in past. Now we have many variants of the ABI, so I guess that we can selectively enable on variants where it works. (Guessing that ANSI and wx container.)

Could you provide links to your binaries for my testing?

Yes the behavior of wxWidgets is counter-intuitive and makes building cross-distribution binaries that use WxGTK as complicated as possible. But it is an upstream problem, not downstream.

The upstream did a bad thing: Configure options change ABI, but not always the library name. So binaries compiled against wxWidgets compiled with different configure options cannot live together on one system.

That is why openSUSE now uses dedicated directories and compat packages.

See README.SUSE in wxWidgets package? https://build.opensuse.org/package/view_file?file=README.SUSE&package=wxWidgets&project=X11%3AwxWidgets

Which ABI variant you are using in your third party package?

openSUSE now offers 3 incompatible ABI variants in openSUSE:
- version 2.8.x, ANSI
- version 2.8.x, Unicode, wx container
- version 2.8.x, Unicode, STL

and another 9 variants in the openSUSE Build Service.
- version 2.9.x, ANSI
- version 2.9.x, Unicode, wx container
- version 2.9.x, Unicode, STL
- version 2.8.x, ANSI, with debugging support
- version 2.8.x, Unicode, wx container
- version 2.8.x, Unicode, STL, with debugging support
- version 2.9.x, ANSI, with debugging support
- version 2.9.x, Unicode, wx container, with debugging support
- version 2.9.x, Unicode, STL, with debugging support

If you want to use third party binaries compiled against wxWidgets, the solution provided forces following limitation:
- only one ABI can be used on the system by third party binaries
- you have to install one of "compat" packages
- If you must install more third party binaries using different ABIs, you have to write LD_LIBRARY_PATH wrapper for all of these ABIs except the one that is represented by the compat package.

Note that if you are using third party RPM, zypper and YaST will automatically ask you to install one of these libraries. But it does not know, which of variants above is the correct one for your application. You have to pick correct one manually.

For example, running springlobby from Fedora results in an error message as cited above:

http://download.fedora.redhat.com/pub/fedora/linux/updates/16/x86_64/springlobby-0.139-1.fc16.x86_64.rpm

Installing WxGTK from Fedora will make WxGTK apps from SUSE not working.

Possibly we should disable runtime ABI checks but include all ABI options as dependencies in RPM packages.

comment 11: Applications in openSUSE 11.2 prefer STL ABI. Maybe Fedora packages break them.

Well, I'll try to enable compat 2.4 and 2.6 in wx container variant. If it break wx container binaries that don't enable 2.4 and 2.6, we will have to add up to another 24 ABI variants. (all combinations of enable flags)

comment 12: There is a wrapper that modifies rpm dependencies of all openSUSE wxWidgets related packages. But for some reason it didn't work as expected. Trying to install springlobby, zypper offered to install wxWidgets-ansi-compat-lib-config and libwx_*-compat-lib-stl, which cannot work.

I have bad news. Adding --enable-compat-24/26 again changes ABI.

Rebuilt with --enable-compat24 --enable-compat26 makes springlobby working, but it breaks audacity from openSUSE (which uses the same unicode + wxcontainer ABI):

audacity: Symbol `_ZTV12wxBufferedDC' has different size in shared object, consider re-linking
audacity: Symbol `_ZTV10wxClientDC' has different size in shared object, consider re-linking
audacity: Symbol `_ZTV10wxMemoryDC' has different size in shared object, consider re-linking
audacity: Symbol `_ZTV17wxBufferedPaintDC' has different size in shared object, consider re-linking
Fatal Error: Mismatch between the program and library build versions detected.
The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.4,compatible with 2.6),
and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,wx containers,compatible with 2.6).

It means, that we probably have to add 24 ABI variants (or at least 16) to make happy all third party packages users (2.4 only enabled (maybe this one can be omitted), 2.6 only enabled, both 2.4 and 2.6 enabled it all for 2.8 ANSI, 2.8 wxcontainer, 2.9 ANSI, 2.9 wxcontainer, and that all both non-debug and debug).

Or just tell users that it is not wise idea to build cross-distro packages using system wxWidgets.

Why not just disable runtime check?

Because the ABI really breaks when you change configure options and library only sometimes changes its name.

It is better if the application refuses to start than if the application mysteriously crashes. Upstream "fixed" this problem by adding the check. (We have had bug reports related to that problem in past.)

We just have to live with the fact, that any wxWidgets 2.8 version can be built as at least 40 binary incompatible variants. Some libraries and plugins can be build only in some of these variants.

Some applications can be built only with a subset of these variants (e. g. no-Unicode variants only, no-STL variants only, only with compat 24/26 etc.).

Will program built for 2.6 API work under library built with 2.4 and 2.6 API if the runtime check is disabled? I doubt it will not.

Maybe yes, maybe not, maybe it will mysteriously crash on memory corruption because structure size changed. wxWidgets developers don't care about that.

We already know, that --enable-stl really breaks ABI and causes crashes, that --enable-unicode breaks ABI (but it changes library name), that --enable-mediactrl slightly changes ABI and causes unresolved symbols. Every such --enable-something change generated one or more bug reports in the past. Do you want to repeat this experience?

In case of these compat options:

Enabling them enlarges size and indexes of wxTreeCtrl and wxHtmlCell on other position than the end of the structure => Application compiled with compat enabled will probably sometimes crash on memory corruption with libraries compiled without compat enabled, even if the application does not use any deprecated method. Reverse will not crash on memory corruption, but it may call different methods than intended.

I created just another variant of wxWidgets packages: wxcontainer24c.

This variant will third party package support will be represented by two identical packages:
wxWidgets-wxcontainer24c-compat-lib-config: It will be always --enable-unicode --disable-stl --enable-compat24.

wxWidgets-fedora-compat-lib-config: It will follow Fedora configuration.

Reason, why this will be done as an extra package:

ZYPP does not allow conflict comments yet. If the user is requested to resolve conflict, only package names are presented. Picking something with "fedora" in the package name will make things more intuitive. Keeping only "fedora" package would make confusion for people that need it for non-Fedora package and they only know the error message presented above.

Runtime check does not complain and applications seems to work correctly.

Packages are available in X11:wxWidgets OBS repository and will be submitted to Factory. After fix of bug 757124, the behavior should be following:

zypper in name_of_fedora_package

If you don't have any third party wxWidgets package installed yet, ZYPP will ask you to resolve problem: There are more packages that provide libraries you need. If you just pick the solution that contains wxWidgets-fedora-compat-lib-config, then you will be able to run unmodified Fedora packages.

If you already installed one of compat-lib-config packages, you will not see this message - there is no way to recognize, that rpm contains binaries compiled with a different configuration.

There is just a limitation:
- Any number of wxWidgets libraries variants is allowed for openSUSE packages that follow README.SUSE.
- Only one compat library config is allowed for third party package. So you cannot mix packages from different third party sources: There is no way, how to pick particular library variant for particular binary. If there would be such need, it is possible to work-around it with:
-- wxrun script that will set LD_LIBRARY_PATH (easy to implement)
-- some type of ugly wrapper that will try to recognize, which variant to load (hard to implement)

I cannot figure out why not to follow the other way:

- Build wxwidgets with all possible compatibility options

- Disable runtime compatibility check

New packages are available in X11:wxWidgets and they were submitted to openSUSE:Factory with request id 114855.

To comment 21:

> - Build wxwidgets with all possible compatibility options

It is impossible. Adding all compatibility options will break API, ABI, Unicode support, and STL support.

Only --enable-compat24 and --enable-compat26 don't break API. --enable-compat26 is enabled by default. Adding --enable-compat24 does not break API, but it breaks ABI. Maintainers of Packman will not be happy that we break their RPMs again. I cannot simply change these options. I have to add new variant with new options, which clearly tells to the RPM, which application RPM is compatible with which library RPMs.

Well, I can think about disabling wxcontainer variant in future and keeping only wxcontainer24c that was created just now. So people using binaries compiled for openSUSE <= 12.1 will have more time to migrate.

Before doing so, I would check all other distributions that ship binaries of wxWidgets libraries. Now we have packaging scheme that allows different compat-lib versions supporting different distros, so we can easily support as much third party binary packages as possible.

Adding --enable-compat24 to STL variant is possible as well, but it makes only a little sense. STL containers in wxWidgets were introduced later than 2.4. So most applications compatible with STL don't need 2.4 API.

> - Disable runtime compatibility check

The check is not here for fun. Upstream clearly declares here: We ignore ABI compatibility and we are aware of it. Don't try to combine such binaries and libraries. Disabling the check only postpones and randomizes crashes. Now it consistently fails on start. After disabling the check, some applications will work, but others will fail randomly on memory corruption. I surely don't want to debug such crashes again.

Even after disabling the check, ld.so will complain on different sizes of structures in library and binaries, and it will suggest relinking of such application.

This is an autogenerated message for OBS integration:
This bug (660438) was mentioned in
https://build.opensuse.org/request/show/114855 Factory / wxWidgets

This is an autogenerated message for OBS integration:
This bug (660438) was mentioned in
https://build.opensuse.org/request/show/601054 15.0 / wxWidgets-3_0

This is an autogenerated message for OBS integration:
This bug (660438) was mentioned in
https://build.opensuse.org/request/show/670842 15.1 / wxWidgets-3_0

This is an autogenerated message for OBS integration:
This bug (660438) was mentioned in
https://build.opensuse.org/request/show/674518 15.1 / wxWidgets-3_0

This is an autogenerated message for OBS integration:
This bug (660438) was mentioned in
https://build.opensuse.org/request/show/686201 15.1 / wxWidgets-3_0