The gcc -v I get from my default setup: COLLECT_LTO_WRAPPER=e:/mingw/mingw32/bin/../libexec/gcc/i686-w64-mingw32/ Target: i686-w64-mingw32 Configured with: ../../../src/gcc-4.8.2/configure --host=i686-w64-mingw32 << etc. snip >> 32-static/lib -Wl,--large-address-aware' Thread model: win32 gcc version 4.8.2 (i686-win32-sjlj, Built by MinGW-W64 project)
msys is simply msys, on its own tree and v1.0; no msys dll's are used, anyway. The /mingw32/bin files could just as easily be located in /mingw/bin and it would function identically. The recipe I used to build this particular mingw installation followed up the mingw-get sequence with a download of the sjlj- gcc package. The mingw/bin directory is still there, doing any chores which are not compiler-specific. If I were to take the /mingw32/bin out of my path I'd have the gcc that came with the package, a dwarf2- 4.8.1 toolchain. They have different STDC++ libraries which nevertheless hav the same name, and that's where my trouble came from: the examples compiled with SJLJ but I had a dwarf2 libstdc++-6.dll waiting in my windows path, On Wed, Oct 29, 2014 at 1:28 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2014-10-29 13:06-0700 Greg Jung wrote: > > I've been perusing mailing lists etc. about this, I don't understand >> enough to pass on what I might have learned, but I'll write a few lines >> just to help get it straight in my own mind. Newer versions >> of GCC for win32, 4.8.1, ... 4.9.1, come in four flavors: split on >> threads. >> (win32 .vs. posix), and on exception handling (sjlj vs dwarf2). Evidently >> posix,dwarf2 is the most popular download configuration. >> http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting% >> 20Win64/Personal%20Builds/mingw-builds/ >> > > You forgot at least one additional important gcc flavour factor: note > the link you gave was a mingw-w64 one. That is quite different from > MinGW (separate developers, separate download area, etc., etc.). > > So when you say you are doing experiments on MinGW/MSYS are you actually > referring to that or the entirely separate project MinGW-w64/MSYS2? > > Arjen and I are referring exactly to MinGW/MSYS. The separate project > MinGW-w64/MSYS2 is a platform that is well worth trying, but that has > not been done yet (as far as I know) so I would not be surprised if > there were PLplot build-system issues to solve for that platform. > > > 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 > __________________________ >
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
