Building ASCEND for 64-bit Windows: Difference between revisions

Revision as of 20:51, 26 January 2012

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

PyGTK for 64-bit may have some bugs (http://www.daa.com.au/pipermail/pygtk/2009-July/017278.html)
SCons does not distribute an installer that works against 64-bit Python
Windows platform-specific code so far assumes 32-bit mode.

We are working towards fixing these items.

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 $*

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.
Suite 'utilities_ascEnvVar' current crashing.

Python bindings

Installed SWIG 1.3.40
Seems to be an issue with linking to python27.lib. The problem may be that described here, or it could be a 64-bit specific problem (or both). Perhaps we should try what happens with Python 2.5 alternatively.

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...?

SUNDIALS is used by the IDA solver in ASCEND.

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.

@@ Line 19: / Line 19: @@
 * svn checkout ASCEND source code (from trunk)
 * <tt>scons</tt>
 Test suite
-* The CUnit test suites seem to be basically working.
+* 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.
 * Suite 'utilities_ascEnvVar' current crashing.
@@ Line 33: / Line 32: @@
 Things we need to work on:
-* A lot of new compiler warnings due to the very new GCC version used by MinGW-64 that will need to be worked through.
+* 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 32-bit vs 64-bit Windows?
-* config.h.in etc for size of <tt>void *</tt> etc.
 * 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...?
 == Cunit ==