On 2019-06-14 13:10+0100 Phil Rosenberg wrote:
Just a note about MSVC, what are the ABI concerns you have? It is of note that GCC for windows does not provide ABI forward compatibility https://stackoverflow.com/a/23521099. My understanding is that MSVC's C ABI is consistent across versions and I just did a quick google and found that for C++ MSVC2015, 2017 and 2019 are all ABI compatible. https://devblogs.microsoft.com/cppblog/cpp-binary-compatibility-and-pain-free-upgrades-to-visual-studio-2019/
My concern is gcc/g++ ABI changes fairly often between versions as noted in the stackoverflow link you provided. But as the link implied modern gcc/g++ does provide an option to allow users to specify some older ABI version. So that is what Arjen had to do some time ago when he ran into a MSYS2 library that was compiled with a dated gcc suite of compilers with an older ABI. That condition is caused by the fact it takes a while for Alex to to rebuild every library to be ABI consistent with the latest gcc suite of compilers provided by MSYS2 so with MSYS2 you do run into this temporary (until libraries are rebuilt) problem periodically whenever the gcc suite of compilers has an ABI change. Note, Arjen recently also ran into the opposite problem (MSYS2 compiler had older ABI than compiler used to build the MSYS2 libraries), but that was an artifact of him attempting to use an MSYS2 platform that was not consistently updated. In sum, if using gcc/g++ to be ABI safe you should always build PLplot with exactly the same version of that suite of compilers that are used to build the libraries from the distribution (Cygwin, MSYS2, Debian, etc.). And mixing MSVC-built PLplot with gcc-built libraries or vice versa is not a good idea. However, it sounds from your experience, that if you stick with MSVC that compiler suite ABI does not change very often with version allowing you to use downloaded or built free software libraries that are built with a fairly different MSVC version (but same ABI).
Interestingly it looks like Microsoft is also developing some sort of open source library packaging system, called Vcpkg, to reduce the existing pain of having to build all open source libraries from scratch https://devblogs.microsoft.com/cppblog/vcpkg-a-tool-to-acquire-and-build-c-open-source-libraries-on-windows/. Might be worth looking into. Had a quick scan down the list of available libraries and Cairo, Pango, Curl, wxWidgets are there. HA HA - JUST CHECKED AND SO IS PLPLOT!!! At version 5.13.
That additional distribution of free software for Windows does sound like it is worth checking out. But the link you gave only provided a list of libraries so I am not sure whether the bash, cmp, diff, etc., Unix tools necessary for comprehensive testing are included or not. If so, then you have found a third free software distribution for Windows that generally provides what is available from MSYS2 and Cygwin. However, if not, in theory you can put the MSYS2 versions of those tools at the bottom of your PATH to allow comprehensive testing on the platform using nmake. But that workaround (which historically has worked once for Arjen when he was testing an MSVC environment with no free software libraries) makes testing life a bit tricky so you may want to just stick with pure MSYS2 instead. Alan __________________________ Alan W. Irwin 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.org); 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 __________________________ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel