Alan, I have three mingw32 installation in my computer, not by choice: as I worked with one I would hit a snag that was possibly solved with a new configuration. The third installation, made by recipe found here, http://ingar.satgnu.net/devenv/mingw32/gtk.html included an updated compiler from mingw-w64. And things work with this compiler where they are broken with an unadorned mingw. I resolved my issue with plplot examples by discovering - new to me- the libstdc++ issue with dwarf/sjlj: - from my reply note:
" ok that solves this issue: I had kept a copy of the (dwarfish) libstdc++-6 in the general programs directory, rather than improvig hte path to point to the correct version, which I know now is sjlj in /mingw32." Was I really supposed to know all this to run a program? I suppose that is a pitfall of combining different systems under one roof. I'm doing nothing "in the wilderness", just using a superior gcc toolchain which is successful because people are actively producing the mingw-w64 builds, updating the header files to keep up with stuff visual C++ users will use. I dont see much maintenance going on with mingw32, and it shows in the problems I come across trying to do builds. Every configure I do and CMAKE I run is happy with the results of gcc, I think the headers may be tweaked a bit better than legacy mingw (legacy = as in, no maintainers). From my contemporaneous experience including a recheck I did today, using the gcc as built from mingw-w64 works better, works equivalently. I'm not pioneering, only doing what I need to get by. Regards, Greg
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
