CMake issueshttps://gitlab.kitware.com/cmake/cmake/-/issues2023-07-12T08:44:21-04:00https://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/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/23241FindOpenMP: Using libiomp5md.dll2022-02-20T03:28:07-05:00terrylyonsFindOpenMP: Using libiomp5md.dllIn a project with multiple components using openmp protocol, it is essential that they all use the same dll to provide the service. The mkl component links to the intel module libiomp5md.dll which does the job and is a drop in replacemen...In a project with multiple components using openmp protocol, it is essential that they all use the same dll to provide the service. The mkl component links to the intel module libiomp5md.dll which does the job and is a drop in replacement for the Microsoft version. FindLapack identifies the version shipped in the visual studio folder tree. The issue is that there seems no way to direct FindOpenMP to do the same. Components which rely on find_package OpenMP introduce a dependency to libomp.dll that results in unusable builds.
This is the issue: how to direct find_package(OpenMP) to use/inherit a particular (external) choice of link library and link library path consistently. Setting the obvious variables in the cache does not seem to have an effect.
This is a breaking issue for me.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/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/20904InstallRequiredSystemLibraries, Intel Fortran2020-07-02T12:40:01-04:00Torgeir RustenInstallRequiredSystemLibraries, Intel FortranIn i Fortran project I use the InstallRequiredSystemLibraries module. I use the Intel Fortran Compiler:
```
c:\NinjaCmake\Fortran>cmake -B CMakeBuild -G "Ninja"
-- The Fortran compiler identification is Intel 19.1.0.20200306
....
...In i Fortran project I use the InstallRequiredSystemLibraries module. I use the Intel Fortran Compiler:
```
c:\NinjaCmake\Fortran>cmake -B CMakeBuild -G "Ninja"
-- The Fortran compiler identification is Intel 19.1.0.20200306
....
```
The InstallRequiredSystemLibraries issue the message:
```
CMake Warning at C:/Program Files/CMake/share/cmake-3.18/Modules/InstallRequiredSystemLibraries.cmake:699 (message):
system runtime library file does not exist: 'C:/Program Files
(x86)/IntelSWTools/compilers_and_libraries_2020.1.216/windows/redist/intel64/compiler/libioffload_host.dll'
Call Stack (most recent call first):
CMakeLists.txt:17 (include)
```
This library, and also the liboffload.dll and libmpx.lib, are removed from the Intel redist.
In my CMakeLists.txt I have an install command and when I install the Release version of my program the following dll's are installed:
```
-- Installing: C:/NinjaCmake/Fortran/./bin/msvcp140.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/vcruntime140.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/concrt140.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/cilkrts20.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libchkp.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libirngmd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libmmd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libmmdd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/svml_dispmd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/ifdlg100.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libicaf.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifcoremd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifcoremdd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifcorert.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifcorertd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/libifportmd.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1033
-- Installing: C:/NinjaCmake/Fortran/./bin/1033/ifcore_msg.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1033/irc_msg.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1033/libmUI.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1041
-- Installing: C:/NinjaCmake/Fortran/./bin/1041/ifcore_msg.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1041/irc_msg.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1041/libiomp5ui.dll
-- Installing: C:/NinjaCmake/Fortran/./bin/1041/libmUI.dll
```
Here libmmdd.dll, libifcoremdd.dll are debug dll's and could be removed from the installation.
Furthermore, I think msvcp140, concrt140 and cilkrts20 are c++ libraries and could be removed? I have never shipped them with Fortran executables. From the intel documentation it also look like libirngmd is also for c++.
The libifcorert is used when compiling using /MDs (single threaded dynamic library) , as far as I understand from the Intel documentation the /MDs switch is depreciated so I guess the libifcorert.dll could also be removed.
My guess is that libchkp(check pointers), ifdlg100(interface dialog) and libicaf(co arrays) are not much used and can also be removed.https://gitlab.kitware.com/cmake/cmake/-/issues/20881IPO: Intel C++ for Windows2022-03-30T15:41:22-04:00Matheus IzvekovIPO: Intel C++ for WindowsTested on Intel C++ compiler 19.1 with VS 2019
check_ipo_supported fails: CMake doesn't support IPO for current CXX compiler
My own analysis:
Looking at the code, it is only supported for linux in `Compiler\Intel.cmake`.
From the oth...Tested on Intel C++ compiler 19.1 with VS 2019
check_ipo_supported fails: CMake doesn't support IPO for current CXX compiler
My own analysis:
Looking at the code, it is only supported for linux in `Compiler\Intel.cmake`.
From the other side, `Platform\Windows-MSVC.cmake` does not handle `Intel` Compiler ID.https://gitlab.kitware.com/cmake/cmake/-/issues/20590VS: CUDA in custom path and Intel compiler2020-12-07T03:46:02-05:00Paolo CrosettoVS: CUDA in custom path and Intel compilerI'm trying to compile some targets on Windows with Intel compilers and others with CUDA with cl as host compiler. This worked when using FindCuda.cmake by setting ```CMAKE_GENERATOR_TOOLSET="Intel C++ Compiler 18.0"```. My understanding ...I'm trying to compile some targets on Windows with Intel compilers and others with CUDA with cl as host compiler. This worked when using FindCuda.cmake by setting ```CMAKE_GENERATOR_TOOLSET="Intel C++ Compiler 18.0"```. My understanding is that now I can achieve it by setting
```
CMAKE_GENERATOR_TOOLSET="Intel C++ Compiler 18.0,cuda=<path-to-cuda>"
```
However this does not work
```
-- Looking for a CUDA compiler
-- Looking for a CUDA compiler - NOTFOUND
```
Setting ``` CMAKE_GENERATOR_TOOLSET=cuda=<path-to-cuda>"``` works (but uses the visual studio compiler everywhere).https://gitlab.kitware.com/cmake/cmake/-/issues/19182VS: Intel Fortran project link flags2019-04-22T19:59:31-04:00TangLaoyaVS: Intel Fortran project link flagsDear all,
I downloaded the latest Cmake and let it generate project for Visual Studio. The environment I used is Windows 7 64 bit + Visual Studio 2013 + Intel Fortran 2019, when use cmake-3.13.4-win64-x64 I can generate correct Fortran a...Dear all,
I downloaded the latest Cmake and let it generate project for Visual Studio. The environment I used is Windows 7 64 bit + Visual Studio 2013 + Intel Fortran 2019, when use cmake-3.13.4-win64-x64 I can generate correct Fortran and C++ project, but there are some options that can't feed to the Visual Studio IDE, for example, /MAP /STACK:1000000000. I tried the latest version cmake-3.14.2-win64-x64, but this time the original project 'fem' has become a C++ project. Could anyone help me to take a look at it?
Thanks,
Tang Laoya
[CMakeLists.txt](/uploads/3d3845a111b3edd123d51c889168f236/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/19115Intel: 2019 compiler version macros incorrect2019-04-02T07:46:01-04:00Mark AbrahamIntel: 2019 compiler version macros incorrectUsing cmake 3.13.1 and a freshly installed Intel compiler suite, I get
```
$ /opt/tcbsys/intel/compilers_and_libraries_2019.3.199/linux/bin/intel64/icpc -V
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, V...Using cmake 3.13.1 and a freshly installed Intel compiler suite, I get
```
$ /opt/tcbsys/intel/compilers_and_libraries_2019.3.199/linux/bin/intel64/icpc -V
Intel(R) C++ Intel(R) 64 Compiler for applications running on Intel(R) 64, Version 19.0.3.199 Build 20190206
Copyright (C) 1985-2019 Intel Corporation. All rights reserved.
$ cmake --version
cmake version 3.13.1
CMake suite maintained and supported by Kitware (kitware.com/cmake).
$ (cd build; cmake .. -DCMAKE_CXX_COMPILER=icpc -DCMAKE_C_COMPILER=icc)
-- The C compiler identification is Intel 19.0.0.20190206
-- The CXX compiler identification is Intel 19.0.0.20190206
-- Check for working C compiler: /opt/tcbsys/intel/compilers_and_libraries_2019.3.199/linux/bin/intel64/icc
-- Check for working C compiler: /opt/tcbsys/intel/compilers_and_libraries_2019.3.199/linux/bin/intel64/icc -- works
-- Detecting C compiler ABI info
-- Detecting C compiler ABI info - done
-- Detecting C compile features
-- Detecting C compile features - done
-- Check for working CXX compiler: /opt/tcbsys/intel/compilers_and_libraries_2019.3.199/linux/bin/intel64/icpc
-- Check for working CXX compiler: /opt/tcbsys/intel/compilers_and_libraries_2019.3.199/linux/bin/intel64/icpc -- works
-- Detecting CXX compiler ABI info
^C
```
I expected the compiler versions to be identified as e.g. 19.0.3.20190206. Major version looks detected OK, minor version may be OK, but the patch version is not detected correctly and perhaps is defaulting to 0?https://gitlab.kitware.com/cmake/cmake/-/issues/17765No Fortran Compiler Could be Found...Tried Everything2021-02-01T17:14:38-05:00MikeNo Fortran Compiler Could be Found...Tried EverythingI am completely new to cmake and compiling. I am trying to compile a dll for the program OpenFAST developed by NREL. They provide the .f90 file and a CMakeLists file. Their instruction for Windows are to use execute "cmake -G "Visual ...I am completely new to cmake and compiling. I am trying to compile a dll for the program OpenFAST developed by NREL. They provide the .f90 file and a CMakeLists file. Their instruction for Windows are to use execute "cmake -G "Visual Studio XXX", filling in the version of Visual Studio I have.
I am stuck at the file not finding a Fortran compiler. I downloaded Simply Fortran 2, which includes gfortran, and Intel Parallel Studio 2018, which has ifort. Both of these are added to the PATH, and I get a response when I type them in to any command window. So I know the path to ifort and gfortran works correctly. I downloaded Intel Parallel Studio XE 2018, CMake 3.10.2, and Visual Studio Community 2017. I had read there were issues with PSXE 2017 not integrating with VS 2017, but that it was resolved in PSXE 2018.
I have attached the CMakeLists file. I added line 19, set(FC "path to ifort") to try to force the program to recognize ifort. I tried this with gfortran as well, and without the full path for both since the directories are in the PATH. The error occurs with line 20, when it tries to enable the language. It says "The Fortran compiler identification is unknown...No CMAKE_Fortran_COMPILER could be found".
Please, I've searched everywhere online for topics like this. I've been trying to get this to compile for six days. I don't know what I'm doing wrong. If I'm editing the CMakeLists file to specify the compiler to use, which is not even a good practice from what I've read, I don't know what else I can do.
[CMakeLists.txt](/uploads/5715707d230fa5a50c43da27289fe043/CMakeLists.txt)https://gitlab.kitware.com/cmake/cmake/-/issues/17524Ninja: re-compilation cascades in Fortran builds2023-09-06T15:58:17-04:00Yurii BatrakNinja: re-compilation cascades in Fortran buildsWhen cmake uses the "Unix Makefiles" generator it produces a makefile that contains some additional "magic" to avoid unnecessary re-compilations. Basically, when a Fortran module is re-compiled, cmake checks, does the produced `*.mod` fi...When cmake uses the "Unix Makefiles" generator it produces a makefile that contains some additional "magic" to avoid unnecessary re-compilations. Basically, when a Fortran module is re-compiled, cmake checks, does the produced `*.mod` file differ from the `*.mod` file from previous compilation, and is able to figure out that modules are actually the same.
Contrary, when cmake uses the "Ninja" generator such optimization isn't applied and if Fortran compiler updates timestamps of module files on each re-compilation, even if the `*.mod` file itself wasn't changed (as in case of ifort), an incremental build with ninja falls in a series of unnecessary re-compilations.https://gitlab.kitware.com/cmake/cmake/-/issues/17234Ninja: Fortran INCLUDE directive and Intel assume:nosource_include2017-09-08T06:07:30-04:00NunoNinja: Fortran INCLUDE directive and Intel assume:nosource_includeHi,
I am using cmake 3.9.1 with ninja 1.7.2.git.kitware.dyndep-1.
Our project has some target that rely on the intel fortran flag assume:nosource_include.
The idea is that we can get include files from other directories other than the ...Hi,
I am using cmake 3.9.1 with ninja 1.7.2.git.kitware.dyndep-1.
Our project has some target that rely on the intel fortran flag assume:nosource_include.
The idea is that we can get include files from other directories other than the current source one.
say the flag is on, my file is src/test1.f90 and I have src/test1.inc and src2/test1.inc.
if the flag is on and provided that the command line is something like "-Isrc2 -Isrc", the compiler will include src2/test1.inc.
for some reason, the build.ninja that get created insists in adding the current source dir to the list of INCLUDES for test1.f90.obj.
build.ninja has then
INCLUDES = -Isrc -Isrc2 -Isrc
I know that this is not ideal, but it is convenient.
thanks,
Nunohttps://gitlab.kitware.com/cmake/cmake/-/issues/16714Using Intel Fortran on Windows with NMake generator fails to detect the linke...2017-10-13T13:17:55-04:00Javier MartínUsing Intel Fortran on Windows with NMake generator fails to detect the linker versionWhen using an installation of Intel Fortran 12.0 in Windows that does not have the MS *C/C++ compiler* available, the feature detection code is not able to tell the feature level of the *linker*. In particular, I use ifort 12.0 with VS20...When using an installation of Intel Fortran 12.0 in Windows that does not have the MS *C/C++ compiler* available, the feature detection code is not able to tell the feature level of the *linker*. In particular, I use ifort 12.0 with VS2008, so the linker used is able to generate and embed a manifest into binaries. However, since the activation of this feature depends on MSVC_VERSION and this variable gets a "wrong", low value, the manifest embedding is not enabled and instead, the linker generates both my out.exe and an out.exe.manifest file. By contrast, if the VS 2008 generator is used instead of the "NMake Makefiles" generator, the rules for manifest embedding are generated.
The problem can be reproduced as follows:
* Environment: Windows computer with Intel Fortran 12.0 with MS Visual Studio 2008 _shell_ - it has link.exe (9.0) but not the corresponding cl.exe (15.0)
* Project: any simple "hello world" Fortran project will do. I am just doing `project(out Fortran)` and then `add_executable(out hello.f90)`.
* Configuration: I configure and generate the project with two generators, "Visual Studio 9 2008" and "NMake Makefiles" (the latter from the command line created by the Intel Fortran-provided equivalent to vcvars.bat)
* Result: the VS project generates out.exe, which has an embedded manifest; while the makefile version generates out.exe _without_ an embedded manifest _and_ an out.exe.manifest alongside it. In order for the latter executable to be usable, the manifest file must either be copied alongside the binary, or manually embedded with a call to mt.exe.
* Expected result: both generators result in executable files with embedded manifests.
I traced the problem to the fact that `Modules/Platforms/Windows-MSVC.cmake` (which is included by `Windows-Intel.cmake`) tests the `MSVC_VERSION` variable (the version of *cl.exe*) and only enables the manifest embedding if it at least 1400, the version of cl that comes with VS 2005.
This variable is defined above in the same file; in this case it is set from the value of the `CMAKE_Fortran_SIMULATE_VERSION` variable, which comes from data extracted from the Intel Fortran compiler by building and running `CMakeFortranCompilerId.F.in`. The problem is that, while Intel Fortran in Windows does report the \_MSC_VER macro, it reports *the same version reported by cl.exe*. Since in my case there is no cl.exe to be found, ifort reports _MSC_VER=1020, which is so old that it is stored by CMake as 1300. Thus, the manifest embedding feature is not enabled.
Since having the Intel Fortran compiler without the MS _C compiler_ is a valid configuration, the condition for the manifest embedding feature should depend on detecting features from the linker itself, not the C compiler.https://gitlab.kitware.com/cmake/cmake/-/issues/15262Visual Studio Generators: selection of runtime2018-02-21T09:08:47-05:00Kitware RobotVisual Studio Generators: selection of runtimeThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15262). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=15262). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/11437Visual project generation for Intel Fortran targets: XML syntax error and mis...2018-04-26T12:18:59-04:00Kitware RobotVisual project generation for Intel Fortran targets: XML syntax error and missing source control variablesThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11437). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=11437). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/9948put env.var INTEL_LICENSE_FILE into eclipse/kdevelop/codeblocks projects when...2018-04-26T12:18:59-04:00Kitware Robotput env.var INTEL_LICENSE_FILE into eclipse/kdevelop/codeblocks projects when the Intel compiler is usedThis issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=9948). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=9948). Further discussion may take place here.https://gitlab.kitware.com/cmake/cmake/-/issues/8067Incorrect Default Flags with IFORT(10.1.025) and Visual Studio 20082018-04-28T09:16:27-04:00Kitware RobotIncorrect Default Flags with IFORT(10.1.025) and Visual Studio 2008This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8067). Further discussion may take place here.This issue was created automatically from an original [Mantis Issue](https://cmake.org/Bug/view.php?id=8067). Further discussion may take place here.