Building ASCEND for 64-bit Windows: Difference between revisions

From ASCEND
Jump to navigation Jump to search
← Older editNewer edit →
Line 156: Line 156:
w.show()
w.show()
</pre>
</pre>
Some helpful diagnostics for finding out why 'import gtk' gives errors in some cases: (in my case, I needed to add c:/GTK/bin to the START of my PATH because of a conflicting ZLIB1.DLL earlier in my PATH.
* http://gramps-project.org/wiki/index.php?title=ImportError:_DLL_load_failed


Some optional components that will allow the ASCEND GUI to do more:
Some optional components that will allow the ASCEND GUI to do more:

Revision as of 18:51, 4 February 2012

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
  • From the MSYS prompt, edit /etc/fstab so that 'c:/MinGW64' is mapped to '/mingw'
  • install 64-bit Python 2.7.2
  • download and install the SlikSvn 64-bit client.
  • append /c/Python27 and /c/Python27/Scripts and SlikSvn to the PATH in MSYS. Also, set an environment variable HOST_PREFIX for the MinGW-w64 compiler (to be used by our SCons script). A good way is by creating the file ~/.profile
export PATH="$PATH:/c/Python27:/c/Python27/Scripts:/c/Program Files/SlikSvn/bin"
export HOST_PREFIX=x86_64-w64-mingw32
  • download and extract source tarball for SCons 2.1.0. Build via python setup.py bdist_wininst then install resulting .exe in dist subfolder.
  • install 'findutils' by unpacking findutils-4.4.2-2-msys-1.0.13-bin.tar.lzma and unpacking into c:\msys

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.
  • 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.
  • there are 'multilib' versions of MinGW-w64 that might be good to look at.
  • some issue on one of my machines with missing 'shell32' and 'user32' with MinGW-w64... why?

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 configuration issue? looks like the parser is waiting for input from stdin)
    • compiler_blackbox (lacking error code in return from parse. not Win64 specific)

Check the current build status on our buildbot.

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. The python27.lib file distributed with Python doesn't work with MinGW-w64 (or maybe even for MinGW32?). To build gendef, we used revision r4724 from here (click 'download GNU tarball').

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

Next, run gendef as follows. 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?)

Firstly, as per python bug 4709, in c:\Python26\include\pyconfig.h, you need to move the following lines, 

#ifdef _WIN64
#define MS_WIN64
#endif

further up the file, to just before the #ifdef _MSC_VER in line 107.

Earlier, we thought that you also needed to patch the Python include file 'modsupport.h'. We don't think that's necessary now, if the above patch is made.

Install SWIGWIN 1.3.40 to c:\MinGW\swigwin-1.3.40 and add it to your MSYS PATH. Note that (bug 494) there is currently a bug in SWIG 2.x that prevents us from using it. It looks like that SWIG bug is fixed in their code, but we have to wait for the SWIG 2.0.5 release.

You can now build the ASCEND Python module, ascpy. It seems to work, but as of writing, there is a crash in the GUI when instantiating a model. It might be that there are still some errors in relation with 64-bit data types, possibly in the ascxx code. With the above, ./test.py TestSolver.testsunpos6 loads and solves a model correctly! Python bindings at least partly operational! Also, pygtk/ascdev models/test/ipopt/test6.a4c seems to work too.

Notes about Python with MinGW-w64

There seem to be warnings on the net about MinGW and MinGW-w64 used with SWIG. It has always worked fine for us on Win32, but maybe there are new issues arising. To test this, here is a simple 'hello world' example SWIG module. It works on Ubuntu 11.10 32-bit, and builds fine on Win7 64-bit, but fails with a segfault when exiting.

swigtest.tar.gz (900 byte tarball)

MinGW-w64 can build (without SWIG) against Python 2.7 for at least trivial bindings... we can prove it. A simple example that takes a string, prints it, and calculates its length, seems to work fine:

pytest.tar.gz (1.1k tarball)

Both of the above tests work fine if the patch from python bug 4709 is applied to your installed Python pyconfig.h header file.

Other pages on MinGW with Python:

Cunit

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

Runtime requirements

To actually run the GUI resulting from the above build, you still need to install GTK+, PyGTK, PyCairo, PyGObject. Get the amd64 py2.7 packages from this page:

  • http://www.lfd.uci.edu/~gohlke/pythonlibs
    • py2cairo-1.10.0.win-amd64-py2.7.‌exe
    • pygobject-2.28.6.win-amd64-py2.7.‌exe
    • pygtk-2.22.0.win-amd64-py2.7.‌exe
    • run these 'as administrator' by right-click from Windows Explorer.

To test the above:

    • gtk-demo.exe should work and pop up a window with some GUI demos
    • start up Python and try
import gtk

w = gtk.Window() w.add(gtk.Label("hello")) w.show()

Some helpful diagnostics for finding out why 'import gtk' gives errors in some cases: (in my case, I needed to add c:/GTK/bin to the START of my PATH because of a conflicting ZLIB1.DLL earlier in my PATH.

Some optional components that will allow the ASCEND GUI to do more:

Retrieved from "https://ascend4.org/index.php?title=Building_ASCEND_for_64-bit_Windows&oldid=3235"