Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Error installing pFUnit on WSL(Ubuntu-20.04.5) #382

Open
rholden813 opened this issue Oct 18, 2022 · 11 comments
Open

Error installing pFUnit on WSL(Ubuntu-20.04.5) #382

rholden813 opened this issue Oct 18, 2022 · 11 comments

Comments

@rholden813
Copy link

Hi,
I am trying to install pFUnit on a WSL (Ubuntu-20.04.5) on my Windows laptop. I am using gfortran-11, gcc-11, g++-11 and cmake 3.25.0-rc1

I come across an error when using

make install

As per the instructions given to build and install pFUnit, I have used the following:

mkdir build
cd build
cmake ..

As a result of cmake .., the code returns:

-- 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

Using make tests, the code successfully completes all of the tests, as shown below:

Test project /home/hk2314/pFUnit/build/extern/fArgParse/extern/gFTL-shared/extern/gFTL
      Start  1: test_derived_logical
 1/18 Test  #1: test_derived_logical ..............   Passed    0.00 sec
      Start  2: test_derived_integer
 2/18 Test  #2: test_derived_integer ..............   Passed    0.00 sec
      Start  3: test_derived_integer32
 3/18 Test  #3: test_derived_integer32 ............   Passed    0.00 sec
      Start  4: test_derived_real
 4/18 Test  #4: test_derived_real .................   Passed    0.00 sec
      Start  5: test_derived_double
 5/18 Test  #5: test_derived_double ...............   Passed    0.00 sec
      Start  6: test_derived_complex
 6/18 Test  #6: test_derived_complex ..............   Passed    0.00 sec
      Start  7: test_derived_complex32
 7/18 Test  #7: test_derived_complex32 ............   Passed    0.00 sec
      Start  8: test_derived_double_complex
 8/18 Test  #8: test_derived_double_complex .......   Passed    0.00 sec
      Start  9: test_derived_fixed_string
 9/18 Test  #9: test_derived_fixed_string .........   Passed    0.00 sec
      Start 10: test_derived_deferred_string
10/18 Test #10: test_derived_deferred_string ......   Passed    0.00 sec
      Start 11: test_derived_unlimited
11/18 Test #11: test_derived_unlimited ............   Passed    0.00 sec
      Start 12: test_derived_integer_rank_1
12/18 Test #12: test_derived_integer_rank_1 .......   Passed    0.00 sec
      Start 13: test_derived_integer32_rank_2
13/18 Test #13: test_derived_integer32_rank_2 .....   Passed    0.00 sec
      Start 14: test_derived_integer_shape_1d
14/18 Test #14: test_derived_integer_shape_1d .....   Passed    0.00 sec
      Start 15: test_derived_integer32_shape_2d
15/18 Test #15: test_derived_integer32_shape_2d ...   Passed    0.00 sec
      Start 16: test_derived_Foo
16/18 Test #16: test_derived_Foo ..................   Passed    0.00 sec
      Start 17: test_derived_FooPoly
17/18 Test #17: test_derived_FooPoly ..............   Passed    0.00 sec
      Start 18: test_derived_kitchen_sink
18/18 Test #18: test_derived_kitchen_sink .........   Passed    0.00 sec

100% tests passed, 0 tests failed out of 18

Total Test time (real) =   0.04 sec
[100%] Built target tests

But, to complete the installation, using make install, I receive an error shortly after fargparse is built:

[ 21%] Built target fargparse
[ 21%] Building Fortran object src/funit/core/CMakeFiles/funit-core.dir/MatchObject.F90.o
[ 21%] Building Fortran object src/funit/core/CMakeFiles/funit-core.dir/AbstractPattern.F90.o
[ 21%] Building Fortran object src/funit/core/CMakeFiles/funit-core.dir/ExceptionVector.F90.o
/home/hk2314/pFUnit/src/funit/core/ExceptionVector.F90:2:8:

    2 |    use PF_Exception
      |        1
Fatal Error: Cannot open module file ‘pf_exception.mod’ for reading at (1): No such file or directory
compilation terminated.
make[2]: *** [src/funit/core/CMakeFiles/funit-core.dir/build.make:296: src/funit/core/CMakeFiles/funit-core.dir/ExceptionVector.F90.o] Error 1
make[1]: *** [CMakeFiles/Makefile2:761: src/funit/core/CMakeFiles/funit-core.dir/all] Error 2
make: *** [Makefile:166: all] Error 2

I was unable to find a similar error to this one online and I have spent many hours today, along with my colleagues to find a solution. Any help or guidance would be much appreciated.

@rholden813 rholden813 changed the title Error installing pFUnit on WSL(Ubunutu-20.04.5) Error installing pFUnit on WSL(Ubuntu-20.04.5) Oct 20, 2022
@tclune
Copy link
Member

tclune commented Oct 20, 2022

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

@tclune
Copy link
Member

tclune commented Oct 23, 2022

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
Copy link
Author

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
Copy link
Member

tclune commented Oct 24, 2022

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
Copy link
Author

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
Copy link
Member

tclune commented Oct 25, 2022

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
Copy link
Author

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
Copy link

n-claes commented Nov 24, 2022

@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
Copy link
Member

tclune commented Nov 28, 2022

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

@tclune
Copy link
Member

tclune commented Nov 28, 2022

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.

@mathomp4
Copy link
Collaborator

@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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants