Closed koutoui closed 3 years ago
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
Now, using Visual Studio emits an error as I don't know how to make VS work with Mumps
@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.
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.
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
OK thank you!
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
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.
Hi all, I've been trying to compile mumps v5.3.3.7 with the intel toolchain on Windows using cmake, but I'm getting linker errors when I'm trying to compile the c_example.c (that's under the example folder). (NOTE: All is done in the intel specific cmd with msvc2019 integration)
I first run:
that outputs:
which I then build like that:
which outputs:
And then I install it:
which outputs:
But, when I try to compile the example (which I've changed a bit).
and I get:
Which outputs a DMUMPS_SET_TMP_PTR and a DMUMPS_F77 linker error. Could you point me in the right direction on how to fix that? (I'm not much of a windows expert). Note: I've opened the visual studio solution to build it from there, since there was a url suggestion on your readme(https://software.intel.com/content/www/us/en/develop/articles/configuring-visual-studio-for-mixed-language-applications.html), but the IFORT_COMPILER/etc variables were already defined
Best Regards, Ioannis