Export API routines for MSVC compiler#168
Export API routines for MSVC compiler#168TyBalduf wants to merge 0 commit intodftd4:mainfrom TyBalduf:main
Conversation
awvwgk
left a comment
awvwgk
left a comment
There was a problem hiding this comment.
I can understand why we need to export the procedures in the C API. However, why do we have to do the same for the Fortran API? Especially, for type bound procedures the created struct will provide a procedure pointer.
Codecov Report
@@ Coverage Diff @@
## main #168 +/- ##
=======================================
Coverage 60.12% 60.12%
=======================================
Files 44 44
Lines 3130 3130
Branches 1019 1019
=======================================
Hits 1882 1882
Misses 667 667
Partials 581 581
Continue to review full report at Codecov.
|
|
@awvwgk I'm not entirely sure why the app subroutines would need the DLL attributes. This was the error I was getting on the last step of the build after I added DLLEXPORTs to just the api subroutines: So my first pass was to try also adding DLLEXPORT to the other unresolved external symbols, which worked on my machine. I suspect it could be due to my compiler setup being somewhat unusual (ifort and msvc cl). This is not a crucial fix in my view. My main goal was to see if making the compilation work for my setup was as simple as the fix made for getting xTB to compile. I'll leave this as a draft until I get a chance to try to fix it. |
|
The docs/build-and-deploy error seems to be unrelated. I'll have to look more into what could be causing the intel-build failure, though that is during the CMake build of mctc, so I'm surprised my changes would affect it. |
|
I can reproduce the error with Intel 2021.5 and MSVC 19.31 on my machine. Seems like the dllexports are needed all over the place, however they don't work anymore on Unix platforms and I'm not down for introducing preprocessor statements to guard a compiler directive in a comment. We can't fix one platform and than just break the build for another. From the Intel side there seems to be no solution (https://community.intel.com/t5/Intel-Fortran-Compiler/dllexport-Exporting-all-module-data-automatically/td-p/1153856). However, the recommendation is to create a script which parses the symbols dumped by some mean and turn them into a |
the |
Agreed, I definitely wouldn't want to fix one build just to break another or cause a big game of chasing down bugs introduced by fixes intended for another build. I'm using ifort/msvc in a mingw environment, which was why adding the attributes worked for me. If I can't find a fix that doesn't break other builds, I'm fine with just using a patched version locally. Or since this compiler combination hasn't worked on Unix machines, just supporting/allowing it for Windows (only under the condition that the fixes don't break any existing build).
But I would assume based on it being a remark, rather than a warning or error, that these attributes are simply ignored. The Meson build displays the same messages and goes through just fine. |
I see, it is a linking error due to CMake failing to properly detect BLAS and LAPACK. |
2 participants
This commit adds DLLEXPORT attributes to the subroutines needed for
the api and app to compile
Signed-off-by: Ty [email protected]