1.9.3 tests fail on FreeBSD

[mexas]

Please help

http://eis.bris.ac.uk/~mexas/log/opencoarrays193-freebsd.log

1.9.1 passed all tests.
I haven't tried 1.9.2.

[vehre]

This happens to me, when the mpi-library can not be found on the LD_LIBRARY_PATH. Build/testscript deficiency? @zbeekman

Btw, you are using clang for the c-compiler and gfortran for the fortran parts. I think this is unsupported.

[mexas]

Wrong MPI library is used:

-- Found MPI_C: /usr/local/mpi/openmpi/lib/libmpi.so (found version "3.0") 
-- Found MPI_Fortran: /usr/local/mpi/openmpi/lib/libmpi_usempi.so (found version "3.0") 

It should be using MPICH.

I need to find where this is coming from.
The port gives the user a choice of mpich, openmpi and openmpi2.
mpich is the default, which is what I'm testing now.

[mexas]

I think

find_package( MPI )

is to blame.
I don't know which MPI it chooses when multiple MPI libraries
are installed on the system. For some reason it chooses openmpi.
And of course, it doesn't know of the user's chosen MPI option,
when building opencoarrays.

[mexas]

yes, disabling find_package(MPI) helps:

-- Found MPI_C: /usr/local/lib/libmpi.so (found version "3.1") 
-- Found MPI_Fortran: /usr/local/lib/libmpifort.so (found version "3.1") 

100% tests pass:

http://eis.bris.ac.uk/~mexas/log/opencoarrays193-freebsd-mpich.log

[mexas]

However, now I cannot build with openmpi...
I need to find out how FreeBSD port options
are passed to opencoarrays cmake build

[vehre]

Well, usually it is the other way around. You can supply to find_package(MPI) which mpi-installation to choose. See for example here: https://cmake.org/cmake/help/v3.10/module/FindMPI.html
But I don't know how to pass this to the coarray installer. May be --help can give a clue.

[zbeekman]

Building packages for distribution should be done by invoking cmake directly, which I suspect is what @mexas is doing. I haven’t had a chance to look at the logs and the issue template was not followed. Recent versions of CMake have substantial changes to FindMPI. (One of the reasons why we ask for the CMake version in the issue template)

I’ll try to look at the attached logs; hopefully they contain all the required info to debug this issue.

[mexas]

# cmake --version
cmake version 3.10.1

[zbeekman]

@mexas your log does not show how CMake is being invoked during the build. I need this information to determine why it is picking up the wrong MPI.

EDIT: An additional note: To me CMake 3.10 and the recent FindMPI changes seem likely to be the culprit for this problem. Another issues was reported recently using the installer script and I suspect the semantics/behavior of how the MPI identification is done in 3.10 is the source of these issues.

[zbeekman]

Btw, you are using clang for the c-compiler and gfortran for the fortran parts. I think this is unsupported.

@vehre I would categorize clang use as unofficially supported at this point. By default on macOS when using Homebrew clang is used as well, and I have not seen any ill effects. Perhaps we should be officially supporting it. As soon as I can add some CI tests with clang we can change it to be officially supported.

[mexas]

@zbeekman if I invoke make with "-dx", I get this:

===>  Performing out-of-source build
/bin/mkdir -p /usr/ports/lang/opencoarrays/work/.build
+ cd /usr/ports/lang/opencoarrays/work/.build
+ /usr/bin/env 'F77=gfortran6' 'FC=gfortran6' 'FFLAGS=-O -Wl,-rpath=/usr/local/lib/gcc6' 'FCFLAGS=-W
l,-rpath=/usr/local/lib/gcc6' 'XDG_DATA_HOME=/usr/ports/lang/opencoarrays/work' 'XDG_CONFIG_HOME=/us
r/ports/lang/opencoarrays/work' 'HOME=/usr/ports/lang/opencoarrays/work' 'PATH=/usr/ports/lang/openc
oarrays/work/.bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin:/root/bin' 'SHELL=/bi
n/sh' 'CONFIG_SHELL=/bin/sh' /usr/local/bin/cmake '-DCMAKE_C_COMPILER:STRING=cc' '-DCMAKE_CXX_COMPIL
ER:STRING=c++' '-DCMAKE_C_FLAGS:STRING=-O2 -pipe  -fstack-protector -fno-strict-aliasing' '-DCMAKE_C
_FLAGS_DEBUG:STRING=-O2 -pipe  -fstack-protector -fno-strict-aliasing' '-DCMAKE_C_FLAGS_RELEASE:STRI
NG=-O2 -pipe  -fstack-protector -fno-strict-aliasing' '-DCMAKE_CXX_FLAGS:STRING=-O2 -pipe -fstack-pr
otector -fno-strict-aliasing ' '-DCMAKE_CXX_FLAGS_DEBUG:STRING=-O2 -pipe -fstack-protector -fno-stri
ct-aliasing ' '-DCMAKE_CXX_FLAGS_RELEASE:STRING=-O2 -pipe -fstack-protector -fno-strict-aliasing ' '
-DCMAKE_EXE_LINKER_FLAGS:STRING= -Wl,-rpath=/usr/local/lib/gcc6  -L/usr/local/lib/gcc6 -B/usr/local/
bin -fstack-protector' '-DCMAKE_MODULE_LINKER_FLAGS:STRING= -Wl,-rpath=/usr/local/lib/gcc6  -L/usr/l
ocal/lib/gcc6 -B/usr/local/bin -fstack-protector' '-DCMAKE_SHARED_LINKER_FLAGS:STRING= -Wl,-rpath=/u
sr/local/lib/gcc6  -L/usr/local/lib/gcc6 -B/usr/local/bin -fstack-protector' '-DCMAKE_INSTALL_PREFIX
:PATH=/usr/local' '-DCMAKE_BUILD_TYPE:STRING=Release' '-DTHREADS_HAVE_PTHREAD_ARG:BOOL=YES' '-DCMAKE
_INSTALL_RPATH_USE_LINK_PATH=YES' '-DCMAKE_VERBOSE_MAKEFILE:BOOL=ON' /usr/ports/lang/opencoarrays/wo
rk/OpenCoarrays-1.9.3
-- The C compiler identification is Clang 4.0.0

Is this the info you were looking for?

The full log:
http://eis.bris.ac.uk/~mexas/log/1.log

[zbeekman]

@mexas Yes this looks like it has all the info I was looking for.

A few follow on questions:

1. Is the only patching that's occurring truncating the CMAKE_Fortran_COMPILER_VERSION to the major version for the mod_dir_tail?
   (This is a change that might be worthwhile to consider upstreaming into our build system. My only concern is that module files between minor versions may have incompatibilities, maybe @vehre knows if GFortran makes any guarantees about this.)

2. When you say "disabling find_package(MPI) helps" presumably you are deleting it in the top level CMakeLists.txt only? It is called again in src/mpi/CMakeLists.txt but the call in the top level CMakeLists.txt is mostly a work around/accomodation for the easy installation script with the deficiencies in the older FindMPI.cmake.

If the answer to Q2 is "yes" then this helps greatly, because we now know that the call in src/mpi/CMakeLists.txt is being handled correctly but the top level one is not.

[mexas]

@zbeekman yes to both

Q1: Well, disabling find_packages(MPI) is the second patch. In the build log I show you it wasn't applied.

RE: compiler_version: Using the full gcc version triplet breaks the FreeBSD pkg system, because they use only the major version, i.e. there is an env var defined for this.

Q2: yes, only the top level CMakeLists.txt. However, now that you ask, I see that for 1.9.1 it was different. For 1.9.1 the patch was:

@${REINPLACE_CMD} '/mod_install/s/$${CMAKE_Fortran_COMPILER_VERSION}/${_GCC_VER}/' \
               ${WRKSRC}/src/mpi/CMakeLists.txt

For 1.9.3 I went for:

@${REINPLACE_CMD} '/mod_dir_tail/s/$${CMAKE_Fortran_COMPILER_VERSION}/${_GCC_VER}/' \
               ${WRKSRC}/CMakeLists.txt

Maybe that's why it's broken between 1.9.1 and 1.9.3...

[mexas]

sorry, typed too fast. I now see that what I wrote is confusing.

disabling find_packages(MPI) was never in 1.9.1. This is a new patch for 1.9.3.

It's the patch that truncated the GCC version to the major version, that is different between 1.9.1 and 1.9.3. In 1.9.1 I applied it to src/mpi/CMakeLists.txt and in 1.9.3 I apply it to the top level CMakeLists.txt.