Bug 953017

Now it works. Solution was doing
# zypper rm hugin
# zypper in hugin

Someone needs to trigger a rebuild of openSUSE:Factory/wxWidgets so that it gets updated to ABI 1009.

This bug is back in current tumbleweed:

# hugin
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,STL containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,STL containers,compatible with 2.8).
Aborted (core dumped)


My guess is that the latest change in wxWidgets-3_0 (which added a patch, but didn't change the version) caused this.

I'd guess triggering a rebuild is needed once more.

It would also make sense to tighten the dependencies (down to the build counter?) to enforce automatic rebuilds.

Build of openSUSE:Factory/wxWidgets-3_0 is in progress.

standard             x86_64     outdated (was: blocked: gnome-vfs2-devel, gstreamer-plugins-base-devel, libnotify-devel, libSDL-devel, gconf2-devel, gnome-vfs2, libgstallocators-1_0-0, libgstapp-1_0-0, libgstaudio-1_0-0, libgstfft-1_0-0, libgstpbutils-1_0-0, libgstriff-1_0-0, libgstrtp-1_0-0, libgstrtsp-1_0-0, libgstsdp-1_0-0, libgsttag-1_0-0, libgstvideo-1_0-0, typelib-1_0-GstAllocators-1_0, typelib-1_0-GstApp-1_0, typelib-1_0-GstAudio-1_0, typelib-1_0-GstFft-1_0, typelib-1_0-GstPbutils-1_0, typelib-1_0-GstRtp-1_0, typelib-1_0-GstRtsp-1_0, typelib-1_0-GstSdp-1_0, typelib-1_0-GstTag-1_0, typelib-1_0-GstVideo-1_0, libnotify4, typelib-1_0-Notify-0_7, libwebkitgtk-devel, libSDL-1_2-0, gconf2, libavahi-glib1, libsmbclient0, gstreamer-plugins-base, typelib-1_0-JavaScriptCore-1_0, typelib-1_0-WebKit-1_0, libwebkitgtk-1_0-0, libjavascriptcoregtk-1_0-0, libpulse0, libsamba-util0, samba-libs, libndr0, libsamba-errors0, libtevent-util0, libndr-standard0, libsmbconf0, libsamba-hostconfig0, libsamba-credentials0, libndr-nbt0, libdcerpc-binding0, libndr-krb5pac0, libsamba-passdb0, libdcerpc0, libsamdb0, libnetapi0, libsmbldap0, libwbclient0)

>It would also make sense to tighten the dependencies (down to the build
>counter?) to enforce automatic rebuilds.

Automatic rebuilds are enforced by OBS itself.

The tightening dependencies could make sense. Dependence on the build (and even on the version) may be too restrictive.

But I have an idea: convert ABI info string to a symbol that could be required/provided:

Example:
3.0 (wchar_t,compiler with C++ ABI 1002,STL containers,compatible with 2.8)

=>
Provides:  wx_abi_3.0_wchar_cppabi1002_stl_compat28
%define wxabi wxabi_3.0_wchar_cppabi1002_stl_compat28

Requires:  %wxabi

After such change, zypper will evaluate the fail condition.

I can confirm the bug on my system.  Also, Jan Engelhardt's suggested fix makes no difference.

Linux Socrates.i-pi.com 4.9.6-1-default #1 SMP PREEMPT Thu Jan 26 09:09:16 UTC 2017 (d1207ac) x86_64 x86_64 x86_64 GNU/Linux

$ rpm -qa | egrep -i 'hugin|wxWidgets' | sort
hugin-2016.2.0-1.4.x86_64
python-wxWidgets-3_0-3.0.2.0-2.10.x86_64
python-wxWidgets-3_0-lang-3.0.2.0-2.10.x86_64
wxWidgets-lang-2.8.12-29.1.noarch

$ hugin
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,STL containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,STL containers,compatible with 2.8).
Aborted (core dumped)

09:35 zap:/dev/shm > g++ x.cpp `wx-config --cflags --libs` -Wall -fabi-version=4
09:35 zap:/dev/shm > ./a.out 
^C
09:35 zap:/dev/shm > g++ x.cpp `wx-config --cflags --libs` -Wall -fabi-version=5
09:35 zap:/dev/shm > ./a.out 
^C

Since I am able to compile using an abi-version that is definitely different from the library (one of them has to be, because the library can only have one state), the patch is functional.

But yes, since the patch touches a .h file, it does mean that all the wx programs need to be rebuilt at least once to pick up the new strategy.

Created attachment 712320 [details]
Active repositories

Sorry Jan Engelhardt, I copied and pasted the wrong name.  I meant that Thomas Wagner's solution didn't work for me.  I attached the repositories currently in use on my system.

$ hugin
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,STL containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,STL containers,compatible with 2.8).
Aborted (core dumped)
$ sudo zypper rm hugin
[sudo] password for root: 
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 4 applications are going to be REMOVED:
  "Hugin Batch Processor" "Hugin Calibrate Lens" "Hugin Panorama Creator"
  "System Tray"

The following package is going to be REMOVED:
  hugin

1 package to remove.
After the operation, 35.5 MiB will be freed.
Continue? [y/n/? shows all options] (y): y
(1/1) Removing hugin-2016.2.0-1.4.x86_64 .................................[done]
Additional rpm output:
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'


There are some running programs that might use files deleted by recent upgrade. You may wish to check and restart some of them. Run 'zypper ps -s' to list these programs.
$ sudo zypper in hugin
Loading repository data...
Reading installed packages...
Resolving package dependencies...

The following 3 applications are going to be installed:
  "Hugin Batch Processor" "Hugin Calibrate Lens" "Hugin Panorama Creator"

The following NEW package is going to be installed:
  hugin

The following application is going to be REMOVED:
  "System Tray"

1 new package to install.
Overall download size: 11.3 MiB. Already cached: 0 B. After the operation,
additional 35.5 MiB will be used.
Continue? [y/n/? shows all options] (y): y
Retrieving package hugin-2016.2.0-1.4.x86_64
                                           (1/1),  11.3 MiB ( 35.5 MiB unpacked)
Retrieving: hugin-2016.2.0-1.4.x86_64.rpm ..................[done (326.9 KiB/s)]
Checking for file conflicts: .............................................[done]
(1/1) Installing: hugin-2016.2.0-1.4.x86_64 ..............................[done]
Additional rpm output:
Unknown media type in type 'all/all'
Unknown media type in type 'all/allfiles'

$ hugin
Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,STL containers,compatible with 2.8),
and your program used 3.0 (wchar_t,compiler with C++ ABI 1010,STL containers,compatible with 2.8).
Aborted (core dumped)

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

@Jan

Hi, currently this is a common problem that our Build Service has...it doesn't respect ABI and rebuild packages accordingly. 

I remembered in the ancient days of our Build Service, once a dependency was updated, everything relies on it got rebuilt. It might be a trigger now set to be false.

I think the situation is better with C/C++ stuff, but much worse with leaf languages like wxWidgets and golang, which highly depends on ABI (eg, packages built with golang 1.3 will not work with golang 1.4 at all.)

So either we solve it from OBS side, or propose a new official RFC that allows core packages' maintainers to add such "look like useless" runtime dependencies like "wxWidgets(ABI) = 1010", "golang(ABI) = 1.4" to guarantee the rebuild will surely happens. (Or some people will insist on that you added an useless Requires, eg, golang is statically built, so someone thought it shouldn't depend on specific version of golang itself).

I think it is worthy that we openly discuss it on opensuse-packaging mailing list. new such problems among leaf languages may occur. it'll greatly improve our system's consistency because such problems usually can't be found at build time.

Marguerite

BTW the patch you added just relaxed ABI requirements for 1002-1010. 

It is not a long-term solution. It didn't touch the key part of such problems.

It just hide itself again, and will reoccur in the future, eg wxWidgets 1011+. 

The key part of such problems is still: 

A package that provides an ABI updates itself, everything relies on that ABI will not rebuild. This is an Open Build Service specific problem.

Marguerite

Like I mentioned, wxWidgets was updated to not depend on Tumbleweed rebuilds anymore. But it needs one more full build cycle, which is not through (yet).

>It just hide itself again, and will reoccur in the future, eg wxWidgets 1011+.

Hm yeah.

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

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

As of today (2017-02-17 ) and after a python-wxWidgets-3_0 rebuild there's still trouble in Tumbleweed
(Obs said same build skipping publish)

Fatal Error: Mismatch between the program and library build versions detected.
The library used 3.0 (wchar_t,compiler with C++ ABI 1002,STL containers,compatible with 2.8),
and wxPython used 3.0 (wchar_t,compiler with C++ ABI 1010,STL containers,compatible with 2.8).
make: *** [../../include/Make/Html.make:14: d.rast.edit.tmp.html] Error 1
rm d.rast.edit.tmp.html
abuild@qt-kt.labaroche.ioda.net:/home/abuild/rpmbuild/BUILD/grass-7.2.0/scripts/d.rast.edit> rpm -qa | grep wx
libwx_baseu_xml-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_adv-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_propgrid-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_media-suse1-3.0.2-9.2.x86_64
wxWidgets-3_0-devel-3.0.2-9.2.x86_64
libwx_baseu-suse1-3.0.2-9.2.x86_64
libwx_baseu_net-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_core-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_html-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_xrc-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_stc-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_gl-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_ribbon-suse1-3.0.2-9.2.x86_64
python-wxWidgets-3_0-3.0.2.0-2.11.x86_64
python-wxWidgets-3_0-devel-3.0.2.0-2.11.x86_64
libwx_gtk2u_richtext-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_aui-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_qa-suse1-3.0.2-9.2.x86_64
libwx_gtk2u_webview-suse1-3.0.2-9.2.x86_64

all coming from pure oss repository of Tumbleweed.

Or simply try 

How to prove wxWidget and python-wxWidget are completely broken on TW

python
import wxversion
wxversion.select(['3.0', '2.8', '2.6'])
import wx 

(SEGV)

Is there a hope to get a fixed, usable status ?

>(Obs said same build skipping publish)

Then it was not really rebuilt.

But I've made a test in Application:Geo:Staging (where I'm trying to fix the grass build) I've done the following

osc linkpac openSUSE:Factory/python-wxWidgets-3_0 Application:Geo:Staging/python-wxWidgets-3_0
wait until build completed for TW x86_64 
and then rerun the grass build

Application:Geo:Staging/python-wxWidgets-3_0-devel: attempting download from api, since not found at download.opensuse.org
 Application:Geo:Staging/python-wxWidgets-3_0: attempting download from api, since not found at download.opensuse.org
fetching packages for 'Application:Geo:Staging'                                   9.3 MB 00:02 
e new build

[452/454] cumulate python-wxWidgets-3_0-3.0.2.0-3.1
[   10s] [453/454] cumulate wxWidgets-3_0-devel-3.0.2-9.2
[   10s] [454/454] cumulate python-wxWidgets-3_0-devel-3.0.2.0-3.1

So guess what, the build failed, with the previous comment about mismatch ABI

So my conclusion is that wx stack is for the moment completely broken, creating a burden of load and a waste in contributing effort.

The problem is with wxPython. Turns out someone made a copy of most/all wxWidgets headers (which, by now, are out of date) and bundled them with wxPython. *facepalm*

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

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

This is an autogenerated message for OBS integration:
This bug (953017) was mentioned in
https://build.opensuse.org/request/show/458710 Factory / python-wxWidgets-3_0

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

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

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

Maybe this helps understand this bug. I had to build the latest git of wxhexeditor for another bug, it wouldn't build for 42.2 due I think to gcc48 not handling stc++11 properly so I built against gcc6, it built but when I installed it it had the compatability bug. This was built against wxWidgets-3_0 from the oss Leap:42.2 repo. I then built it against the latest wxWidgets-3_0 with Jan's changes and it works. I couldn't reproduce this problem with 42.2 before, seems it only affects gcc6 built packages.

Has entered Factory.