Error when configuring using pFUnit
Closed this issue · 14 comments
Hello,
I have some trouble using/configuring pFUnit.
When cloning the repository and trying to configure pFUnit I get an error message that gFTL could not be found
(git 2.30.2, cmake 3.18.4, i have internet connection). Full error message see below.
As far as I understood, submodules should be downloaded during configuration, so as the error messge says This should not happen.
Note: there seems to be a global installation of gFTL on our system.
As it is also cmake related:
Our administrator had version 4.1.9 installed (or created a package and then installed).
However, when trying to configure a project using this version, cmake gives an error message from /usr/share/cmake/pfunit/PFUNITConfig.cmake:15, that include could not find load file: /usr/share/cmake/fargparse/PFUNIT.cmake (of course there is no PFUNIT.cmake in fargparsebut there is one inpfunit`).
With kind regards
nuclearfusionreactor
-- The Fortran compiler identification is GNU 11.2.0
-- The C compiler identification is GNU 11.2.0
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /censored/opt/gcc/11.2.0/arch-amd64/bin/gfortran - skipped
-- Checking whether /censored/opt/gcc/11.2.0/arch-amd64/bin/gfortran supports Fortran 90
-- Checking whether /censored/opt/gcc/11.2.0/arch-amd64/bin/gfortran supports Fortran 90 - yes
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /censored/opt/gcc/11.2.0/arch-amd64/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- *** Setting default install prefix to /censored/Programs/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.9 (found version "3.9.2") found components: Interpreter
-- Using package 'FARGPARSE'
CMake Error at src/funit/CMakeLists.txt:30 (message):
Could not find gFTL. This should not happen.
Call Stack (most recent call first):
src/funit/core/CMakeLists.txt:89 (funit_target_link_pfunit)
-- Configuring incomplete, errors occurred!
Hmm. Definitely seems to be some issue with CMake "sort of" finding things but not really.
Could you send the cmake command you used to generate the output above? Also did you clone pFUnit with --recursive? Just want to be sure I know how pFUnit should be finding gFTL. (Unfortunately, different users want different mechanisms for this, so the CMake logic has become complex/fragile.)
My next thought is to ensure that CMake does not try to use anything global by explicitly specifying CMAKE_PREFIX_PATH and CMAKE_INSTALL_PREFIX on the command line. If this works then we just need to understand why cmake is doing the other thing with the original command.
The output above was produced with cmake .. inside of the Build-directory.
pFUnit was not cloned with --recursive
I made a try with
cmake -DCMAKE_PREFIX_PATH=/local/path/Programs/pFUnit/ -DCMAKE_INSTALL_PREFIX=/local/path/pFUnit/Build/installed/ ..
but I get still the same error message. (The same if I point CMAKE_PREFIX_PATH to the Build subdirectory).
with kind regards
nuclearfusionreactor
Can you set the CMAKE_PREFIX_PATH also to /local/path/pFUnit/Build/installed/? I want to rule out other things being in the path you specified interfering. (And be sure to wipe out any detritus in the build dir from the first attempt, of course.)
Using cmake -DCMAKE_PREFIX_PATH=/local/path/Programs/pFUnit/Build/installed/ -DCMAKE_INSTALL_PREFIX=/local/path/Programs/pFUnit/Build/installed/ .. leads to the same error.
with kind regards
nuclearfusionreactor
Hmm. My next suggestion is to start from either a full recursive clone from the repo or the full tar file and repeat the previous step. (Note that the default GitHub tar ball does not include submodules, but a script adds a full tar ball in the "Assets" list for each recent release. E.g., the most recent release has pFUnit-v4.4.2.tar.)
A new clone with --recursive does lead to the same message.
Using pFUnit-v4.4.2.tar also leads to the same message, as does pFUnit-v4.2.7.tar. pFUnit-v4.1.14.tar on the other hand works with cmake .. and then make. I have not yet tried to use this version with configuring/compiling a project.
Edit: Version pFUnit-v4.2.0.tar also fails. v4.1.15 does not have a .tar file.
Edit2: 4.1.4 finds gftl in /usr/share/cmake/gftl_shared/, 4.2.0 finds fargparse in /usr/share/cmake/fargparse/ but neither /usr/share/cmake/gftl_shared/GFTL_SHAREDConfig.cmake nor /usr/share/cmake/gftl/GFTLConfig.cmake.
Hmm. These latest facts at least provide some sort of clue as to what is causing a problem. I can at least take a look at the changes in the subsequent versions to see what might be causing issues for cmake.
But since 4.2.7 is building and installing on several systems on my end, there would still seem to be some system dependency that is playing a role. Clearly it is not the compiler, and GFortran 11.2 is fine in any event. The CMake you are using is a bit older than what I have on my system, but we've not really been pushing the envelope on CMake issues. I'm going to check with a colleague that's a bit more experienced with CMake to see if they have any theories here.
@nuclearfusionreactor We have a thought. My current guess is the gftl, gftl_shared, and fargparse in your /usr/share might be too old for current pFUnit and maybe that is causing the issue. (We often fix bugs to GFE libraries which means they need to all be "of the right vintage").
One course is to update all the other GFE libraries on your system to the latest version, but we have a test you could do before that. So, could you clone pFUnit 4.4.2 again and then do:
cmake .. -DCMAKE_SYSTEM_IGNORE_PREFIX_PATH='/usr/share/cmake'
Our thought is CMake is really good at finding things on a system and maybe it's finding the old libraries and GFE isn't testing to make sure they are a new enough version. But if you tell CMake to ignore that path, it might then try using the internal versions from pFUnit.
Note, you might need to try:
-DCMAKE_SYSTEM_IGNORE_PREFIX_PATH='/usr/share'
instead or as well. Not sure exactly what's right, but I figure try the longest path first then slowly remove.
I made a clone with --recursive of the repository and tried it with
cmake .. -DCMAKE_SYSTEM_IGNORE_PREFIX_PATH='/usr/share/cmake'
Also with '/usr/share/', and with different order of .. and -D. I also tried to explicitly remove the gftl folders, but neither did work.
However I think this is because the -DCMAKE_SYSTEM_IGNORE_PREFIX_PATH did not do what was expected. I think so because output of cmake with --debug-find says that fargparse is still found in /usr/share/cmake/fargparse/FARGPARSEConfig.cmake, which should not be the case.
with kind regards
nuclearfusionreactor
Ah. Looking at its help page it was introduced in CMake 3.23 and you are older than that. It worked for me because we have that version.
Well, if it's easy for you, you can try updating CMake. Otherwise, I'll look around to see if there is an older way of doing what that setting does.
Also, if you have a chance, can you go to /usr/share/cmake and see if you can determine what versions of GFE libraries you have? Should be visible in the Config-version.cmake files.
There is no GFE library in that folder.
If you meant GFTL then it is 1.2.7, for GFTL_SHARED it is 1.0.7
There is no GFE library in that folder. If you meant GFTL then it is 1.2.7, for GFTL_SHARED it is 1.0.7
Ah. Sorry. GFE is the "Goddard Fortran Ecosystem" which gFTL, gFTL-shared, fArgParse, etc. are part of. I just think of it in those terms. It's also an "omnibus" repo that @tclune maintains here: https://github.com/Goddard-Fortran-Ecosystem/GFE which has consistent versions of all libraries.
And those are quite old. My guess is you probably need to update them. For example in the latest GFE release, we have:
- gFTL v1.8.1
- gFTL-shared v1.5.0
- pFlogger v1.9.1
- fArgParse v1.3.0
- yaFyaml v1.0.4
- pFUnit v4.4.1
If you can't update CMake to ignore /usr/share/cmake then your best bet might be to update any GFE libraries you have installed to the latest version, and then pFUnit will probably be happy.
@nuclearfusionreactor Were you ever able to successfully build? Apologies for losing track of this ticket - my hope was the last response from @mathomp4 above would suffice.
Sorry for the late reply, this was a side project and thus not of high priority.
As I did the tests already a while ago I am not sure I can remember all of it correctly.
Bu I hope I remember the most important point correctly:
CMAKE was updated and I think I could get it to ignore /usr/share/cmake (I can not reproduce this now).
But this did not help, neither for the 'normal' checkout nor for the recursive.
My stand at the moment is, that the problem is due to an issue with the local installation, and thus there is not much that you can do about this.
I thus decided to close this now as done.
With kind regards,
nuclearfusionreactor