Porting Open Source HPC Software to Microsoft Windows Platforms
As we started with the porting of OpenFOAM Symscape released some patches to build a windows version of OpenFOAM with a mingw cross compiler. As these patches among other things abstract the OS specific things into a separated library we have based our work on these patches. The patches and a description of them are available at the Symscape webpage: www.symscape.com/openfoam-on-windows.
We have categorized the porting issues in to three scopes, the Build System, which also contains files system issues, OS specific things and compiler and linker issues. The issues are described together with our solution.
The most OS specific issues have been resolved by the patches from Symscape. There are however a few things left:
The port of OpenFOAM from gcc to the Microsoft Visual Studio 2008 compiler has caused various compiler errors. The fixes for them can be extracted from a patch file which will be available on request. The name resolution of the Microsoft compiler however was a reoccurring problem. To give two examples:
There was an ambiguous access to IOdictionary in dynamikInkJetFvMesh.C
There have been problems with different instantiations of HashTable (HashTableI.H, HashTable.H, HashTable.C), e.g. operator()() cannot be distinguished between different types. This has lead to linker errors because the symbols got stripped during linking.
The solution for this compiler errors have been: explicit specilization, explicit inlining or being more explicit with the names, e.g. calling a constructor with IOdictionary:: IOdictionary instead of IOdictionary.
Other Issues that are worth mentioning are:
Visual Studio 2008 does not support the C99 feature variable length arrays.
The uses of variable length arrays have been replaced with alloca, malloc and free calls, e.g. in processorLduInterfaceTemplates.C.
OpenFOAM uses the following keywords of the Visual Studio 2008 C++ compiler: near, far (e.g. in treeBoundBox.C) and DELETE (in topoSetSource.C, ...)
The entities with the name of a compiler keyword have been renamed.
Microsoft does not deliver bcrt (Cube root) in math.h with the C standard library.
We use bcrt from the Intel Math Kernel Library.
Porting shared libraries from UNIX/Linux to Windows is a lot of work, because all symbols of a shared library need to be explicitly exported for the Microsoft tool chain.
To bring this proof of concept we first build a statically linked version. The major drawback of this approach is less flexibility for user routines.
The static linked version has introduced a new problem, because the linker does not include unreferenced objects into the executable and OpenFOAM uses dynamic run time selection tables to select solvers. Therefore some modules needed for our test case have not been available during execution.
To make our test case run we have added the needed but striped object files explicitly to the linker command line to force the inclusion into the executable. This step however needs to be repeated for all cases which use different modules, so a dynamically linked version is absolutely necessary.
A project by Fraunhofer SCAI