Backslide bug in install script?

[SourcerersApprentice]

I have been working with the OpenCoarrays install script, trying to get it working with msmpi and gfortran. I was previously able to get the install to progress to the point where it started doing tests to evaluate MPI support by forcing cmake to use the "MSYS Makefiles" generator. After getting the latest script (updated last weekend?) it now fails to evaluate the C compiler. Appended is a snip of the verbose output. The thing that jumps out at me is the object file name testCCompiler.c.obj looks a little funny, but it doesn't bother my mpicc when I feed it that by hand. I have a working, tested (with scalapack test suite) msmpi v7 64 bit mpich installation working with gfortran, however there is still a question of whether there is sufficient mpi3 support in the msmpi7 package to build coarrays. I will report back on what might be needed to support gfortran caf on windows on a new thread when a successful outcome is achieved.

Best regards, Tim Z

---snip--- CMake Error at C:/MinGW/msys/1.0/share/cmake-3.4/Modules/CMakeTestCCompiler.cmake:61 (message): The C compiler "C:/MinGW/msys/1.0/mingw32-64/bin/mpicc.exe" is not able to compile a simple test program.

It fails with the following output:

Change Dir: C:/gccbuild/OpenCoarrays2/opencoarrays/opencoarrays-build/CMakeFiles/CMakeTmp

Run Build Command:"C:/MinGW/msys/1.0/bin/make.exe" "cmTC_f52ca/fast"

/usr/bin/make -f CMakeFiles/cmTC_f52ca.dir/build.make CMakeFiles/cmTC_f52ca.dir/build

make[1]: Entering directory `/c/gccbuild/OpenCoarrays2/opencoarrays/opencoarrays-build/CMakeFiles/CMakeTmp'

Building C object CMakeFiles/cmTC_f52ca.dir/testCCompiler.c.obj

/C/MinGW/msys/1.0/mingw32-64/bin/mpicc.exe -o CMakeFiles/cmTC_f52ca.dir/testCCompiler.c.obj -c /C/gccbuild/OpenCoarrays2/opencoarrays/opencoarrays-build/CMakeFiles/CMakeTmp/testCCompiler.c

[SourcerersApprentice]

This bit might be a little more diagnostic:

Cannot create temporary file in c:\gccbuild\OpenCoarrays2\opencoarrays\opencoarrays-build\CMakeFiles\CMakeTmp\ none: No such file or directory

Linking C executable cmTC_9d95f.exe

/C/MinGW/msys/1.0/bin/cmake.exe -E remove -f CMakeFiles/cmTC_9d95f.dir/objects.a

/C/MinGW/msys/1.0/mingw32-64/bin/ar.exe cr CMakeFiles/cmTC_9d95f.dir/objects.a @CMakeFiles/cmTC_9d95f.dir/objects1.rsp

c:\MinGW\msys\1.0\mingw32-64\bin\ar.exe: CMakeFiles/cmTC_9d95f.dir/testCCompiler.c.obj: No such file or directory

make[1]: *\ [cmTC_9d95f.exe] Error 1

make[1]: Leaving directory `/c/gccbuild/OpenCoarrays2/opencoarrays/opencoarrays-build/CMakeFiles/CMakeTmp'

make: *\ [cmTC_9d95f/fast] Error 2

[zbeekman]

Hi Tim, Are you trying to install it using the install.sh script, or have you tried to build it manually with CMake?

If you're trying to build it manually with CMake, can you also include the contents of the FC and CC environment variables, the path to the build directory, the path to the source directory, and how you're invoking CMake on the command line?

Also, do you know which release you're currently using and the one that you were using before? Knowing the exact commits or tags will help track down if there was a regression and something changed.

[SourcerersApprentice]

Hi Izaak,

I have been using the install script and editing the cmake command inside to add the generator and debug output. I had been working with zips, but have since gotten with the program and pulled from the master branch. I got the first zip last Wednesday, and then again Saturday evening. Both zips are marked as 1.2.1. I am out tomorrow, but should be able to pin down the commit in question within a couple of days.

Tim

[zbeekman]

Sure, take your time. Just FYI, the master branch is more of the "development branch" right now, with some proposed features for the next major release. Currently the "release" branch (with OCA 1.x on it) is named branch-1.0.0. This 1.x branch is mostly the same as the tagged releases, although it does occasionally contain some bug fixes or minor new build system or install infrastructure improvements. Currently these two branches have diverged in small unintended ways, potentially introducing a few small bugs that we are aware of and working to rectify. More on this below.

In the next few days, we are going to be moving to a GitHub Flow git workflow. (If you want a more detailed explanation check out this video) We are doing this to enable us to keep the stable release branch(es) in sync with the development branch(es), so that bug fixes and build system improvements or bugs can be more easily applied to both branches. What this means is that the current stable and deployable branch (branch-1.0.0) will becomemasterand what is currently master will be renamed todevelopment. Throughout this process a number of relatively minor bug fixes we've found will be applied, as well as merging the branches together to re-establish a more recent common history, before forking off thedevelopment` branch.

The impact of this on the majority of users should be relatively minimal. However, if you have forked the github repo, or have made any local changes this will temporarily complicate your life. My advice if you have local uncommitted changes or local changes only committed to the local repository is to keep your working tree as is (and maybe even back it up somewhere) and after the workflow changes are in place, re-clone or fork the this central Github repository.

I'm planning to announce the upcoming changes in an email to the OCA google group.

[SourcerersApprentice]

I have discovered that the problem is with my mpicc, it works by hand, but doesn't like running from the script so much. In any event, I have verified to my satisfaction that this is not a problem with the OpenCoarrays distribution.

[rouson]

Thanks for the report and the update!

[rouson]

BTW, if this is a scenario that you think we can detect and work around in our installation script, please let me know. On a related note, does item 1 on the Known Issues list for release 1.2.1 accurately describe your situation?

[SourcerersApprentice]

I am not sure. The libraries and headers are installed in the normal spot for runtime files, they should not need anything special to point to where they are. In my case it might be a little tricky. I have Visual Studio '15 but mpicc/mpif90 both wrap gcc/gfortran. The install script correctly identifies the underlying compilers as gnu, but it lets cmake decide which generator to use. Cmake always goes for the Visual Studio build, even if I remove all VS compilers from the path. This is why I force the generator to be MSYS Makefiles. When mpicc cooperates, doing that and editing the cache variables MPI_C_INCLUDE_PATH MPI_C_LIBRARIES MPI_Fortran_INCLUDE_PATH and MPI_Fortran_LIBRARIES causes the evaluation to complete successfully, it generates makefiles and starts the build (which promptly breaks). When you detect that it is Windows and we are using gfortran, at some point you should be able to detect the MSMPI installation, and set up to use it. The headers and libraries mimic mpich, but it has no mpicc or mpif90. Although I want to create an mpicc and mpif90, I might try to get things going using gfortran directly. For Windows users, this might be the easiest way to provide support for gfortran distributions. I will keep you updated as I make progress.

[rouson]

@zbeekman, do you think using CMake's find_package capability would help with this? Do you think this should be submitted in a CMake bug report?

[zbeekman]

@rouson This smells like a CMake bug... I have a few questions to try to determine this, for @SourcerersApprentice... Right now the code is using the FindMPI CMake module, although somewhat inconsistently. It's possible that addressing #39 could sort this out, but I'm not sure at the moment.

@SourcerersApprentice:

I have no experience with MSYSmakefiles; are they the same as GNU Makefiles but with better handling of paths, etc. on MS Windows systems?

Does mingw or cygwin (I forget which you're using) also come with gmake?

And lastly, are you setting FC and CC to the appropriate MPI wrapper scripts before calling CMake?

(The best way to do this is probably export FC=$(which mpif90) and export CC=$(which mpicc) since the user environment might be slightly different than the CMake environment.