Building ASCEND for 64-bit Windows

From ASCEND
Jump to navigation Jump to search

We now have a working version of ASCEND on 64-bit Windows. There's not yet a fully-functional installer, so you will still need to build your own copy from source.

Steps to build ASCEND for 64-bit Windows

We need a complete set of 64-bit build tools, plus 64-bit Python before we can get started:

  • install MSYS bundle to c:\msys as instructed here (I chose 'MSYS-20111123.zip')
  • 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

If the build enviromnent is set up, should then be able to follow the standard instructions to get a copy of the ASCEND code from 'trunk' in our repository then build it with:

  • now run 'scons -j4'

Things to check:

  • if you already have MinGW on your system the above instructions will need tweaking. We have only tried this on a system without Python or MinGW already installed.
  • be sure you have the 64-bit Python package.
  • the above will build just 'libascend'. For the CUnit test suite, other solvers, and the GUI, please read on.

We still want to check/look into:

  • can we set up a MinGW/MinGW-w64 combined build environment and build both 32- and 64-bit versions on that same machine? Can Python 32-bit and 64-bit coexist? Can we install 32- and 64-bit versions of all the Python modules, and GTK as well?
  • rather than using the big bundle MSYS that is provided by the MinGW-w64 project, we should try to use 'standard' MinGW-get-inst for the MSYS portion, and load MinGW-w64 on top of that. Makes obtaining minor utilities like 'find' and 'autoconf' much easier.
  • our build tools can be 32-bit, even if the build target is 64-bit.

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 branch 'mingw64' 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, if the runtime dependencies listed below are first installed.

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 (again I needed to edit the script to switch 'ftp' to 'http'.
  • ./configure --enable-static=yes --enable-shared=no --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_PREFIX=/mingw IPOPT_LIBS=ipopt,coinmumps,coinmetis,coinlapack,coinblas,gfortran,stdc++

The above seems to work fine, except that it results (on my system) in dynamic link to libgfortran-3.dll, libquadmath-0.dll, libstdc++-6.dll and libgcc_s_sjlj0.dll all of which must be satisfied at runtime in order for IPOPT to work. We can (and have succeeded to) include those dependencies with the ASCEND installer, but they total an additional 12 MB which we would rather avoid.

To build the ASCEND installer in that case, we use 

scons IPOPT_DLL1=... IPOPT_DLL2=.... IPOPT_DLL3=... IPOPT_DLL4=... installer

where the '...' correspond to the full path to the required DLLs on your particular system. On mine they were in /mingw/lib/i686-w64-mingw32/lib or something like that.

We would like to remove the need for these extra DLLs. One approach would be to link statically to them, but it doesn't seem to work. We tried building IPOPT 3.10.2 with 

 ./configure --enable-shared=no --enable-static=yes FFLAGS="-static-libgfortran" CFLAFGS="-static-libgcc" CXXFLAGS="-static-libstdc++ -static-libgcc" --host=x86_64-w64-mingw32 --prefix=/mingw

but even with all that stuff, the links were still present when it came to creating the ascend_ipopt.dll file.

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:

To test the above:

  • c:\GTK\bin must be in your PATH when attempting to run anything that uses GTK.
  • gtk-demo.exe should work and pop up a window with some GUI demos
  • start up Python and try

Invalid language.

You need to specify a language like this: <source lang="html">...</source>

Supported languages for syntax highlighting:

a4c, abap, abc, abnf, actionscript, ada, agda, alan, algol, ampl, amtrix, applescript, arc, arm, as400cl, ascend, asciidoc, asp, aspect, assembler, ats, autohotkey, autoit, avenue, awk, ballerina, bat, bbcode, bcpl, bibtex, biferno, bison, blitzbasic, bms, bnf, boo, c, carbon, ceylon, charmm, chill, chpl, clean, clearbasic, clipper, clojure, clp, cmake, cobol, coffeescript, coldfusion, conf, cpp2, critic, crk, crystal, cs_block_regex, csharp, css, d, dart, delphi, diff, dockerfile, dts, dylan, ebnf, ebnf2, eiffel, elixir, elm, email, erb, erlang, euphoria, exapunks, excel, express, factor, fame, fasm, felix, fish, fortran77, fortran90, frink, fsharp, fstab, fx, gambas, gdb, gdscript, go, graphviz, haml, hare, haskell, haxe, hcl, html, httpd, hugo, icon, idl, idlang, inc_luatex, informix, ini, innosetup, interlis, io, jam, jasmin, java, javascript, js_regex, json, jsp, jsx, julia, kotlin, ldif, less, lhs, lilypond, limbo, lindenscript, lisp, logtalk, lotos, lotus, lua, luban, makefile, maple, markdown, matlab, maya, mercury, meson, miranda, mod2, mod3, modelica, moon, ms, msl, mssql, mxml, n3, nasal, nbc, nemerle, netrexx, nginx, nice, nim, nix, nsis, nxc, oberon, objc, ocaml, octave, oorexx, org, os, oz, paradox, pas, pdf, perl, php, pike, pl1, plperl, plpython, pltcl, po, polygen, pony, pov, powershell, pro, progress, ps, psl, pure, purebasic, purescript, pyrex, python, q, qmake, qml, qu, r, rebol, rego, rexx, rnc, rpg, rpl, rst, ruby, rust, s, sam, sas, scad, scala, scilab, scss, shellscript, slim, small, smalltalk, sml, snmp, snobol, solidity, spec, spn, sql, squirrel, styl, svg, swift, sybase, tcl, tcsh, terraform, tex, toml, tsql, tsx, ttcn3, txt, typescript, upc, vala, vb, verilog, vhd, vimscript, vue, wat, whiley, wren, xml, xpp, yaiff, yaml, yaml_ansible, yang, zig, znn

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:

Creating the installer

If you have NSIS installed on your system then you will be able to build working installer for ASCEND. It's a 32-bit installer that installs a 64-bit ASCEND library/executable/etc.

Before you can build the installer, you need to download the NSIS Inetc plugin, and extract the inetc.dll file into your c:\Program Files (x86)\NSIS plugins folder.

Some issues to address/check:

  • make sure no WoW3264Node confusions arise when trying to install 64-bit ASCEND on 64-bit Windows.
  • possible issue with IPOPT with 32-bit installer used on 64-bit Windows. Also check IPOPT with 64-bit version.
  • how to make sure that installed versions of GTK/Python etc are 64 bit and not 32-bit?
  • are there any issues with MSVCR90.DLL not being present? PyGTK seems to depend on it.
  • what happens when you try to install on Windows 32? does it fail gracefully?
  • consider including all required dependencies in the package: total size would be +~45MB (minus compression savings, minus optimisations from removing unneeded bits of GTK+?)
Retrieved from "https://ascend4.org/index.php?title=Building_ASCEND_for_64-bit_Windows&oldid=3749"