If no linker preference is set for a shared library, CMake is choosing the executable that is used for linking based on the highest linker preference value. If a library consists of C and Fortran sources, the Fortran compiler frontend has the higher linker preference value and it is chosen by default.
For the Intel oneAPI compiler with MSVC-like syntax icx-cl as the C and C++ compiler and the Intel oneAPI Fortran compilers ifort or ifx, this leads to the following situation in combination with WINDOWS_EXPORT_ALL_SYMBOLS:
The symbols that are to be exported from the library are collected from the C objects and written to a .def file.
Flags are generated that pass that .def file to the linker. However, the syntax for these flags match the C compiler icx-cl.
The Fortran compiler is used for linking (higher linker preference value). But .def files need to be passed differently for ifx or ifort than for icx-cl.
That leads to the linked libraries being empty or only exporting the Fortran symbols.
This is probably an issue that should be fixed in CMake. (However, that doesn't seem to be solvable easily.)
To work around the issue, explicitly specify to use the C compiler frontend as the linker for the AMD and CHOLMOD libraries.
If no linker preference is set for a shared library, CMake is choosing the executable that is used for linking based on the highest linker preference value. If a library consists of C and Fortran sources, the Fortran compiler frontend has the higher linker preference value and it is chosen by default.
For the Intel oneAPI compiler with MSVC-like syntax
icx-cl
as the C and C++ compiler and the Intel oneAPI Fortran compilersifort
orifx
, this leads to the following situation in combination withWINDOWS_EXPORT_ALL_SYMBOLS
:.def
file..def
file to the linker. However, the syntax for these flags match the C compilericx-cl
..def
files need to be passed differently forifx
orifort
than foricx-cl
.That leads to the linked libraries being empty or only exporting the Fortran symbols.
This is probably an issue that should be fixed in CMake. (However, that doesn't seem to be solvable easily.) To work around the issue, explicitly specify to use the C compiler frontend as the linker for the AMD and CHOLMOD libraries.
Fixes #799.