Shared Fortran / C++ libraries on Windows

Windows has particular linking requirements for shared libraries that can become challenging with MSVC-like compilers such as Intel oneAPI when linking Fortran and C libraries together. In short, the workaround is to use static libraries instead of shared libraries for such cases on Windows.

Example: MUMPS-superbuild project provides MUMPS libraries in the same way as the original MUMPS project’s Makefiles, that is with a library called “mumps_common” and then a library for each of 4 numerical precisions “smumps”, “dmumps”, “cmumps”, and “zmumps” that link against “mumps_common”. This is quite robust across compilers and linkers - the only issue is on Windows with oneAPI when building shared libraries.

Building shared libraries for MUMPS-superbuild is done by:

cmake --workflow shared

Most unresolved externals with oneAPI on Windows were symbols like:

MUMPS_BUF_COMMON_mp_...
MUMPS_OOC_COMMON_mp_...
MUMPS_LR_COMMON_mp_...
MUMPS_LR_STATS_mp_...

A first hypothesis was that auto-export was incomplete. CMake on Windows can auto-export symbols via CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS. In mixed C and Fortran projects, that is often good enough. Given the unresolved names, it was reasonable to suspect missing DATA exports from mumps_common.dll.

We ran a few checks to diagnose:

  1. Inspected linker diagnostics to collect unresolved symbol families.
  2. Inspected generated export definition .def files to see what CMake actually exported.
  3. Compared expected names versus actual exports in the produced DLL/import library path.
  4. Tested oneAPI-specific compile/link flag ideas.

Auto-export did miss symbols that appeared in unresolved lists. But even after supplementing exports, unresolved externals persisted. We tested multiple fixes, including:

  • Supplemental export definitions for missing DATA symbols.
  • oneAPI flag experiments intended to improve dynamic common/module handling.
  • Internal bridge-style link topology changes.

Why these were rejected:

  • Supplemental exports alone did not clear unresolved module-data references.
  • oneAPI flag experiments were either ineffective or unstable for this build.
  • Bridge-link approaches can alter expected import-library behavior and create downstream risk for users linking mumps_common.lib.

The root cause appears to be broader than CMAKE_WINDOWS_EXPORT_ALL_SYMBOLS. Auto-export can be incomplete, but even with explicit extra exports, oneAPI Fortran on Windows still struggled to resolve cross-DLL module/common data references in this configuration.

Practical recommendations

To maintain mixed Fortran/C HPC packaging across compilers, validate shared-library topology on every target compiler, especially Windows. Treat Fortran module/common data across Windows DLL boundaries as a first-class risk. To keep it simple - use static libraries.