On 2017-07-11 13:02-0400 Wayne Stambaugh wrote:
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.
I wrote to this list recently concerning a similar issue (see <https://sourceforge.net/p/msys2/mailman/msys2-users/thread/alpine.deb.2.11.1706271801150.14...@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 __________________________ ------------------------------------------------------------------------------ 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 Msys2-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/msys2-users