- Minimum version
- Host setup
- Run-time setup
- Known limitations (2020-06-16)
Windows 64bit binaries can be generated on 64bit Linux using the mingw compiler for cross-compilation.
The mingw cross-compiler should be at least version 8.2.0 (tested) or slightly older. Versions that are much older may have faulty regex implementations.
On openSUSE use the packages for compilation:
zypper in mingw64-cross-binutils zypper in mingw64-cross-cpp mingw64-cross-gcc mingw64-cross-gcc-c++ zypper in mingw64-filesystem mingw64-headers mingw64-runtime zypper in mingw64-libwinpthread1 mingw64-winpthreads-devel zypper in mingw64-libfftw3 mingw64-fftw3-devel zypper in mingw64-libz mingw64-zlib-devel
For CentOS/RedHat, the cross-compiler is available under
dnf config-manager --set-enabled PowerTools
The package names to install are somewhat different from the openSUSE ones:
dnf install mingw64-gcc-c++ dnf install mingw64-winpthreads mingw64-zlib
Notably, many of the development packages are simply rolled into the runtime ones. There does not seem to be an FFTW package readily available.
If there are issues with zlib, it is possible to download it manually and compile as a static library.
CC="$(wmake -show-c)" CFLAGS="$(wmake -show-cflags)" ./configure --static make
The resulting output files (zconf.h, zlib.h) and (libz.a) either need
to be installed in system locations where OpenFOAM can find them, or if
they are to be shipped directly with OpenFOAM, they can also be placed
If the header files are only needed during compilation, it can be a
fairly convenient hack to simply place copies of them in the
Flex is used in a few locations within OpenFOAM for generating code.
The generated C++ code requires the
FlexLexer.h header file, but
/usr/include location will be ignored by the cross-compiler.
As another ugly hack, a copy of this file can be made in a standard project include location. For example,
ln -s /usr/include/FlexLexer.h src/OSspecific/MSwindows
The last point to consider when cross-compiling is the behaviour of
the OpenFOAM wmake toolchain used during compilation. These are found
wmake/src. If the
Makefile is used directly, executables
will be created that work on the target platform (Windows), but not
on the host platform (which is what is required). This is addressed
directly by the
wmake/src/Allmake script, which will use the system
gcc to create host binaries for the wmake toolchain. If, for some
reason, you also require target wmake toolchain binaries, you will
need to invoke
make manually within the
The settings for cross-compilation are normally defined in the
etc/prefs.sh file with contents like this:
# For mingw cross-compile export WM_COMPILER=Mingw export WM_MPLIB=MSMPI export WM_LABEL_SIZE=32 # other settings...
Additional adjustments may be required in some other places. For example
fftw_version=fftw-system export FFTW_ARCH_PATH=/usr/x86_64-w64-mingw32/sys-root/mingw
When running, the
WM_PROJECT_DIR environment must be set.
OpenFOAM will otherwise not be able to locate its files.
If running with MSYS2, make certain to set the following environmental control (preferrably for all users):
For the cross-compiled executables and libraries to work, the corresponding runtime libraries are required. These will need to be copied across from the Linux host system to the target machine. On openSUSE these runtime libraries are provided by the packages:
mingw64-libgcc_s_seh1 mingw64-libstdc++6 mingw64-libz mingw64-libwinpthread1
Both for CentOS/RedHat and for openSUSE, this roughly corresponds to the entire directory contents:
Known limitations (2020-06-16)
- kahip does not build
- ptscotch does not build
- boost should build ok, but no CGAL support (ie, no foamyHexMesh)
- no ParaView plugin, runTimePostProcessing
- reacting EulerFoam solvers have too many interdependencies and do
not yet compile cleanly.
It is advisable to compile with the wmake
-koption to keep going even when the EulerFoam solvers fail to compile.
Copyright (C) 2020 OpenCFD Ltd.