On 2015-07-15 13:24-0700 Walt Brainerd wrote: > First, yes, those are the correct compilers: > > bash-3.1$ which gfortran > /c/mingw/bin/gfortran.exe > bash-3.1$ gfortran --version > GNU Fortran (tdm64-1) 5.1.0 > > I tried MSYS2 to see what would happen. > Nothing works--not even git. Says my > version of cygwin.dll is incompatible. > (Incompatible with what? The compilers, > cygwin and msys2 are all the latest 64-bit > version). What is the point of MSYS if > you also have to have Cygwin?
> > So I deleted Msys2 and reinstalled msys1. > > [It looked interesting for progressing with > coarray Fortran as it includes /dev/shm.] > > Your test didn't get very far, but here it is: > > http://www.fortran.com/Test2/*tar.gz Hi Walt: Sorry I have been a bit slow to respond today, but I have a number of things on my plate as release manager with the release of 5.11.1 coming up in 10 days. I am very happy to see a proper report tarball at the above URL rather than the peculiar one we had for Test1. That report is exactly what I should have needed to get further, but as you stated your test stopped virtually instantly. The error message (in shared/output_tree/cmake.out) was CMake Error: Could not create named generator MSYS Makefiles I have been told elsewhere that the MSYS2 version of cmake does not have the MSYS Makefiles generator because you should always use the "Unix Makefiles" generator on that platform. So from that it appears you might have been using the MSYS2 version of cmake, but that doesn't jibe with your statement above that your removed MSYS2. I am now left wondering if your TDM environment fails to do a clean job of imposing MSYS2 on a previous MSYS platform (explaining why you could not get MSYS2 to work) or vice versa (explaining why from the above error message some part of MSYS2 appears to still be left). Anyhow, I suggest you start over with a new clean install of TDM using a unique installation prefix so that it is always easy thereafter to remove that version of TDM if it gets clobberred. According to <http://tdm-gcc.tdragon.net/about> you have two choices which are MinGW or MinGW-w64. But I assume that really means your choices are MinGW/MSYS (a very limited environment which you denote as MSYS1) or MinGW-w64/MSYS2 since MSYS is normally used as a companion to MinGW and MSYS2 is normally used as a companion to MinGW-w64. Anyhow, when you start over with TDM I suggest you pick MinGW-w64/MSYS2 from the get go (and the 64-bit rather than 32-bit version if you are offered the choice by TDM) to see if that clean version works for you. And in that case you must use MSYS2 version of cmake and the "Unix Makefiles" generator. On the other hand, if you decide to make a clean start with TDM using MinGW/MSYS from the get go, then in that case you have to use the raw Windows version of cmake (that you can download from Kitware) and the "MSYS Makefiles" generator. I hope that helps to clarify your TDM choices. Also, note it appears to be a constant problem on Windows that installation to default areas never works properly because of overlapping results from other similar but not identical installations (such as MinGW/MSYS and MinGW-w64/MSYS2) and the inability to clean out the default install area properly. Thus, I have long advocated using separate install prefixes as above. I don't have a lot of Windows experience so I am not sure my recommendation is common, but I do note that the one site I have found (<http://www.openwalnut.org/projects/openwalnut/wiki/InstallMSYS2>) that is the source of the recommendation that you must use the MSYS2 version of CMake and the "Unix Makefiles" generator with MinGW-w64/MSYS2 _also_ recommends a separate install prefix for MinGW-w64/MSYS2. So at least I am not alone in recommending a separate install prefix! Alan P.S. I notice you asked further question in a later e-mail, but I believe I have answered all of them here. But if not, please ask them again in light of the extra information I have given here. 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 __________________________ ------------------------------------------------------------------------------ Don't Limit Your Business. Reach for the Cloud. GigeNET's Cloud Solutions provide you with the tools and support that you need to offload your IT needs and focus on growing your business. Configured For All Businesses. Start Your Cloud Today. https://www.gigenetcloud.com/ _______________________________________________ Plplot-general mailing list Plplot-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-general
