[Msys2-users] wxWidgets ABI mismatch again.

Discussion:

Wayne Stambaugh

2017-07-11 17:02:59 UTC

I've just finished building KiCad after performing an upgrade to gcc 7.1
and once again I'm faced with an ABI mismatch error between the
wxWidgets library build ABI version (1010) and the program build ABI
version 1011. I rebuilt and installed the wxWidgets packages using gcc
7.1 but I'm still getting the ABI version error. Should I report this
on the issue tracker on github or is someone already working on it. In
the mean time any help resolving this issue until new wxwidgets packages
are built would be appreciated so I can get some work done. I imagine
this will also effects wxPython as well. Thanks in advance for the help.

Cheers,

Wayne

David Grayson

2017-07-11 18:43:48 UTC

Permalink

I don't know what your current state is, but I would try to do this:

1) Remove any instances of the "-fabi-version" GCC argument from the
packages involved.
2) Make sure everything was compiled with the same version of GCC.

--David

Post by Wayne Stambaugh
I've just finished building KiCad after performing an upgrade to gcc 7.1
and once again I'm faced with an ABI mismatch error between the
wxWidgets library build ABI version (1010) and the program build ABI
version 1011. I rebuilt and installed the wxWidgets packages using gcc
7.1 but I'm still getting the ABI version error. Should I report this
on the issue tracker on github or is someone already working on it. In
the mean time any help resolving this issue until new wxwidgets packages
are built would be appreciated so I can get some work done. I imagine
this will also effects wxPython as well. Thanks in advance for the help.
Cheers,
Wayne
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Msys2-users mailing list
https://lists.sourceforge.net/lists/listinfo/msys2-users

Wayne Stambaugh

2017-07-11 19:09:06 UTC

Permalink

Post by David Grayson
1) Remove any instances of the "-fabi-version" GCC argument from the
packages involved.
2) Make sure everything was compiled with the same version of GCC.
--David

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Msys2-users mailing list
https://lists.sourceforge.net/lists/listinfo/msys2-users

Wayne Stambaugh

2017-07-11 19:17:32 UTC

Permalink

I am building KiCad from source so the ABI will be determined by the gcc
configuration which I'm guessing from the error message is 1011.

There is this interesting patch:

https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-wxwidgets/wxWidgets-3.0.2-relax-abi-compatibility-gcc.patch

which I am guessing is the culprit. It seems to me that this should
have failed when the switch to the 1010 ABI was made. I'm not a gcc
expert but I would be leery of changing:

+ #if ((__GXX_ABI_VERSION >= 1002) && (__GXX_ABI_VERSION <= 1008))

to:

+ #if ((__GXX_ABI_VERSION >= 1002) && (__GXX_ABI_VERSION <= 1011))

in the patch given the ABI changes called out at:

https://gcc.gnu.org/onlinedocs/gcc/C_002b_002b-Dialect-Options.html

Some of the changes between ABI versions 8 through 11 look like they may
not be compatible but I'm not completely sure about this.

Even the latest build.h file at wxWidgets is still showing ABI 1010 as
the maximum compatible ABI version.

https://github.com/wxWidgets/wxWidgets/blob/master/include/wx/build.h

I guess I will try changing the ABI patch to 1011 and see what happens.

Post by David Grayson
1) Remove any instances of the "-fabi-version" GCC argument from the
packages involved.
2) Make sure everything was compiled with the same version of GCC.
--David

Alan W. Irwin

2017-07-12 00:29:07 UTC

Permalink

Post by Wayne Stambaugh
I am building KiCad from source so the ABI will be determined by the gcc
configuration which I'm guessing from the error message is 1011.
https://github.com/Alexpux/MINGW-packages/blob/master/mingw-w64-wxwidgets/wxWidgets-3.0.2-relax-abi-compatibility-gcc.patch

[...]

Post by Wayne Stambaugh
I guess I will try changing the ABI patch to 1011 and see what happens.

I think a better approach is to completely throw away that above
relax-abi-compatibility patch. The wxwidgets developers obviously don't think
relaxing their ABI compatibility requirements is a good idea so why
should MSYS2 builders of the wxwidgets library relax that caution
which is probably well-founded?

Instead for a reliable workaround for the fundamental issue use the
-fabi-version=n g++ option on builds of your own software where n is
1000 less than the ABI number for the wxwidgets library build that is
reported in the popup error message.

But as I alluded to in my other post the fundamental issue is MSYS2 is
currently not delivering a platform that is guaranteed to have a
self-consistent ABI no matter what time a user updates his system.
That problem is soluble (virtually all other rolling releases of free
software based on the gcc compiler suite are able to deliver on that
self-consistent ABI guarantee) so I assume it only a matter of time
(but probably a lot of work and time unless the MSYS2 developers are
willing to adapt a solution from another rolling-release distro)
before MSYS2 can provide that guarantee as well.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

Alan W. Irwin

2017-07-11 23:21:14 UTC

Permalink

I wrote to this list recently concerning a similar issue (see
<https://sourceforge.net/p/msys2/mailman/msys2-users/thread/***@enira.zlyna.ubzr/#msg35916206>)
which was at that time a 1008 MinGW-w64/MSYS2 build ABI versus 1010
for the latest gcc release at that time while your latest issue is an
ABI mismatch between 1010 for the MSYS2 library and 1011 for your build.

It turned out the workaround then for these wxwidgets ABI
issues was to build your application as you normally do with the
latest g++ from MSYS2, but whenever you get an ABI mismatch message
specify the ABI number of the library build using the g++ option
-fabi-version=n, where n = library ABI number - 1000. So in that
previous case the successful workaround was use -fabi-version=8 for
the build of our own application, and I am virtually positive from
what you reported above that if you tried the temporary workaround
-fabi-version=10, you would be fine, but you would have to keep
constantly changing that workaround each time you updated anything to
do with MSYS2 (either the wxwidgets libraries or g++).

My further understanding from that thread is the MSYS2 library build
process is currently not automated and definitely not atomic in the
computing sense, i.e., there is currently no assurance that whenever
MSYS2 is updated by a user at any time, that user is assured that the
latest gcc, g++, etc., version they acquire is the same one used to
build the libraries. But when MSYS2 solves that atomicity problem
(presumably by the appropriate automatic build and atomic update
process), these constant ABI inconsistency issues with wxwidgets will
go away.

Furthermore, because wxwidgets is so careful about ABI inconsistency
it is the "canary in the coal mine" for the MSYS2 project. That is
other projects that do not detect ABI inconsistencies as well as
wxwidgets does will be similarly affected by those ABI inconsistencies
in the non-automated and non-atomic build process that MSYS2 has now.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________