Linker Errors in Windows (intel toolchain with msvc) about mumps

[scivision]

I would use the Ninja or MinGW Makefiles generator instead of Visual Studio. I've never gotten Visual Studio to work. I should update the message to note that. I almost always use Ninja as it generally works faster and more reliably than GNU Make. https://github.com/ninja-build/ninja/releases

[scivision]

Now, using Visual Studio emits an error as I don't know how to make VS work with Mumps

[dariomangoni]

@koutoui just for reference: the approach here followed mixes C and Fortran source files all at once (e.g. mumps_common).
Visual Studio then considers the target as C/C++ code, but actually the compiler options that are passed are for the Fortran compiler.
In order to overcome this issue I think that you have to compile (where "compile" is used in the strict sense i.e. without linking) C and Fortran file in separate object files, then link the two object files in a single library.
Something like:

ADD_LIBRARY(mumps_common
                        $<TARGET_OBJECTS:MUMPS_COMMON_OBJ_FORTRAN>
                        $<TARGET_OBJECTS:MUMPS_COMMON_OBJ_C>
                        ${MUMPS_COMMON_EXPORTS})

(here the MUMPS_COMMON_EXPORTS are used to allow the symbol exposition that was probably needed because I was compiling shared libraries and I don't know if MUMPS_CALL was enough to export all the symbols needed)
This allowed me to compile Mumps in Windows directly in VS and also as shared library at least for 5.1.2 (the last time I tried) but it is quite stressful operation.

from mumps.

[scivision]

Yes I tried this in "objects" branch but had problems with the cyclical links in Mumps.
I think this is a worthwhile improvement. To do this, I will probably have to start with the original Mumps Makefiles, mimicking their numerous object file creation. Once that works, I can combine into fewer object files perhaps, or just so some foreach() loops.

[dariomangoni]

If it can be of any help this is my full CMakeLists (dated back to Mumps 5.1.1) that I've used for a while to build Mumps for our software.
However, what I did is to merge all the libraries in just one shared library. Probably this overcame the problem, but then you won't have the standard set of files (mumps_common, dmumps, etc will be collapsed in a single libdmumps).
CMakeLists_5.1.1.txt

[scivision]

OK thank you!

[eremite-ever]

This project is too awesome！
but I also encountered this link problem in Windows(intel toochain with msvc), and I am looking forward to a good solution！

dmumps.lib(mumps_c.obj) : error LNK2019: unresolved external symbol DMUMPS_SET_TMP_PTR referenced in function DMUMPS_SET_TMP_PTR_C
dmumps.lib(mumps_c.obj) : error LNK2019: unresolved external symbol DMUMPS_F77 referenced in function dmumps_c

[scivision]

For both #1 and #2, despite recent MUMPS CMake enhancement re: shared libs, on Windows with Intel oneAPI (icl/ifort or icx/ifx) shared libs still don't work. This may be an upstream MUMPS issue. Using static libs (the default) does work.