Building ASCEND for 64-bit Windows

There are a number of barriers to building ASCEND on 64-bit Windows:

• 'Standard' MinGW does not build 64-bit executables, so we need to use the MinGW-w64 compiler, which is a bit new.
• We need to switch to a true 64-bit Python in order to run 64-bit ASCEND.
• PyGTK for 64-bit may have some bugs (http://www.daa.com.au/pipermail/pygtk/2009-July/017278.html)
• Windows 64 uses 8-byte pointers (long long) which our code hasn't had to deal with up to now.

This page records our progress on getting up and running.

Steps to date

• install MSYS bundle to c:\msys as instructed here
• install MinGW-64 bundle to c:\mingw64 as instructed (we used mingw-w64-bin_i686-mingw_20111220.zip
• install 64-bit Python 2.7.2
• append /c/Python27 and /c/Python27/Scripts to the PATH in MSYS.
• download and extract source tarball for SCons 1.2.0. Build via python setup.py bdist_wininst then install resulting .exe in dist subfolder.
• create 'scons' file in c:\Python27\Scripts containing

#!/bin/sh
python /c/Python27/Scripts/scons.py $*

• svn checkout ASCEND source code (from trunk)
• scons

Things we need to work on:

• A lot of new compiler warnings due to the very new GCC version 4.7 used by MinGW-64 that will need to be worked through.
• Installing the MinGW-64 toolchain with 'standard' (local) tool filenames (maybe a quick script to rename or symlink them?)
• Detecting 32-bit vs 64-bit Windows?
• Detecting Python linker flags
• Building PyGTK etc for our version of Python
• Packaging it all (will NSIS 32-bit be OK to use?)
• Conversions between 'void *' and 'unsigned long' don't seem to work on Win64. Instead, Windows wants 'void *' to be cast to 'unsigned long long', since those pointers are the same size.
• Something strange happening with MMIO...?
• it's probably going to be better and easier to use the MSYS package from the MinGW project, and then to just overlay the Mingw-w64 files within that environment. Need to check that it works.
• there doesn't seem to be any harm in using a 32-bit compiler executable, even if the target is 64-bit.
• the python lib distributed with Python needs to be tweaked, see http://docs.python.org/install/index.html#gnu-c-cygwin-mingw

Test suite

• The CUnit test suites seem to be basically working. We have made changes to CUnit and currently require that you access the svn trunk version of CUnit for ASCEND testing. A new CUnit release is planned.
• Failing test cases:
  • compiler_autodiff (issue with a non-null pointer in line 198)
  • compiler_bintok (program hangs! possibly just a conifuration issue?)
  • solver_ipopt.formula (crashes, but all other tests are fine)
  • utilities_ascSignal (appears not to be an issue only with Win64)
  • compiler_blackbox (lacking error code in return from parse. not Win64 specific)

Python bindings

Before MinGW-w64 can link to Python27.dll, you need to download, build, and install a utility called 'gendef' which builds library *.DEF files that MinGW-w64 can use. We used revision r4724 from here (click 'download GNU tarball').

• ./configure --host=x86_64-w64-mingw32 --prefix=/mingw
• make -j4
• make install

Using Windows Explorer, copy the file c:\Windows\System32\Python27.dll into c:\Python27\Libs. Then, in MSYS,

• cd /c/Python27/Libs
• gendef Python27.dll
• mv Python27.lib OLD-Python27.lib (just in case?)

Next, you need to make a change to one of the Python header files. Around line 100 of c:\Python27\include\modsupport.h, add as shown:

#if SIZEOF_SIZE_T != SIZEOF_INT || defined(__WIN64__)
/* On a 64-bit system, rename the Py_InitModule4 so that 2.4
   modules cannot get loaded into a 2.5 interpreter */
#define Py_InitModule4 Py_InitModule4_64
#endif

Install SWIGWIN 1.3.40 to c:\MinGW\swigwin-1.3.40 and add it to your MSYS PATH.

You can now build the ASCEND Python module, ascpy, but as of writing, it doesn't yet work due to some issue with 'SwigIterator'.

Cunit

• use SVN trunk code
• ./configure --prefix=/mingw --host=x86_64-w64-mingw32 --build=mingw32
• make install

SUNDIALS

SUNDIALS is used by the IDA solver in ASCEND.

• ./configure --host=x86_64-w64-mingw32 --prefix=/mingw
• make -j4
• make install

IPOPT

• download and extract the 'findutils' lzma tarball from here; put the extract 'find.exe' and 'xargs.exe' into c:/msys/bin.
• download the source tarball for IPOPT 3.10.1
• cd ThirdParty/Blas && ./get.Blas (note that on my system I had to edit the URL in the get.Blas script to use "http:" instead of "ftp:")
• cd ThirdParty/Metis && ./get.Metis
• cd ThirdParty/Mumps && ./get.Mumps
• cd ThirdParty/Lapack && ./get.Lapack
• ./configure --host=x86_64-w64-mingw32 --prefix=/mingw
• make -j4
• make install

If the install works OK you should have some /mingw/libcoin* and /mingw/libipopt.a files.

This will build you a static IPOPT solver. There isn't a way to build a DLL of IPOPT with MinGW yet, apparently.

To get scons to detect this build of IPOPT, use

scons --config=force -j4 IPOPT_LIBPATH=/mingw/lib IPOPT_PREFIX=/mingw IPOPT_LIBS=ipopt,coinmumps,coinmetis,coinlapack,coinblas,gfortran,stdc++

The above seems to work fine, except that it results in a dynamic link to libgfortran-3.dll that must be satisfied at runtime in order for IPOPT to work. Possibly a solution will be

F77FLAGS="-static" ./configure --host=x86_64-w64-mingw32 --prefix=/mingw

Wait and see if that works...

GDB

• Download the GDB package from the MinGW-64 site here (we chose http://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/gdb/x86_64-w64-mingw32-gdb-7.1.90.20100730.zip/download x86_64-w64-mingw32-gdb-7.1.90.20100730.zip])
• Building GDB from source tarball version 7.3.1 worked OK but the resulting GDB didn't recognise/load symbols from the running executable. So download the MinGW-64 pre-compiled version instead.