#52 Intel 14.0.3 compilation error iso fortran env

[Albert Jornet]

Hi,

I manage to find another Intel compiler version 14.0.3 in anoher HPC. When compiling with my software it appears this errors.

mpif90 -o forcesoil.exe /ccc/work/cont003/dsm/p529jorn/modipsl/modeles/ORCHIDEE_MICT_UNITTEST/.config/obj/forcesoil.o -L/ccc/work/cont003/dsm/p529jorn/modipsl/modeles/ORCHIDEE_MICT_UNITTEST/lib -lfcmforcesoil -i4 -r8 -fpe0 -O0 -g -traceback -fp-stack-check -ftrapuv -check bounds -L/ccc/products/netcdf-4.2_hdf5_parallel/default/lib -lnetcdff -lnetcdf -lstdc++ -L/ccc/work/cont003/dsm/p529jorn/modipsl/modeles/ORCHIDEE_MICT_UNITTEST/../../lib -L/ccc/work/cont003/dsm/p529jorn/modipsl/lib/lib -lioipsl -lnetcdf -lpfunit
gmake: *** No rule to make target iso_fortran_env.o', needed bymain.o'. Stop.

[Albert Jornet]

I am not sure it is clear the problem is pfunit in this case.

In some cases I replaced:
use iso_fortran_env, only: OUTPUT_UNIT

1)
use, intrinsic :: iso_fortran_env, only: OUTPUT_UNIT

Or

2)
HASH define OUTPUT_UNIT 6

[Tom Clune]

This appears to be a problem in the dependency generator rather than the Fortran compiler. Can you check to see what version of gmake is buing used? We certainly routinely compile and use pfunit with intel 14, so I don't think we need a workaround for the USE statement.

I'll also add INTRINSIC to the USE statement if it does not break the currently supported compilers. (I suspect it will.) Otherwise, we'll include it in 4.0.

[Albert Jornet]

The version is: GNU Make 3.81

Thank you!

[Tom Clune]

Sorry - I was on travel last week and missed your response until cleaning up my inbox just now.

Gmake version is not the issue, as it is the same as on my system. We now suspect that either you have detritus from previous attempts and/or you are using an unsupported version of python. Python is used to generate the dependency list, and is clearly confused about the instrinsic module. Could you do a fresh clone and see if the problem goes away. If it does not, could you let us know which version of python you are using. We test with 2.7, but 3.x should also work. 2.6 definitely fails, but not with the manner you reported.

Also if you could confirm which version of pfunit you are using. Is it the development branch or the current release? I did recently add "intrinsic" to some of the USE commands for modules such as iso_fortran_env. But again, our regression tests are not tripping over the problem, so we're left wondering what is different on your system.

And of course, using the CMake build would sidestep most of these issues, but we are still interesting in ensuring that the usual gmake mechanism is robust for other users.

Thanks,

• Tom

[Michael L. Rilee]

Sorry for the trouble, and thanks for posting it here.

The compilation line above is for an application and is not occuring during the pFunit build. The dependency generator source/MakeDependenciesTmp is a dumb sed+grep script, which can be fooled, but it is not called during application compilation and linking. It is also not part of the installation.

We'd need to look at the makefile that generates the error above, as I believe the problem is occuring after pFunit build and installation.

MPI linking can be tricky, but first I'd want to verify the process that leads up to the makefile and the linking step shared above.

[Tom Clune]

Mike,

Thanks for being a more careful reader than myself. I'd incorrectly assumed that the problem was during the build of pfunit itself. This is indeed a problem with the dependency generator for the app itself. (Albert even indicated as much in his 2nd post, but I just did not read carefully.)

[Albert Jornet]

Hi,

You are completly right. This issue is not related at all with pFUnit. As you said, it belongs to the dependency generator app. It is now solved.

Thanks for your help!