Thank you for the information. I updated the ABI relaxation patch and rebuild wxwidgets and everything seems to be working fine. Since the wxWidgets project has not updated their include/wx/build.h header to include the 1011 ABI, I may hold off on submitting this patch in case there are some corner cases that could cause issues with the wxwidgets library. Of course wxPython doesn't work not because it is still build with an older ABI so using -fabi-version may be the path of least resistance.
On 7/11/2017 8:29 PM, Alan W. Irwin wrote: > On 2017-07-11 15:17-0400 Wayne Stambaugh wrote: > >> 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 >> > [...] >> 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? This patch[1] is from the wxwidgets project. This is not specific to msys2 project. The wxwidgets header include/wx/build.h was last updated for the 1010 ABI compatibility on 01/24/16. I'm guessing they haven't got around to updating it for 1011 ABI compatibility. [1]: https://github.com/wxWidgets/wxWidgets/commit/ad21cc332ac906b9ae8f238ab135cbe410e78eba > > 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. Doing this could potentially create an issue when linking against libraries that have a ABI version greater than the build version using -fabi-version. I'm not sure this would be any better than linking against libraries built with older ABIs. > > 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 > __________________________ ------------------------------------------------------------------------------ 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
