Error installing pFUnit on WSL(Ubuntu-20.04.5)

[rholden813]

Error installing pFUnit on WSL(Ubuntu-20.04.5)

[mathomp4]

@n-claes This is indeed a CMake 3.25 + pFUnit issue. In #399 I added a fix to "pin" CMake to 3.24.3 until CMake can respond to an issue I opened (see https://gitlab.kitware.com/cmake/cmake/-/issues/24203).

For now, you might want to do the same thing in your CI (and I guess locally, don't move to 3.25.0 if possible)

[tclune]

My apologies - it has been a busy week. I will take a deeper look over the weekend.

[tclune]

This is a weird error. pf_Exception is in the same directory as the failing file, and CMake should have detected the dependency and built it first.

The initial output you provided from the CMake command itself is much shorter than I would have expected. One guess is that you have installed some of these packages already and CMake is finding old/partial installations?

Could you start again from scratch and upload the full output from the CMake command and then the output from a serial build with make VERBOSE=1 This should provide a clearer picture of the first time things have gone off the rails.

[rholden813]

Thanks for getting back to me. Here is the result of cmake ..:

hk2314@L1070:~/pFUnit/build$ cmake ..
-- The Fortran compiler identification is GNU 11.1.0
-- The C compiler identification is GNU 11.1.0
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /usr/bin/gfortran-11 - skipped
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc-11 - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- *** Setting default install prefix to /home/hk2314/pFUnit/build/installed.
-- *** Override with -DCMAKE_INSTALL_PREFIX=<path>.
-- Setting build type to 'Debug' as none was specified.
-- Performing Test _LOGICAL_DEFAULT_KIND: SUCCESS (value=4)
-- Performing Test _INT_DEFAULT_KIND: SUCCESS (value=4)
-- Performing Test _ISO_INT8: SUCCESS (value=1)
-- Performing Test _ISO_INT16: SUCCESS (value=2)
-- Performing Test _ISO_INT32: SUCCESS (value=4)
-- Performing Test _ISO_INT64: SUCCESS (value=8)
-- Performing Test _REAL_DEFAULT_KIND: SUCCESS (value=4)
-- Performing Test _DOUBLE_DEFAULT_KIND: SUCCESS (value=8)
-- Performing Test _ISO_REAL32: SUCCESS (value=4)
-- Performing Test _REAL32_IEEE_SUPPORT: SUCCESS (value=T)
-- Performing Test _ISO_REAL64: SUCCESS (value=8)
-- Performing Test _REAL64_IEEE_SUPPORT: SUCCESS (value=T)
-- Performing Test _ISO_REAL128: SUCCESS (value=16)
-- Performing Test _REAL128_IEEE_SUPPORT: SUCCESS (value=T)
-- MPI enabled
-- OpenMP enabled
-- Found Python: /usr/bin/python3.8 (found version "3.8.10") found components: Interpreter
Submodule 'fArgParse' (https://github.com/Goddard-Fortran-Ecosystem/fArgParse.git) registered for path '../../../extern/fArgParse'
Cloning into '/home/hk2314/pFUnit/extern/fArgParse'...
Submodule path '../../../extern/fArgParse': checked out 'ff26eb0af81e751584ef9d35612be1ee36c484e5'
Submodule 'gFTL-shared' (https://github.com/Goddard-Fortran-Ecosystem/gFTL-shared.git) registered for path '../../../extern/fArgParse/extern/gFTL-shared'
Cloning into '/home/hk2314/pFUnit/extern/fArgParse/extern/gFTL-shared'...
Submodule path '../../../extern/fArgParse/extern/gFTL-shared': checked out '1c85cb233d195f3fb5eb51ceb362c3bf09f2d7c4'
Submodule 'gFTL' (https://github.com/Goddard-Fortran-Ecosystem/gFTL.git) registered for path '../../../extern/fArgParse/extern/gFTL-shared/extern/gFTL'
Cloning into '/home/hk2314/pFUnit/extern/fArgParse/extern/gFTL-shared/extern/gFTL'...
Submodule path '../../../extern/fArgParse/extern/gFTL-shared/extern/gFTL': checked out '2453d80836297395d9489783dc795d5a84ef5581'
-- Using submodule /home/hk2314/pFUnit/extern/fArgParse
-- Using submodule /home/hk2314/pFUnit/extern/fArgParse/extern/gFTL-shared
-- Performing Test _LOGICAL_DEFAULT_KIND: SUCCESS (value=4)
-- Performing Test _INT_DEFAULT_KIND: SUCCESS (value=4)
-- Performing Test _ISO_INT8: SUCCESS (value=1)
-- Performing Test _ISO_INT16: SUCCESS (value=2)
-- Performing Test _ISO_INT32: SUCCESS (value=4)
-- Performing Test _ISO_INT64: SUCCESS (value=8)
-- Performing Test _REAL_DEFAULT_KIND: SUCCESS (value=4)
-- Performing Test _DOUBLE_DEFAULT_KIND: SUCCESS (value=8)
-- Performing Test _ISO_REAL32: SUCCESS (value=4)
-- Performing Test _ISO_REAL64: SUCCESS (value=8)
-- Performing Test _ISO_REAL128: SUCCESS (value=16)
-- Using submodule /home/hk2314/pFUnit/extern/fArgParse/extern/gFTL-shared/extern/gFTL
-- Setting default install prefix to /home/hk2314/pFUnit/build/installed.
   Override with -DCMAKE_INSTALL_PREFIX=<path>.
-- cpp is /usr/bin/cpp
-- Using target 'FARGPARSE::fargparse'
-- Using target 'FARGPARSE::fargparse'
-- Configuring done
-- Generating done
-- Build files have been written to: /home/hk2314/pFUnit/build

After running make VERBOSE=1, the result is:

makeoutput.txt

[tclune]

Hmm. Well there is no error in that output. But it did not complete either. Even more odd, it looks like ExceptionVector.F90 built successfully, despite no record of having built Exception.F90 first.

The CMake step is also reporting that it is using FARGPARSE in a manner that suggests it is finding a previous installation, and I suspect this is related to your problems. E.g., you might have conflicting versions of things being built together. CMake is unfortunately too good at searching many places for installs.

For completeness, please let me know which version of CMake you are using. But I think the solution will be to find and purge earlier builds. The very latest CMake does have an option to restrict the search path, so if you cannot find/delete the existing packages, we can show you how to modify your CMake command line to force it.

[rholden813]

I suspect you are correct and CMake is using conflicting versions during the installation. The CMake version I am using is CMake-3.25.0-rc1. I'll have a look through and delete any old builds. Should I not be able to find them, if you could show me how to modify the CMake command, that would be great.

[tclune]

The CMake option (as of 3.23) is

cmake .. -DCMAKE_SYSTEM_IGNORE_PREFIX_PATH='/usr/share/cmake'

You'll need to add any system paths that CMake may be searching; unfortunately the list is not short, and it is OS dependent.

[rholden813]

When building a fresh docker image, the same error as before (pf_Exception) is still the result of the make install. There would be no previous installation of pFUnit anywhere to affect the installation. We switched to cmake 3.18.0 (the recommended version for the code we are using) and there are no errors and everything installs correctly. Maybe there is some incompatibility between cmake 3.25.0-rc1 and pFUnit?

[n-claes]

@tclune FYI we're encountering the exact same problem in our GitHub Actions CI pipeline, just noticed it now. We use gfortran-10 and gcc-10 together with cmake 3.25.0, the full log is here. As you can see it crashes with the same error as given above when building pFUnit, our tests run on Ubuntu.

We usually cache a successful pFUnit build, approximately a month ago our CI also did a clean build using cmake 3.24.2 and that did not raise issues (see here).

This indeed looks like an incompatibility between cmake 3.25.0 and pFUnit just as you suggested. In the meantime we'll temporarily limit the cmake version used by Actions, that should patch it for now.

[tclune]

@mathomp4 - just in case you are not following this ticket. Probably not a fun one to track down.

[tclune]

We are looking a bit more closely at the CI today. At first glance, the problem appears to be that CMake 3.25 is incorrectly processing the dependencies for files that have 2 Fortran modules in them. I usually just have 1 module per file, but for some special cases I do violate that rule.

If so, it should be possible to submit a reproducer to the CMake team. So far we don't see anything in the CMake release notes that would point a finger at anything. We know 3.22.1 works and 3.25 fails.