Bug 953017 - hugin won't start on Tumbleweed due do C++ ABI version mismatch
hugin won't start on Tumbleweed due do C++ ABI version mismatch
Status: RESOLVED FIXED
: 985362 985376 986540 1022819 1023418 1023841 1025008 1025314 (view as bug list)
Classification: openSUSE
Product: openSUSE Tumbleweed
Classification: openSUSE
Component: Other
Current
Other Other
: P5 - None : Normal with 10 votes (vote)
: ---
Assigned To: Stanislav Brabec
E-mail List
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2015-10-31 14:10 UTC by Thomas Wagner
Modified: 2017-02-21 13:48 UTC (History)
13 users (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Active repositories (1.85 KB, text/plain)
2017-01-31 18:18 UTC, Kenneth Ingham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wagner 2015-10-31 14:10:16 UTC
Fatal Error: Mismatch between the program and library build versions detected.
The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1009,STL containers,compatible with 2.6),
and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,STL containers,compatible with 2.6).
Abgebrochen (Speicherabzug geschrieben)



# zypper info hugin
Systeminformation:
Informationen für Paket hugin:
-------------------------------
Repository: repo-oss
Name: hugin
Version: 2015.0.0-1.2
Arch: x86_64
Anbieter: openSUSE
Installiert: Ja
Status: veraltet (Version 2014.0.0-3.1 installiert)
Installierte Größe: 36,5 MiB
Zusammenfassung: Toolchain for Stitching of Images and Creating Panoramas
Beschreibung: 
  Hugin can be used to stitch multiple images together. The resulting
  image can span 360 degrees. Another common use is the creation of very
  high resolution pictures by combining multiple images.
  Other tools in this package can correct lens distortion, vignetting and
  chromatic abberation, create HDR images, provide automatic feature
  detection and extraction of key points.

# cat /etc/os-release 
NAME=openSUSE
VERSION="Tumbleweed"
VERSION_ID="20151022"
PRETTY_NAME="openSUSE Tumbleweed (20151022) (x86_64)"
ID=opensuse
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:opensuse:20151022"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://opensuse.org/"
ID_LIKE="suse"

# hugin
Fatal Error: Mismatch between the program and library build versions detected.
The library used 2.8 (no debug,Unicode,compiler with C++ ABI 1009,STL containers,compatible with 2.6),
and your program used 2.8 (no debug,Unicode,compiler with C++ ABI 1002,STL containers,compatible with 2.6).
Abgebrochen (Speicherabzug geschrieben)
Comment 1 Thomas Wagner 2015-10-31 16:47:32 UTC
Now it works. Solution was doing
# zypper rm hugin
# zypper in hugin
Comment 2 Jan Engelhardt 2015-10-31 17:23:14 UTC
Someone needs to trigger a rebuild of openSUSE:Factory/wxWidgets so that it gets updated to ABI 1009.
Comment 3 Christian Boltz 2017-01-30 12:42:05 UTC
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.
Comment 4 Jan Engelhardt 2017-01-30 12:58:34 UTC
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)
Comment 5 Stanislav Brabec 2017-01-30 19:35:34 UTC
>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.
Comment 6 Kenneth Ingham 2017-01-31 01:38:37 UTC
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)
Comment 7 Jan Engelhardt 2017-01-31 08:37:34 UTC
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.
Comment 8 Kenneth Ingham 2017-01-31 18:18:15 UTC
Created attachment 712320 [details]
Active repositories
Comment 9 Kenneth Ingham 2017-01-31 18:20:15 UTC
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)
Comment 10 Jan Engelhardt 2017-02-06 17:00:14 UTC
*** Bug 1023841 has been marked as a duplicate of this bug. ***
Comment 11 Marguerite Su 2017-02-06 17:20:38 UTC
@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
Comment 12 Marguerite Su 2017-02-06 17:31:00 UTC
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
Comment 13 Jan Engelhardt 2017-02-06 17:41:18 UTC
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).
Comment 14 Jan Engelhardt 2017-02-06 17:43:21 UTC
>It just hide itself again, and will reoccur in the future, eg wxWidgets 1011+.

Hm yeah.
Comment 15 Marguerite Su 2017-02-13 09:06:49 UTC
*** Bug 1023418 has been marked as a duplicate of this bug. ***
Comment 16 Jan Engelhardt 2017-02-15 22:16:53 UTC
*** Bug 1022819 has been marked as a duplicate of this bug. ***
Comment 17 Bruno Friedmann 2017-02-17 11:01:02 UTC
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 ?
Comment 18 Jan Engelhardt 2017-02-17 11:46:34 UTC
>(Obs said same build skipping publish)

Then it was not really rebuilt.
Comment 19 Bruno Friedmann 2017-02-17 12:06:35 UTC
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.
Comment 20 Jan Engelhardt 2017-02-17 13:21:17 UTC
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*
Comment 21 Stanislav Brabec 2017-02-17 16:00:23 UTC
*** Bug 1025008 has been marked as a duplicate of this bug. ***
Comment 22 Jan Engelhardt 2017-02-17 17:00:30 UTC
*** Bug 1025314 has been marked as a duplicate of this bug. ***
Comment 23 Bernhard Wiedemann 2017-02-17 17:01:58 UTC
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
Comment 24 Jan Engelhardt 2017-02-17 17:06:02 UTC
*** Bug 986540 has been marked as a duplicate of this bug. ***
Comment 25 Jan Engelhardt 2017-02-17 17:07:58 UTC
*** Bug 985376 has been marked as a duplicate of this bug. ***
Comment 26 Jan Engelhardt 2017-02-17 17:08:30 UTC
*** Bug 985362 has been marked as a duplicate of this bug. ***
Comment 27 Dave Plater 2017-02-19 11:45:49 UTC
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.
Comment 28 Jan Engelhardt 2017-02-21 13:48:22 UTC
Has entered Factory.