Project

General

Profile

Bug #448

Building in MinGW

Added by Kyle Beauchamp over 9 years ago. Updated about 5 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
mdrun
Target version:
Affected version - extra info:
Affected version:
Difficulty:
uncategorized
Close

Description

Because a lot of us prefer to live in a Linux environment, it might be useful to be able to cross-compile for windows using MinGW. It appears that doing this requires a few minor tricks and a couple of easy patches. I am attaching my instructions to do this (tested on GIT version from June 17, 2010 on a ubuntu64 10.04 box). My changes to CMakeLists will likely need slight modifications to play nicely with the other platforms.

************
First, we need a CMAKE mingw toolchain file, such as the attached Toolchain-mingw.cmake. We also need the mingw cross-make scripts (attached, cross-make.sh). ************
git clone git://git.gromacs.org/gromacs.git
cd gromacs ************
emacs src/config.h.cmakein
Add this to end of file:
/*Define if compiling under MinGW platform*/
#cmakedefine MINGW ************
emacs CMakeLists.txt
Add these lines to beginning (after dart):
set(HAVE_UNISTD_H 0)
set(HAVE_GETTIMEOFDAY 0)
set(GMX_NO_NICE 1)
set(MINGW 1) ************
emacs include/vmdio.h
Add the following lines:
#ifndef SHGFP_TYPE_CURRENT
#define SHGFP_TYPE_CURRENT 0
#endif ************
emacs src/gmxlib/checkpoint.c
replace line 108:
#ifdef GMX_FAHCORE
with:
#if ((defined GMX_FAHCORE || defined MINGW)) ************
emacs src/gmxlib/futil.c
replace line 725:
#ifdef _MSC_VER
with:
#if ((defined _MSC_VER || defined MINGW)) ************
ccmake ./ -DCMAKE_TOOLCHAIN_FILE=/opt/mingw/Toolchain-mingw.cmake
Disable dlopen
Disable threads
Set fft to fftpack (fftw can be used, but requires an extra step) ************
cross-make.sh ************
wine can then be used to run the win32 executables under linux, or you can transport them to a native win32 system. ************
The changes to vmdio.h were required to avoid this error:
/mingw/gromacs/src/gmxlib/vmdio.c: In function ‘load_vmd_library’:
/mingw/gromacs/src/gmxlib/vmdio.c:235: error: ‘SHGFP_TYPE_CURRENT’ undeclared (first use in this function)
/mingw/gromacs/src/gmxlib/vmdio.c:235: error: (Each undeclared identifier is reported only once
/mingw/gromacs/src/gmxlib/vmdio.c:235: error: for each function it appears in.)
make2: * [src/gmxlib/CMakeFiles/gmx.dir/vmdio.c.obj] Error 1
make1:
[src/gmxlib/CMakeFiles/gmx.dir/all] Error 2
make: *
* [all] Error 2 ************
The changes to futil.c are required to avoid:
Scanning dependencies of target g_luck
[ 74%] Building C object src/kernel/CMakeFiles/g_luck.dir/g_luck.c.obj
Linking C executable g_luck.exe
../gmxlib/libgmx.a(futil.c.obj):futil.c:(.text+0x2e1): undefined reference to `_truncate'
../gmxlib/libgmx.a(checkpoint.c.obj):checkpoint.c:(.text+0x5ebb): undefined reference to `__chsize_s'
collect2: ld returned 1 exit status
make2: * [src/kernel/g_luck.exe] Error 1
make1:
[src/kernel/CMakeFiles/g_luck.dir/all] Error 2
make: *
* [all] Error 2 ************
The changes to checkpoint.c are required to avoid:
[ 74%] Building C object src/kernel/CMakeFiles/g_luck.dir/g_luck.c.obj
Linking C executable g_luck.exe
../gmxlib/libgmx.a(checkpoint.c.obj):checkpoint.c:(.text+0x5ebb): undefined reference to `__chsize_s'
collect2: ld returned 1 exit status
make2: * [src/kernel/g_luck.exe] Error 1
make1:
[src/kernel/CMakeFiles/g_luck.dir/all] Error 2
make: *
* [all] Error 2

Toolchain-mingw.cmake (587 Bytes) Toolchain-mingw.cmake toolchain file Kyle Beauchamp, 06/18/2010 03:33 AM
cross-make.sh (135 Bytes) cross-make.sh cross make Kyle Beauchamp, 06/18/2010 03:34 AM
mingw.patch (9.5 KB) mingw.patch Roland Schulz, 05/15/2011 12:44 PM

Associated revisions

Revision f2777b4a (diff)
Added by Roland Schulz over 5 years ago

Remove Cygwin+MingW from installguide

MingW was never supported (#448). And Cygwin is currently
not working. Until/Unless it is working the guide shouldn't
claim support.

Change-Id: I6558b95bc47b80f7d97a7960587e83e959682990

History

#1 Updated by Kyle Beauchamp over 9 years ago

Created an attachment (id=477)
toolchain file

#2 Updated by Kyle Beauchamp over 9 years ago

Created an attachment (id=478)
cross make

#3 Updated by Kyle Beauchamp over 9 years ago

What about using FFTW?

**********************
tar -zxvf fftw-3.2.2.tar.gz
cd fftw-3.2.2/
cross-configure.sh --enable-float -prefix=/vspm58/FAH-mingw/opt/ --disable-fortran
cross-make.sh
make install

go to gromacs directory

ccmake using previous protocol, but use fft=fftw3 this time. Give path to fftw. You'll need to add -L/path_to_fftw to CMAKE_CXX_FLAGS and CMAKE_C_FLAGS. You'll also need to add -lfftw3f to CMAKE_C_STANDARD_LIBRARIES and CMAKE_CXX_STANDARD_LIBRARIES (or some equivalent location).

PS I don't think I've been able to get GMX_THREADS working yet.

#4 Updated by Kyle Beauchamp over 9 years ago

What about threads? Although I'm not an expert on the threads-mpi code, it appears that getting threads to work may require somewhat more patching. It appears that the win32 headers and functions provided by mingw are not quite compatible with those used in the thread_windows gromacs code. For example, the type PINIT_ONCE is not defined in the mingw win32 headers, but is used in gromacs winthreads.c.

I suspect a workaround would be to use a more selective subset of the win32 function calls, but this is likely not worth the effort. Another method might be to use the mingw implementation of pthreads, but this creates a Chimera of sorts, in that the mingw build would include both unix-like and windows-like featuress.

My conclusions are:
1. Cross-compiling nonthreaded gromacs is easy and requires only a handful of trivial patches.
2. Cross-compiling threaded gromacs isn't quite as easy.

#5 Updated by Erik Lindahl over 9 years ago

Kyle,

Although this probably won't be any priority for us for 4.5, it would be nice to have it working.

What is the preferred thread mode under MinGW - windows threads or pthreads?

#6 Updated by Kyle Beauchamp over 9 years ago

I'm not sure. I do know that the mingw-posix threads implementation has its own sourceforge page, so the projects are fairly distinct. That makes me think that the mingw-posix threads are less-well supported.

#7 Updated by Sander Pronk over 9 years ago

(In reply to comment #6)

I'm not sure. I do know that the mingw-posix threads implementation has its
own sourceforge page, so the projects are fairly distinct. That makes me think
that the mingw-posix threads are less-well supported.

From what I understand, MingW can simply use the MS C library threading functions. In that case, thread_mpi could simply use that (it already supports MSVC and icc under Windows). Is it possible to use cmake with mingw, or do you always use configure?

#8 Updated by Kyle Beauchamp over 9 years ago

cmake works (provided you specify a mingw toolchain file at the command line).

In theory, I agree that windows calls to threading should work. However, I think that the mingw-windows headers only export a subset of the total win32 threading. I suspect that the mingw headers are missing a couple of things that we use. For example, this type (PINIT_ONCE) is not defined in the mingw headers, but is used in our win32 threads code.

I should also point out that I've run into some strange issues with my mingw builds, like segfaults during seemingly innocuous operations. My conclusion is that mingw is another imperfect build environment. IMHO, none of the windows build options (cygwin, mingw, MSVS+-ICC) is as friendly as gcc+linux. Of course, this is to be expected...

#9 Updated by Sander Pronk over 9 years ago

Actually, that variable is a holdover from when I was happily unaware of the fact that the useful thread-synchronization functions in Windows are post-Vista. I removed it from the current git master.

There's been a few bug fixes in the last 6 weeks that fixed segfaults in mdrun compiled on MSVC, so if you have the mingw build you might want to give it another try. At the moment, icc builds work best, though (I think).

#10 Updated by Rossen Apostolov about 9 years ago

Hi Kyle,

It will be great if someone could help with the support on that but we don't have the manpower at the moment. I'll change the status to LATER.

#11 Updated by Kyle Beauchamp about 9 years ago

I totally agree. Also, with the vast improvements Erik has made to windows builds, MinGW is not worth the extra effort.

#12 Updated by Roland Schulz over 8 years ago

This patch makes it possible to compile with MinGW. Not tested at all and some known bugs. Just adding it here so that if someone wants to work on it, he/she can use it as starting point.

#13 Updated by Gerrit Code Review Bot over 5 years ago

Gerrit received a related patchset '1' for Issue #448.
Uploader: Roland Schulz ()
Change-Id: I6558b95bc47b80f7d97a7960587e83e959682990
Gerrit URL: https://gerrit.gromacs.org/3194

#14 Updated by Roland Schulz about 5 years ago

  • Affected version set to 5.0

Also available in: Atom PDF