CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2024-03-05T08:12:36-05:00https://gitlab.kitware.com/cmake/cmake/-/issues/25724Fortran: Unrecognized flag '-F' provided to gfortran on macOS when linking to...2024-03-05T08:12:36-05:00Willem DeconinckFortran: Unrecognized flag '-F' provided to gfortran on macOS when linking to a FrameworkArchitecture: macOS 13.5 (Ventura) with gfortran [GNU Fortran (Homebrew GCC 13.2.0) 13.2.0]
Problem description:
--------------------
I am trying to build a Fortran target linking with LAPACK:
```
target_link_libraries(MyFortranTarget P...Architecture: macOS 13.5 (Ventura) with gfortran [GNU Fortran (Homebrew GCC 13.2.0) 13.2.0]
Problem description:
--------------------
I am trying to build a Fortran target linking with LAPACK:
```
target_link_libraries(MyFortranTarget PRIVATE ${LAPACK_LIBRARIES})
```
The variable `LAPACK_LIBRARIES` is set via `find_package(LAPACK)` and reads:
```
/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/System/Library/Frameworks/Accelerate.framework -lm -ldl
```
Since MR https://gitlab.kitware.com/cmake/cmake/-/merge_requests/7121 this now adds following flag to the compilation of each Fortran file:
```
-F/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/System/Library/Frameworks
```
This flag is not supported with gfortran resulting in a warning emitted for each compiled file:
```
f951: Warning: command-line option '-F/Library/Developer/CommandLineTools/SDKs/MacOSX13.3.sdk/System/Library/Frameworks' is valid for C/C++/ObjC/ObjC++ but not for Fortran
```
I think it is very unlikely that Fortran source code could make use of any header includes from any available Framework.https://gitlab.kitware.com/cmake/cmake/-/issues/25380Makefiles: Fortran module dependency named via preprocessor DEFINE variable2023-11-07T01:53:41-05:00Jeff HoleMakefiles: Fortran module dependency named via preprocessor DEFINE variableHere is a simple example to show the problem. This is possibly related to #16853.
I am using CMake 3.20.2, GCC toolchain 10 (gfortran 10.3.1), on Rocky Linux 8.8. GNU Make version is 4.2.1.
main.f90:
```fortran
1 #define MODULE_NAME ...Here is a simple example to show the problem. This is possibly related to #16853.
I am using CMake 3.20.2, GCC toolchain 10 (gfortran 10.3.1), on Rocky Linux 8.8. GNU Make version is 4.2.1.
main.f90:
```fortran
1 #define MODULE_NAME MyConstants
2
3 module MODULE_NAME
4 implicit none
5 real(8) :: pi = 3.1415926535897932d0
6 end module
7
8 program main
9 use MODULE_NAME
10 implicit none
11 print *, 'pi = ', pi
12 end program
```
CMakeLists.txt:
```cmake
1 project(test LANGUAGES Fortran)
2 set(CMAKE_Fortran_PREPROCESS YES)
3 add_executable(main.out main.f90)
```
I have both these files in a directory alone, and run:
```bash
cmake -B build
cd build
make
```
And I get the following output:
```bash
Scanning dependencies of target main.out
[ 50%] Building Fortran object CMakeFiles/main.out.dir/main.f90.o
Error copying Fortran module "module_name.mod". Tried "MODULE_NAME.mod" and "module_name.mod".
make[2]: *** [CMakeFiles/main.out.dir/depend.make:7: CMakeFiles/main.out.dir/module_name.mod.stamp] Error 1
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/main.out.dir/all] Error 2
make: *** [Makefile:91: all] Error 2
```
It appears when CMake determines module dependencies, it doesn't preprocess the file (at least not fully, as suggested in #16853), and it thinks the module name is "MODULE_NAME" instead of "MyConstants".https://gitlab.kitware.com/cmake/cmake/-/issues/25006Feature Request: fortran language standard support2024-02-03T09:35:54-05:00wolfman21Feature Request: fortran language standard supportHello,
GFortran supports passing the Fortran standard via `-std=[f95|f2003|f2008|...]`
https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html#index-std_003dstd-option
It appears that Fortran isn't supported as a language ...Hello,
GFortran supports passing the Fortran standard via `-std=[f95|f2003|f2008|...]`
https://gcc.gnu.org/onlinedocs/gfortran/Fortran-Dialect-Options.html#index-std_003dstd-option
It appears that Fortran isn't supported as a language in CMAKE_<LANG>_STANDARD:
https://cmake.org/cmake/help/latest/variable/CMAKE_LANG_STANDARD.html#variable:CMAKE_%3CLANG%3E_STANDARD
Could this be added?
Thank you.
----
For reference, a cmake discourse issue on this is here: https://discourse.cmake.org/t/setting-fortran-language-standard/8351https://gitlab.kitware.com/cmake/cmake/-/issues/24846Feature Request: Implement VS_DEBUGGER_properties for Intel fortran targets2023-04-24T07:33:53-04:00Mark FinnisFeature Request: Implement VS_DEBUGGER_properties for Intel fortran targetsThe need for these properties in C++ targets is recognized and there is a similar need in Intel fortran targets. Setting these at generation time through CMake is far more convenient than manually adding them in Visual Studio after gener...The need for these properties in C++ targets is recognized and there is a similar need in Intel fortran targets. Setting these at generation time through CMake is far more convenient than manually adding them in Visual Studio after generation.
(see [https://discourse.cmake.org/t/feature-request-implement-vs-debugger-properties-for-intel-fortran-targets/7798](https://discourse.cmake.org/t/feature-request-implement-vs-debugger-properties-for-intel-fortran-targets/7798))https://gitlab.kitware.com/cmake/cmake/-/issues/24292IntelLLVM: Error linking with Intel Fortran 2023 for Windows2023-07-12T08:44:21-04:00Matthew RothIntelLLVM: Error linking with Intel Fortran 2023 for WindowsVersions of software I am using.
CMake version 3.25.1
Intel Fortran compiler version 2023.0
Microsoft Visual Studio version 2017
I am trying to build Lapack for windows by using their provided CMake build files (v3.10.1 of Lapack though...Versions of software I am using.
CMake version 3.25.1
Intel Fortran compiler version 2023.0
Microsoft Visual Studio version 2017
I am trying to build Lapack for windows by using their provided CMake build files (v3.10.1 of Lapack though I don't think it's a Lapack problem). It makes calls to the FortranCInterface functions, specifically FortranCInterface_VERIFY, which fails with the error message
```
C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin\ifx.exe CMakeFiles\VerifyFortran.dir\VerifyFortran.f.obj -fuse-ld=llvm-lib -o VerifyFortran.lib /machine:x64
ifx: error #10037: could not find 'C:\PROGRA~2\Intel\oneAPI\compiler\latest\windows\bin-llvm\llvm-lib'
```
It looks as if `ifx` is trying to use `llvm-lib`, which seems to be an LLVM linker, to link the test library and failing, and sure enough that linker is not present at the path specified or in my install at all, even after I tried repairing it. The line responsible for this argument in CMake is [line 60 in Windows-IntelLLVM.cmake](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Modules/Platform/Windows-IntelLLVM.cmake#L60) which attempts to use `llvm-lib` for any compiler besides fortran versions less than 2022.1. I couldn't find too much info on it besides a small amount on [LLVM's website](https://llvm.org/docs/CommandGuide/llvm-lib.html). Switching to `fuse-ld=lld` which is in the folder referenced gets closer but still fails:
```
lld-link: error: undefined symbol: MAIN__
>>> referenced by libifcoremd.lib(for_main.obj):(main)
```
Omitting the `-fuse-ld` argument altogether does the same, maybe I need to provide a different linker.
It could be possible Intel forgot to ship this `llvm-lib` tool, or did some other update, as I am assuming it existed in the 2022.1 version at least. If so, maybe Windows-IntelLLVM.cmake should be altered to cope with this change for this version?https://gitlab.kitware.com/cmake/cmake/-/issues/24048IntelLLVM: Default Fortran flags on Windows hard-code /fpp2022-11-03T10:11:25-04:00尚嘉宣IntelLLVM: Default Fortran flags on Windows hard-code /fppCame across a somewhat old piece of fortran code that cannot compile with `/fpp` specified in `ifort`:
https://gitlab.cern.ch/garfield/garfieldpp/-/blob/master/Magboltz/magboltz.f
With `/fpp` will output:
```
#error: comment doesn't ...Came across a somewhat old piece of fortran code that cannot compile with `/fpp` specified in `ifort`:
https://gitlab.cern.ch/garfield/garfieldpp/-/blob/master/Magboltz/magboltz.f
With `/fpp` will output:
```
#error: comment doesn't end to the end of file.
```
Cmake always generates `/fpp` in `CMAKE_Fortran_FLAGS` when compiling with ifort (even with `CMAKE_Fortran_PREPROCESS` set to `OFF`), and had to edit cmake cache to remove this.https://gitlab.kitware.com/cmake/cmake/-/issues/24005Fortran w/ OpenMP: Conditional Compilation Sentinel ignored2022-09-29T04:10:36-04:00Bram MetschFortran w/ OpenMP: Conditional Compilation Sentinel ignoredThe Fortran lexer currently ignores everything following a single `!` character.
However, the sentinel `!$` (in the case of fixed form, also `*$` and `c$`) does not mark a comment, but a line that should only be compiled if OpenMP is e...The Fortran lexer currently ignores everything following a single `!` character.
However, the sentinel `!$` (in the case of fixed form, also `*$` and `c$`) does not mark a comment, but a line that should only be compiled if OpenMP is enabled, see Section 3.3 of the OpenMP Standard,https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5-2.pdf.
Hence it can happen that a conditional module usage of the form
```
!$ use some_module
```
is ignored while scanning the dependencies, and can break the build.https://gitlab.kitware.com/cmake/cmake/-/issues/23520FindBLAS with Intel MKL on Windows2024-03-15T23:14:16-04:00Oliver KrekFindBLAS with Intel MKL on WindowsHi everyone,
I am trying to build/install[ Suitesparse](https://github.com/DrTimothyAldenDavis/SuiteSparse) on Windows as I need the embedded umfpack for a project that runs in fortran. I am using Visual Studio 2022 CE and the Intel fot...Hi everyone,
I am trying to build/install[ Suitesparse](https://github.com/DrTimothyAldenDavis/SuiteSparse) on Windows as I need the embedded umfpack for a project that runs in fortran. I am using Visual Studio 2022 CE and the Intel fotran compiler from the oneAPI. When I want to build the suitesparse source files using Cmake I always get the following error
```
CMake Error at C:/Program Files/CMake/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:230 (message):
Could NOT find BLAS (missing: BLAS_LIBRARIES)
Call Stack (most recent call first):
C:/Program Files/CMake/share/cmake-3.23/Modules/FindPackageHandleStandardArgs.cmake:594 (_FPHSA_FAILURE_MESSAGE)
C:/Program Files/CMake/share/cmake-3.23/Modules/FindBLAS.cmake:1337 (find_package_handle_standard_args)
CMakeLists.txt:117 (find_package)
```
It seems that Cmake is unable to locate the BLAS and LAPACK libraries of Intel MKL. I have tried several things already, like directly adding the mkl directory to the search path or defining the MKLROOT variable but nothing works. It seems that it is not an issue with CMakeLists[CMakeLists.txt](/uploads/af646c3b6eb96d81f1da3799d2c905da/CMakeLists.txt) as I tried it with a simple sample project but I get the same error.
```cmake
project(test)
cmake_minimum_required(VERSION 3.14 FATAL_ERROR)
enable_language(Fortran)
set(BLA_VENDOR Intel10_64lp)
find_package(BLAS REQUIRED)
```
I am really lost at this point as I am relatively new to Cmake etc. Help would be greatly appreciated.
Here the error logs/outputs [CMakeError.log](/uploads/31b3839876666c06763d16ec620b84d6/CMakeError.log)
[CMakeOutput.log](/uploads/5539e8d6a0ff5f30c600d7dd73ee61cd/CMakeOutput.log)
Thanks alreadyhttps://gitlab.kitware.com/cmake/cmake/-/issues/23366IPO,Intel,Fortran: Static libraries generated with no longer link correctly.2022-03-30T10:43:29-04:00Andy VincentIPO,Intel,Fortran: Static libraries generated with no longer link correctly.- CMake: 3.22.3
- Ninja: 1.10.2
- Intel: 18.0.5.274
- MSVC: 2017
This is an issue I've just experienced whilst upgrading our CMake from 3.14.4 to 3.22.3, when using Ninja (unsure if this affects any other generators).
We have some proj...- CMake: 3.22.3
- Ninja: 1.10.2
- Intel: 18.0.5.274
- MSVC: 2017
This is an issue I've just experienced whilst upgrading our CMake from 3.14.4 to 3.22.3, when using Ninja (unsure if this affects any other generators).
We have some projects where various static libraries are compiled (with IPO turned on), which are then linked to a shared library containing other static-libraries or C/CXX code.
It seems that in CMake 3.21.1, a change was made, and the 'lib' tool from MSVC is used, instead of Intel's 'xilib' tool when linking the static library, which then causes an issue when linking the final shared library.
I've attached a small reproducer, which contains:
* A Fortran generated static library (with 1 subroutine)
* A shared library that contains C code, which links to the above. This also contains an export '.def' file, to export the Fortran subroutine.
The CMakeLists.txt encapsulates all of this. When the build occurs, the following is produced:
```
[1/2] Linking Fortran static library fortran_code.lib
f_code.f.obj : warning LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library
[2/2] Linking C shared library test_lib.dll
FAILED: test_lib.dll test_lib.lib
cmd.exe /C "cd . && C:\BuildTools\cmake-3.22.3-windows-x86_64\bin\cmake.exe -E vs_link_dll --intdir=CMakeFiles\test_lib.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100177~1.0\x64\mt.exe --manifests -- C:\PROGRA~2\MICROS~2\2017\PROFES~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\link.exe /nologo CMakeFiles\test_lib.dir\c_code.c.obj /out:test_lib.dll /implib:test_lib.lib /pdb:test_lib.pdb /dll /version:0.0 /machine:x64 /debug /INCREMENTAL /DEF:C:\workspaces\temp\fortran-static-lib-bug\exports.def /DEF:..\exports.def fortran_code.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."
LINK Pass 1: command "C:\PROGRA~2\MICROS~2\2017\PROFES~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\link.exe /nologo CMakeFiles\test_lib.dir\c_code.c.obj /out:test_lib.dll /implib:test_lib.lib /pdb:test_lib.pdb /dll /version:0.0 /machine:x64 /debug /INCREMENTAL /DEF:C:\workspaces\temp\fortran-static-lib-bug\exports.def /DEF:..\exports.def fortran_code.lib kernel32.lib user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:CMakeFiles\test_lib.dir/intermediate.manifest CMakeFiles\test_lib.dir/manifest.res" failed (exit code 1120) with the following output:
exports.def : error LNK2001: unresolved external symbol vmake_name_
test_lib.lib : fatal error LNK1120: 1 unresolved externals
ninja: build stopped: subcommand failed.
```
I've left some commented code in the CMakeLists.txt, which re-enables the use of 'xilib' via the 'CMAKE_Fortran_CREATE_STATIC_LIBRARY' variable. When this is uncommented, everything works as expected (and you can use 'dumpbin /EXPORTS' to see that all the functions are exported as expected).
[fortran-static-lib-bug.zip](/uploads/869207d9b2b252edd91e368635ddc314/fortran-static-lib-bug.zip)https://gitlab.kitware.com/cmake/cmake/-/issues/22922Fortran: Intel ifx vs. gfortran rebuild capabilities2021-11-22T12:48:07-05:00Tyler ReddyFortran: Intel ifx vs. gfortran rebuild capabilitiesI did a quick search of issues and couldn't find anything with "Intel fortran rebuild," but I'm guessing the CMake devs know why this happens, and I do apologize if this is well explained in another issue.
If I do nothing other than `to...I did a quick search of issues and couldn't find anything with "Intel fortran rebuild," but I'm guessing the CMake devs know why this happens, and I do apologize if this is well explained in another issue.
If I do nothing other than `touch` a Fortran source file that has an interface defined and produces a module file, CMake does an excellent job of minimizing what it builds--basically just relinking what it has to in mere seconds, which is wonderful. This is true when using `gfortran` with both `Unix Makefiles` and `Ninja`--great!
Unfortunately, the team I support likes to use compilers like Intel and XL. I know this efficient rebuild behavior is not preserved when using `Intel` compilers--it appears the assumption is made that the interface has changed regardless of the true nature of the change to the Fortran source file, and a massive recompile of the source can follow.
My question is this: how much work would it be to add support for this efficiency behavior for another compiler like Intel? Is it a super-complicated parsing of binary module files, or is the task reasonably doable with tests in place for `gfortran` that we could adapt/parametrize for use with other compilers too?https://gitlab.kitware.com/cmake/cmake/-/issues/22898Fortran: Improve default Fortran_MODULE_DIRECTORY2021-11-13T21:27:41-05:00Lionel GUEZFortran: Improve default Fortran_MODULE_DIRECTORYHello. The default location for Fortran compiler-generated .mod files
is ${CMAKE_CURRENT_BINARY_DIR}. I think this is really a problem.
Suppose a given source file belongs to several targets, in the same source directory. Then CMake wil...Hello. The default location for Fortran compiler-generated .mod files
is ${CMAKE_CURRENT_BINARY_DIR}. I think this is really a problem.
Suppose a given source file belongs to several targets, in the same source directory. Then CMake will re-compile this source file for each target it belongs to. But it will each time generate the corresponding .mod files in the same directory. This can crash the compilation if the compilation is parallel. It can even produce silent nasty errors if the source file is compiled with different compiler options or preprocessor definitions for different targets.
Note the same problem does not occur for object files because CMake wisely puts object files in directories specific to each target.
I think the default location of compiler-generated .mod files should be the same as the location of the corresponding object files.https://gitlab.kitware.com/cmake/cmake/-/issues/22622XL Fortran flags halt on warning2021-09-13T11:28:48-04:00Miroslav StoyanovXL Fortran flags halt on warningIn `Modules/Compiler/XL-Fortran.cmake` line 17, the Fortran flags are too restrictive. Please, do not modify the default compiler behavior and remove the `-qhalt=e` flag, i.e., modify the line to:
```
string(APPEND CMAKE_Fortran_FLAGS_IN...In `Modules/Compiler/XL-Fortran.cmake` line 17, the Fortran flags are too restrictive. Please, do not modify the default compiler behavior and remove the `-qhalt=e` flag, i.e., modify the line to:
```
string(APPEND CMAKE_Fortran_FLAGS_INIT " -qthreaded")
```
The XL compiler blurs the distinction between "warning" and "error" by having three different levels of "error", "severe error" and "unrecoverable error". Much of what falls into the "error" category is considered a "warning" by other compilers. XL appropriately defaults to `-qhalt=s` and halts only on severe errors. Modifying the default behavior is roughly equivalent to adding `-Werror` to the default flags for other compilers, e.g., gcc and clang.
The problem is particularly frustrating when using automated tools to generate Fortran wrappings for C or C++ code where it is not always possible to directly intrude in the code and fix the issue. Sometimes the compiler messages are cryptic and/or point to incorrect lines of code. Bad XL messages are not an issue with CMake, but CMake should not break the build over a warning or an error that XL deems frivolous. See the following issue on GitHub related to Swig-Fortran wrapping and how this is affecting multiple projects:
https://github.com/xsdk-project/xsdk-issues/issues/94https://gitlab.kitware.com/cmake/cmake/-/issues/22519Fortran modules: source/config-specific flags are not using for resolving dep...2022-04-06T13:39:02-04:00Igor S. GerasimovFortran modules: source/config-specific flags are not using for resolving dependency graphs with MakefilesIn our project, for some sources specific flags are.
```
set_source_files_properties(SOURCE.F90 PROPERTIES COMPILE_DEFINITIONS FLAG)
```
This flag is used for choosing which module will be used in the code. Unfortunately, `COMPILE_DEFINI...In our project, for some sources specific flags are.
```
set_source_files_properties(SOURCE.F90 PROPERTIES COMPILE_DEFINITIONS FLAG)
```
This flag is used for choosing which module will be used in the code. Unfortunately, `COMPILE_DEFINITIONS` flags are not used when the source code is parsed.
I looked at `cmDependFortran.cxx` and noticed that only flags, defined in `CMAKE_TARGET_DEFINITIONS_Fortran` are applying. It seems to me, that the following code:
https://gitlab.kitware.com/cmake/cmake/-/blob/9e7a0568f604852af6994bebecf580b825b3ae36/Source/cmMakefileTargetGenerator.cxx#L744-766
should be repeated in `cmDependsFortran::WriteDependencies` before `parser` initialization for applying additional flags to each source file separately.https://gitlab.kitware.com/cmake/cmake/-/issues/22322FortranCInterface_VERIFY fails when LTO is used2021-06-21T10:25:23-04:00Tomasz KłoczkoFortranCInterface_VERIFY fails when LTO is usedWhole thread related to that issu is on https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/CABB28Cz7Hd-X_E%3DLmakBOscaungvM7mE0db_wotey_LyOZW7WQ%40mail.gmail.com/#msg37306025
In wsjtx project uses FortranCInterface_VERIFY () macro...Whole thread related to that issu is on https://sourceforge.net/p/wsjt/mailman/wsjt-devel/thread/CABB28Cz7Hd-X_E%3DLmakBOscaungvM7mE0db_wotey_LyOZW7WQ%40mail.gmail.com/#msg37306025
In wsjtx project uses FortranCInterface_VERIFY () macro and it fails when LTO is used
```console
+ cd wsjtx-2.5.0-rc1
+ CFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none'
+ CXXFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none'
+ FFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -I/usr/lib64/gfortran/modules'
+ FCFLAGS='-O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -I/usr/lib64/gfortran/modules'
+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed -Wl,--gc-sections -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin'
+ CC=/usr/bin/gcc
+ CXX=/usr/bin/g++
+ FC=/usr/bin/gfortran
+ AR=/usr/bin/gcc-ar
+ NM=/usr/bin/gcc-nm
+ RANLIB=/usr/bin/gcc-ranlib
+ export CFLAGS CXXFLAGS FFLAGS FCFLAGS LDFLAGS CC CXX FC AR NM RANLIB
+ /usr/bin/cmake -B x86_64-redhat-linux-gnu -D BUILD_SHARED_LIBS=ON -D CMAKE_AR=/usr/bin/gcc-ar -D CMAKE_BUILD_TYPE=RelWithDebInfo -D CMAKE_C_FLAGS_RELEASE=-DNDEBUG -D CMAKE_CXX_FLAGS_RELEASE=-DNDEBUG -D CMAKE_Fortran_FLAGS_RELEASE=-DNDEBUG -D CMAKE_INSTALL_PREFIX=/usr -D CMAKE_NM=/usr/bin/gcc-nm -D CMAKE_RANLIB=/usr/bin/gcc-ranlib -D CMAKE_VERBOSE_MAKEFILE=ON -D DBUILD_SHARED_LIBS=ON -D INCLUDE_INSTALL_DIR=/usr/include -D LIB_INSTALL_DIR=/usr/lib64 -D LIB_SUFFIX=64 -D SHARE_INSTALL_PREFIX=/usr/share -D SYSCONF_INSTALL_DIR=/etc -S . wsjtx -D hamlib_STATIC=FALSE -D Boost_NO_SYSTEM_PATHS=FALSE
-- The C compiler identification is GNU 11.1.1
-- The CXX compiler identification is GNU 11.1.1
-- The Fortran compiler identification is GNU 11.1.1
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Check for working C compiler: /usr/bin/gcc - skipped
-- Detecting C compile features
-- Detecting C compile features - done
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Detecting Fortran compiler ABI info
-- Detecting Fortran compiler ABI info - done
-- Check for working Fortran compiler: /usr/bin/gfortran - skipped
-- Checking whether /usr/bin/gfortran supports Fortran 90
-- Checking whether /usr/bin/gfortran supports Fortran 90 - yes
-- ******************************************************
-- Building for for: Linux-x86_64
-- ******************************************************
-- Building wsjtx v2.5.0.0-rc1
-- Looking for 4 include files stdlib.h, ..., float.h
-- Looking for 4 include files stdlib.h, ..., float.h - found
-- Looking for include file stdio.h
-- Looking for include file stdio.h - found
-- Looking for include file stdlib.h
-- Looking for include file stdlib.h - found
-- Looking for include file unistd.h
-- Looking for include file unistd.h - found
-- Looking for include file sys/ioctl.h
-- Looking for include file sys/ioctl.h - found
-- Looking for include file sys/types.h
-- Looking for include file sys/types.h - found
-- Looking for include file fcntl.h
-- Looking for include file fcntl.h - found
-- Looking for include file sys/stat.h
-- Looking for include file sys/stat.h - found
-- Looking for include files linux/ppdev.h, linux/parport.h
-- Looking for include files linux/ppdev.h, linux/parport.h - found
-- Looking for include files dev/ppbus/ppi.h, dev/ppbus/ppbconf.h
-- Looking for include files dev/ppbus/ppi.h, dev/ppbus/ppbconf.h - not found
-- Performing Test HAVE_MATH
-- Performing Test HAVE_MATH - Success
-- Looking for pthread.h
-- Looking for pthread.h - found
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD
-- Performing Test CMAKE_HAVE_LIBC_PTHREAD - Success
-- Found Threads: TRUE
-- Found Boost: /usr/include (found suitable version "1.75.0", minimum required is "1.62") found components: log_setup log date_time filesystem thread regex chrono atomic
-- Found OpenMP_C: -fopenmp (found version "4.5")
-- Found OpenMP_CXX: -fopenmp (found version "4.5")
-- Found OpenMP_Fortran: -fopenmp (found version "4.5")
-- Found OpenMP: TRUE (found version "4.5")
-- Found FFTW3: /usr/lib64/libfftw3f_threads.so
-- Found Usb
-- Found Hamlib 4.2
-- Looking for stdint.h
-- Looking for stdint.h - found
-- Looking for stddef.h
-- Looking for stddef.h - found
-- Check size of CACHE_ALL
-- Check size of CACHE_ALL - failed
-- Looking for rig_set_cache_timeout_ms
-- Looking for rig_set_cache_timeout_ms - not found
-- Found Portaudio 19
-- Detecting Fortran/C Interface
-- Detecting Fortran/C Interface - Failed to recognize symbols
-- Verifying Fortran/CXX Compiler Compatibility
CMake Warning (dev) at /usr/share/cmake/Modules/FortranCInterface.cmake:309 (message):
No FortranCInterface mangling known for VerifyFortran
Call Stack (most recent call first):
/usr/share/cmake/Modules/FortranCInterface/Verify/CMakeLists.txt:16 (FortranCInterface_HEADER)
This warning is for project developers. Use -Wno-dev to suppress it.
-- Verifying Fortran/CXX Compiler Compatibility - Failed
CMake Error at /usr/share/cmake/Modules/FortranCInterface.cmake:391 (message):
The Fortran compiler:
/usr/bin/gfortran
and the CXX compiler:
/usr/bin/g++
failed to compile a simple test project using both languages. The output
was:
Change Dir: /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX
Run Build Command(s):/usr/bin/gmake -f Makefile VerifyFortranC && /usr/bin/cmake -S/usr/share/cmake/Modules/FortranCInterface/Verify -B/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/gmake -f CMakeFiles/Makefile2 VerifyFortranC
gmake[1]: Entering directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
/usr/bin/cmake -S/usr/share/cmake/Modules/FortranCInterface/Verify -B/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX --check-build-system CMakeFiles/Makefile.cmake 0
/usr/bin/cmake -E cmake_progress_start /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles 6
/usr/bin/gmake -f CMakeFiles/Makefile2 CMakeFiles/VerifyFortranC.dir/all
gmake[2]: Entering directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
/usr/bin/gmake -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/depend
gmake[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
cd /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /usr/share/cmake/Modules/FortranCInterface/Verify /usr/share/cmake/Modules/FortranCInterface/Verify /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles/VerifyFortran.dir/DependInfo.cmake
Scanning dependencies of target VerifyFortran
gmake[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
/usr/bin/gmake -f CMakeFiles/VerifyFortran.dir/build.make CMakeFiles/VerifyFortran.dir/build
gmake[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
[ 16%] Building Fortran object CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o
/usr/bin/gfortran -DVERIFY_CXX -I/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -I/usr/lib64/gfortran/modules -DNDEBUG -fbounds-check -funroll-all-loops -fno-f2c -ffpe-summary=invalid,zero,overflow,underflow -Wall -Wno-conversion -fno-second-underscore -c /usr/share/cmake/Modules/FortranCInterface/Verify/VerifyFortran.f -o CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o
f951: Warning: '-Werror=' argument '-Werror=format-security' is not valid for Fortran
[ 33%] Linking Fortran static library libVerifyFortran.a
/usr/bin/cmake -P CMakeFiles/VerifyFortran.dir/cmake_clean_target.cmake
/usr/bin/cmake -E cmake_link_script CMakeFiles/VerifyFortran.dir/link.txt --verbose=1
/usr/bin/gcc-ar qc libVerifyFortran.a CMakeFiles/VerifyFortran.dir/VerifyFortran.f.o
/usr/bin/gcc-ranlib libVerifyFortran.a
gmake[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
[ 33%] Built target VerifyFortran
/usr/bin/gmake -f CMakeFiles/VerifyFortranC.dir/build.make CMakeFiles/VerifyFortranC.dir/depend
gmake[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
cd /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX && /usr/bin/cmake -E cmake_depends "Unix Makefiles" /usr/share/cmake/Modules/FortranCInterface/Verify /usr/share/cmake/Modules/FortranCInterface/Verify /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX /home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX/CMakeFiles/VerifyFortranC.dir/DependInfo.cmake
Scanning dependencies of target VerifyFortranC
gmake[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
/usr/bin/gmake -f CMakeFiles/VerifyFortranC.dir/build.make CMakeFiles/VerifyFortranC.dir/build
gmake[3]: Entering directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
[ 50%] Building C object CMakeFiles/VerifyFortranC.dir/main.c.o
/usr/bin/gcc -DVERIFY_CXX -I/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -Wall -Wextra -fopenmp -pthread -DNDEBUG -fdata-sections -ffunction-sections -o CMakeFiles/VerifyFortranC.dir/main.c.o -c /usr/share/cmake/Modules/FortranCInterface/Verify/main.c
[ 66%] Building C object CMakeFiles/VerifyFortranC.dir/VerifyC.c.o
/usr/bin/gcc -DVERIFY_CXX -I/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -Wall -Wextra -fopenmp -pthread -DNDEBUG -fdata-sections -ffunction-sections -o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o -c /usr/share/cmake/Modules/FortranCInterface/Verify/VerifyC.c
[ 83%] Building CXX object CMakeFiles/VerifyFortranC.dir/VerifyCXX.cxx.o
/usr/bin/g++ -DVERIFY_CXX -I/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -Werror -Wall -Wextra -fexceptions -frtti -Wno-pragmas -fopenmp --std=gnu++11 -pthread -DNDEBUG -fdata-sections -ffunction-sections -o CMakeFiles/VerifyFortranC.dir/VerifyCXX.cxx.o -c /usr/share/cmake/Modules/FortranCInterface/Verify/VerifyCXX.cxx
[100%] Linking CXX executable VerifyFortranC
/usr/bin/cmake -E cmake_link_script CMakeFiles/VerifyFortranC.dir/link.txt --verbose=1
/usr/bin/g++ -O2 -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fdata-sections -ffunction-sections -flto=auto -flto-partition=none -Werror -Wall -Wextra -fexceptions -frtti -Wno-pragmas -fopenmp --std=gnu++11 -pthread -DNDEBUG -fdata-sections -ffunction-sections -Wl,-z,relro -Wl,--as-needed -Wl,--gc-sections -Wl,-z,now -specs=/usr/lib/rpm/redhat/redhat-hardened-ld -flto=auto -flto-partition=none -fuse-linker-plugin CMakeFiles/VerifyFortranC.dir/main.c.o CMakeFiles/VerifyFortranC.dir/VerifyC.c.o CMakeFiles/VerifyFortranC.dir/VerifyCXX.cxx.o -o VerifyFortranC libVerifyFortran.a -lgfortran -lquadmath
/usr/bin/ld: /usr/bin/ld: DWARF error: invalid abstract instance DIE ref
/tmp/ccWzjZCF.lto.o: in function `main':
<artificial>:(.text.startup.main[.text.startup.main.group]+0x15): undefined reference to `VerifyFortran'
collect2: error: ld returned 1 exit status
gmake[3]: *** [CMakeFiles/VerifyFortranC.dir/build.make:130: VerifyFortranC] Error 1
gmake[3]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
gmake[2]: *** [CMakeFiles/Makefile2:88: CMakeFiles/VerifyFortranC.dir/all] Error 2
gmake[2]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
gmake[1]: *** [CMakeFiles/Makefile2:95: CMakeFiles/VerifyFortranC.dir/rule] Error 2
gmake[1]: Leaving directory '/home/tkloczko/rpmbuild/BUILD/wsjtx-2.5.0-rc1/x86_64-redhat-linux-gnu/CMakeFiles/FortranCInterface/VerifyCXX'
gmake: *** [Makefile:127: VerifyFortranC] Error 2
Call Stack (most recent call first):
CMakeLists.txt:1003 (FortranCInterface_VERIFY)
```https://gitlab.kitware.com/cmake/cmake/-/issues/22040Fortran: provide a module/variable which determines/contains platform module ...2021-07-13T22:14:06-04:00Ben BoeckelFortran: provide a module/variable which determines/contains platform module search pathsSome platforms (notably [Fedora](https://docs.fedoraproject.org/en-US/packaging-guidelines/Fortran/#_packaging_of_fortran_programs)) place Fortran modules in a location that is not searched by default. CMake should either extract this fr...Some platforms (notably [Fedora](https://docs.fedoraproject.org/en-US/packaging-guidelines/Fortran/#_packaging_of_fortran_programs)) place Fortran modules in a location that is not searched by default. CMake should either extract this from the compiler (though Fedora's `gfortran` build seems oblivious) or provide a module which discovers it.
FWIW, Debian seems to install modules (for HDF5 at least) under `/usr/include/hdf5/$buildmode`. It is unclear how installing multi-arch Fortran development packages works on Debian.
Cc: @brad.kinghttps://gitlab.kitware.com/cmake/cmake/-/issues/21860VS: Fortran source file property COMPILE_FLAGS overwrites target compile flags2021-02-25T16:59:12-05:00Volker JachtVS: Fortran source file property COMPILE_FLAGS overwrites target compile flagsHi, setting some extra compile flags per source file that would go to `Addition Options` in Visual Studio, will overwrite all per target flags, which were also in `Addition Options`. This only applies to Intel Fortran with Visual Studio....Hi, setting some extra compile flags per source file that would go to `Addition Options` in Visual Studio, will overwrite all per target flags, which were also in `Addition Options`. This only applies to Intel Fortran with Visual Studio. Makefiles in general and/or C projects work fine and append the flags correctly.
Here is a CMake file to reproduce:
```cmake
cmake_minimum_required(VERSION 3.8)
project(test Fortran)
if(MSVC)
set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} /flag_default /DDEFAULT=1")
else()
set(CMAKE_Fortran_FLAGS "${CMAKE_Fortran_FLAGS} -flag_default -DDEFAULT=1")
endif()
add_library(test a.F90 b.F90)
if(MSVC)
set_source_files_properties(a.F90 APPEND PROPERTIES COMPILE_FLAGS "/flag_extra /DEXTRA=1")
else()
set_source_files_properties(a.F90 APPEND PROPERTIES COMPILE_FLAGS "-flag_extra -DEXTRA=1")
endif()
```
VS seems to be inconsistent here. If `AdditionalOptions` is set in the file specific configuration in the vfproj file, VS overwrites the target flags. On the other hand, everthing set via `PreprocessorDefinitions` is appended to the target proprocessor defintions.
The following commit kind of fixes the issue by additionally applying the target flags to the source code specific flags. but it may also duplicate preprocessor definitions (which might be less of problem):
https://gitlab.kitware.com/kooky089/cmake/-/commit/107da6fdc60339a84b1d232c3e5affbbd7d888d6
Do you have any hint or suggestion?
Thanks and kind regards,
Volkerhttps://gitlab.kitware.com/cmake/cmake/-/issues/21816Ninja: Debug symbols in Fortran with Intel compiler on Windows2022-02-23T08:48:20-05:00Andreas SchulzNinja: Debug symbols in Fortran with Intel compiler on Windows**Description**
There is a problem with debugging Fortran code, because the source code reference in the object file is not set correctly.
**Reproducer**
[reproducer.zip](/uploads/e7d1e27a360e51f7027f0c68ff074e87/reproducer.zip)
**Addi...**Description**
There is a problem with debugging Fortran code, because the source code reference in the object file is not set correctly.
**Reproducer**
[reproducer.zip](/uploads/e7d1e27a360e51f7027f0c68ff074e87/reproducer.zip)
**Additional Information**
Apparently, during preprocessing of a source file with the Intel compiler the result is written to the terminal and then redirected into a subfolder. This behavior is defined in
CMAKE_Fortran_PREPROCESS_SOURCE (more precisely, here: -E > <PREPROCESSED_SOURCE>).
The preprocessed file contains a reference to the source file in the first line comment
(# 1 “…\main.f” in the minimal example),
which is used by the Intel compiler to create the reference in the object file. But since the preprocessed file is shifted into a subfolder, the relative path becomes outdated and in the object file we get an invalid path
(CMakeFiles\hello_world_fortran.dir…\main.f in the minimal example).
**Version Information**
The problem appears with Ninja version 1.9.0, CMake version 3.19.3, IFort version 19.1.1.216, and Fortran 77.https://gitlab.kitware.com/cmake/cmake/-/issues/21756Fortran: Misses dependency with preprocessor and line continuation2021-01-31T02:23:27-05:00Deniz UralFortran: Misses dependency with preprocessor and line continuationI am working with a climate model which originally uses configure & make but our colleagues developed CMake as an alternative.
It looks like CMake can't resolve the module dependency similar to the case mentioned in https://gitlab.kitw...I am working with a climate model which originally uses configure & make but our colleagues developed CMake as an alternative.
It looks like CMake can't resolve the module dependency similar to the case mentioned in https://gitlab.kitware.com/cmake/cmake/-/issues/18188.
Here is the problematic section:
```
MODULE mo_cuascent
USE mo_kind, ONLY : wp
USE mo_physical_constants, ONLY : grav, tmelt, vtmpc1, rv, rd, alv, als
#ifndef __ICON__
USE mo_echam_conv_constants, ONLY : lmfdudv, lmfmid, nmctop, cmfcmin, cmfcmax, &
#else
USE mo_echam_conv_constants, ONLY : lmfdudv, lmfmid, cmfcmin, cmfcmax, &
#endif
& cprcon, entrmid, cmfctop, centrmax, cbfac, &
& cminbuoy, cmaxbuoy
USE mo_cuadjust, ONLY : cuadjtq
#ifdef _PROFILE
USE mo_profile, ONLY : trace_start, trace_stop
#endif
```
During the build, this error occurs:
```
mo_cuascent.f90(56): error #7002: Error in opening the compiled module file. Check INCLUDE paths. [MO_ECHAM_CONV_CONSTANTS]
USE mo_echam_conv_constants, ONLY : lmfdudv, lmfmid, nmctop, cmfcmin, cmfcmax, &
------^
```
`make.depend` file has
```
mo_cuascent.f90.o: src/echam/CMakeFiles/echam6.dir/mo_cuadjust.mod.stamp
mo_cuascent.f90.o: src/echam/CMakeFiles/echam6.dir/mo_kind.mod.stamp
mo_cuascent.f90.o: src/echam/CMakeFiles/echam6.dir/mo_physical_constants.mod.stamp
mo_cuascent.f90.o.provides.build: src/echam/CMakeFiles/echam6.dir/mo_cuascent.mod.stamp
mo_cuascent.mod.stamp: src/echam/CMakeFiles/echam6.dir/mo_cuascent.f90.o
```
Unfortunately `mo_echam_conv_constants.f90` is not built yet at that point. Interestingly, when I use parallel make (`make -j`) the executable is built by luck.
If I move the trailing continuation lines into the preprocessor directive. Eg:
```
#ifndef __ICON__
USE mo_echam_conv_constants, ONLY : lmfdudv, lmfmid, nmctop, cmfcmin, cmfcmax, &
& cprcon, entrmid, cmfctop, centrmax, cbfac, &
& cminbuoy, cmaxbuoy
#else
USE mo_echam_conv_constants, ONLY : lmfdudv, lmfmid, cmfcmin, cmfcmax, &
& cprcon, entrmid, cmfctop, centrmax, cbfac, &
& cminbuoy, cmaxbuoy
#endif
USE mo_cuadjust, ONLY : cuadjtq
```
It works since CMake can now resolve the missing dependency `mo_echam_conv_constants`.
```
mo_cuascent.f90.o: src/echam/CMakeFiles/echam6.dir/mo_cuadjust.mod.stamp
mo_cuascent.f90.o: src/echam/CMakeFiles/echam6.dir/mo_echam_conv_constants.mod.stamp
mo_cuascent.f90.o: src/echam/CMakeFiles/echam6.dir/mo_kind.mod.stamp
mo_cuascent.f90.o: src/echam/CMakeFiles/echam6.dir/mo_physical_constants.mod.stamp
mo_cuascent.f90.o.provides.build: src/echam/CMakeFiles/echam6.dir/mo_cuascent.mod.stamp
mo_cuascent.mod.stamp: src/echam/CMakeFiles/echam6.dir/mo_cuascent.f90.o
```
I tried this with many different versions of CMake including 3.19.3 but they don't work, unfortunately.
We are using Intel compilers & MPI (mpiifort, mpiicc). I made a workaround using regex to first parse this file before building with CMake since our automatization software depends on CMake.
Could you please have a look at this bug?
Kind regardshttps://gitlab.kitware.com/cmake/cmake/-/issues/21398Ninja does not work with NAG Fortran: Missing variable is: CMAKE_Fortran_PREP...2021-05-07T10:14:39-04:00Matthew ThompsonNinja does not work with NAG Fortran: Missing variable is: CMAKE_Fortran_PREPROCESS_SOURCEI recently tried to use `cmake -G Ninja` with NAG Fortran and:
```console
❯ cmake .. -G Ninja
-- The Fortran compiler identification is NAG 7.0.7020
-- The C compiler identification is AppleClang 12.0.0.12000032
-- Detecting NAG Fortran ...I recently tried to use `cmake -G Ninja` with NAG Fortran and:
```console
❯ cmake .. -G Ninja
-- The Fortran compiler identification is NAG 7.0.7020
-- The C compiler identification is AppleClang 12.0.0.12000032
-- Detecting NAG Fortran directory
-- Detecting NAG Fortran directory - /Users/mathomp4/installed/Core/nag/7.0_7020/lib/NAG_Fortran
-- Check for working Fortran compiler: /Users/mathomp4/installed/Core/nag/7.0_7020/bin/nagfor
CMake Error: Error required internal CMake variable not set, cmake may not be built correctly.
Missing variable is:
CMAKE_Fortran_PREPROCESS_SOURCE
CMake Error at /Users/mathomp4/.homebrew/brew/Cellar/cmake/3.18.4/share/cmake/Modules/CMakeTestFortranCompiler.cmake:39 (try_compile):
Failed to generate test project build system.
Call Stack (most recent call first):
CMakeLists.txt:27 (project)
-- Configuring incomplete, errors occurred!
See also "/Users/mathomp4/IntelTimingTest/pFUnit/build-nag-Ninja/CMakeFiles/CMakeOutput.log".
See also "/Users/mathomp4/IntelTimingTest/pFUnit/build-nag-Ninja/CMakeFiles/CMakeError.log".
```
So, I'm assuming this is similar to https://gitlab.kitware.com/cmake/cmake/-/issues/19450
I'm willing to try and figure out a `CMAKE_Fortran_PREPROCESS_SOURCE` for NAG Fortran, but there is a "hitch": NAG Fortran doesn't have a way to spit out the source to standard output, i.e., the usual `-E`, that I can see (I might ask their support). It does have:
> -F Preprocess only, do not compile. Each file that is preprocessed will produce an output file of the same name with the
> suffix replaced by .f, .f90 or .f95 according to the suffix of the input file. This option is equivalent to
> -otype=Fortran.
I'm wondering: is there an example in the CMake source for a Fortran compiler that doesn't have the `-E` functionality that might get Ninja working with NAG?https://gitlab.kitware.com/cmake/cmake/-/issues/21257FindMPI: Cannot find MSMPI for Fortran2022-12-13T08:26:39-05:00Tetsuya MishimaFindMPI: Cannot find MSMPI for FortranThe CMake 3.18 findMPI on Windows 10 can’t find MS-MPI for Fortran. After some investigations, I found that this patch fixed the problem:
```patch
FindMPI.cmake Thu Aug 20 08:20:32 2020
FindMPI.cmake-p1 Wed Sep 30 11:10:26 2020
********...The CMake 3.18 findMPI on Windows 10 can’t find MS-MPI for Fortran. After some investigations, I found that this patch fixed the problem:
```patch
FindMPI.cmake Thu Aug 20 08:20:32 2020
FindMPI.cmake-p1 Wed Sep 30 11:10:26 2020
***************
*** 1091,1096 ****
--- 1091,1101 ----
if(MPI_${LANG}_INCLUDE_DIRS)
list(REMOVE_DUPLICATES MPI_${LANG}_INCLUDE_DIRS)
endif()
+ if(MPI_${LANG}_ADDITIONAL_INCLUDE_VARS)
+ foreach(MPI_ADDITIONAL_INC_DIR IN LISTS MPI_${LANG}_ADDITIONAL_INCLUDE_VARS)
+ list(APPEND MPI_${LANG}_INCLUDE_DIRS "${MPI_${MPI_ADDITIONAL_INC_DIR}_INCLUDE_DIR}")
+ endforeach()
+ endif()
endmacro()
macro(_MPI_split_include_dirs LANG)
```
Regards,
Tetsuya Mishima