Building ASCEND for 64-bit Windows: Difference between revisions

From ASCEND
Jump to navigation Jump to search
 
(79 intermediate revisions by 2 users not shown)
Line 1: Line 1:
There are a number of barriers to building ASCEND on 64-bit Windows:
We now have a working version of ASCEND on 64-bit Windows. Before you can use these instructions, you need to carefully follow the rather long list of instructions for [[setting up a MinGW-w64 build environment]]. If you're interested in building ASCEND for other platforms, see [[building ASCEND]].


* 'Standard' MinGW does not build 64-bit executables, so we need to use the MinGW-w64 compiler, which is a bit new.
== Compile-time prerequisites ==
* 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.
=== CUnit testing library ===


== Steps to date ==
Note the directions for building and installing CUnit as per [[Developer's Manual#CUnit test suites]]. For MinGW-w64 use the following steps:
cd ~
svn co svn://svn.code.sf.net/p/cunit/code/branches/mingw64 cunit
cd cunit
./configure --prefix=/mingw --enable-examples --enable-debug
make
make install


* install MSYS bundle to c:\msys as instructed [http://sourceforge.net/apps/trac/mingw-w64/wiki/MSYS here]
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.  
* install MinGW-64 bundle to c:\mingw64 as instructed (we used [http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-mingw_20111220.zip/download 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 <tt>python setup.py bdist_wininst</tt> 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)
* <tt>scons</tt>


Things we need to work on:
Currently, failing test cases on MinGW-w64 are:
** 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)
 
You may be able to check the current build status on our [http://build.ascend4.org buildbot].


* 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.
=== SUNDIALS ===
* 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.
SUNDIALS is used by the [[IDA]] solver in ASCEND. First download and save sundials-2.4.0 from  the [http://computation.llnl.gov/casc/sundials/download/download.html SUNDIALS download page]. Unpack, build and install as follows:
* 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 ==
tar zxf /c/Users/'''yourusername'''/Downloads/sundial-2.4.0.tar.gz
cd sundials-2.4.0
./configure --build=x86_64-w64-mingw32 --prefix=/mingw F77=gfortran
make
make install


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 [http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/trunk/mingw-w64-tools/gendef/ here] (click 'download GNU tarball').
SUNDIALS at v2.4.0 doesn't support <tt>DESTDIR=~/temp-install</tt> in the <tt>make install</tt> step, which is annoying becuase it's not quite as easy to 'catch' the installed files and distribute a binary.


* ./configure --host=x86_64-w64-mingw32 --prefix=/mingw
Note, for 32-bit, use <tt>./configure --prefix=/mingw F77=gfortran</tt> above. We need to test again whether the <tt>--build=x86_64-w64-mingw32</tt> part is needed for 64-bit builds, or not.
* 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,
=== IPOPT ===


* cd /c/Python27/Libs
[[IPOPT]] is a free open-source optimisation solver which can be accessed from ASCEND.
* gendef Python27.dll
* mv Python27.lib OLD-Python27.lib ''(just in case?)''


Next, you need to make a change to one of the Python 2.7 header files, because of incorrect detection of 64-bit Windows in their code. Around line 100 of c:\Python27\include\modsupport.h, add as shown:
* Download and unpack [http://www.coin-or.org/download/source/Ipopt/Ipopt-3.11.3.tgz Ipopt-3.11.3.tgz]:
cd ~
wget http://www.coin-or.org/download/source/Ipopt/Ipopt-3.11.3.tgz
tar zxf Ipopt-3.11.3.tgz
cd Ipopt-3.11.3
* Download the third-party dependencies
cd ThirdParty/Blas && ./get.Blas
cd ../Metis && ./get.Metis
cd ../Mumps && ./get.Mumps
cd ../Lapack && ./get.Lapack
* Configure and build IPOPT (configuration takes a several minutes, building takes ~15 min or so):
cd ~/Ipopt-3.11.3
./configure --enable-static=yes --enable-shared=no --prefix=/mingw ADD_FFLAGS="-fopenmp -static-libgcc" --disable-pthread-mumps
make
make install
make test


#if SIZEOF_SIZE_T != SIZEOF_INT <font color=DarkGreen>'''''|| defined(__WIN64__)'''''</font>
Note: above <tt>./configure</tt> command is a special workaround for 64-bit Windows. Thanks for Stefan Vigerske and Tony Kelman for their help with these instructions (and for [http://www.mpclab.net/Trac/wiki/CompilingIpopt#MinGW this page]), and for the suggested changes to our [[Setting up a MinGW-w64 build environment|MinGW-w64 set-up guidelines]]. See also [https://projects.coin-or.org/Ipopt/ticket/215 IPOPT bug 215]. It is probable that on 32-bit, a simpler command without the 'ADD_FFLAGS' will work OK, but it may change the resulting DLL dependencies of the final DLL/executables.
/* 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.
If the install works OK you should have some /mingw/libcoin* and /mingw/libipopt.a files.


You can now build the ASCEND Python module, <tt>ascpy</tt>, but as of writing, it doesn't yet work due to some issue with 'SwigIterator'.
This will build you a static IPOPT solver. There isn't a way to build a DLL of IPOPT with MinGW yet, apparently (although the static libary for IPOPT can be incorporated into a DLL as we have done for our [[IPOPT]] external solver in ASCEND).


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.
Currently the resulting IPOPT depends on libgfortran and libstdc++. If you build the resulting static libraries into a DLL or an EXE, that DLL/EXE will have shared library dependencies on the ligfortran and libstdc++ DLLs that come with MinGW/MinGW-w64. We would rather like to have the code from of those external DLLs statically linked, but don't yet know how that's possible.


'''[[Media:swigtest.tar.gz|swigtest.tar.gz]]''' (900 byte tarball)
== Building ASCEND ==


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:
If your [[Setting up a MinGW-w64 build environment|Windows build environment]] is set up correctly, and you have a current copy of the source code (either from [[VersionManagement|our subversion repository]] or a source-code tarball), you should be able to simply run:


'''[[Media:pytest.tar.gz|pytest.tar.gz]]''' (1.1k tarball)
scons -j4


== Cunit ==
If your environment is set up correctly, your build should complete correctly on both 64-bit and 32-bit build environments.


* use SVN trunk code
To run test suites, try
* <tt>./configure --prefix=/mingw --host=x86_64-w64-mingw32 --build=mingw32</tt>
* make install


== SUNDIALS ==
scons test ascend solvers models
test/test_expectpass


SUNDIALS is used by the [[IDA]] solver in ASCEND.
This script should run all the test cases currently expected to pass. You can also try


* <tt>./configure --host=x86_64-w64-mingw32 --prefix=/mingw</tt>
scons test ascend solvers models MALLOC_DEBUG=1
* <tt>make -j4</tt>
test/test_expectpass_mallocdebug
* <tt>make install</tt>


== IPOPT ==
to test those functions which require malloc debugging to also be tested.  This latter set of tests removes some other ones because of known memory leakage.


* download and extract the 'findutils' lzma tarball from [http://sourceforge.net/projects/mingw/files/MSYS/Base/findutils/findutils-4.4.2-2/findutils-4.4.2-2-msys-1.0.13-bin.tar.lzma/download here]; put the extract 'find.exe' and 'xargs.exe' into c:/msys/bin.
== Runtime prerequisites ==
* download the source tarball for IPOPT 3.10.1
* <tt>cd ThirdParty/Blas && ./get.Blas </tt> (note that on my system I had to edit the URL in the <tt>get.Blas</tt> script to use "http:" instead of "ftp:")
* <tt>cd ThirdParty/Metis && ./get.Metis</tt>
* <tt>cd ThirdParty/Mumps && ./get.Mumps</tt>
* <tt>cd ThirdParty/Lapack && ./get.Lapack</tt>
* <tt>./configure --host=x86_64-w64-mingw32 --prefix=/mingw</tt>
* <tt>make -j4</tt>
* <tt>make install</tt>


If the install works OK you should have some /mingw/libcoin* and /mingw/libipopt.a files.
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:


This will build you a static IPOPT solver. There isn't a way to build a DLL of IPOPT with MinGW yet, apparently.
* Install GTK+2 as detailed in [[setting up a MinGW-w64 build environment]].
* From the [http://sourceforge.net/projects/ascend-sim/files/thirdparty/ ASCEND third-party download page], download and install:
** [http://sourceforge.net/projects/ascend-sim/files/thirdparty/pygtk-2.22.0.win-amd64-py2.7.exe/download pygtk-2.22.0.win-amd64-py2.7.exe]
** [http://sourceforge.net/projects/ascend-sim/files/thirdparty/pygobject-2.28.6.win-amd64-py2.7.exe/download pygobject-2.28.6.win-amd64-py2.7.exe]
** [http://sourceforge.net/projects/ascend-sim/files/thirdparty/py2cairo-1.10.0.win-amd64-py2.7.exe/download py2cairo-1.10.0.win-amd64-py2.7.exe]
* In order to have plotting and console support in the PyGTK GUI, Download and install the following Python packages from http://www.lfd.uci.edu/~gohlke/pythonlibs (sorry, this website doesn't allow direct URL links). Be sure to use the'''win-amd64-py2.7''' versions for 64-bit Python, or the '''win32-py2.7''' files for 32-bit Python:
** six (required for dateutil)
** pyparsing (required for matplotlib)
** dateutil (required for matplotlib)
** numpy-MKL (required for matplotlib)
** matplotlib (optional)
** setuptools (required for ipython)
** pyreadline (required for ipython)
** ipython (optional)


To get <tt>scons</tt> to detect this build of IPOPT, use
To test the above:
* You should be able to start IPython (pylab mode) from the Start menu, without any errors output
* c:\Program Files\GTK+-2.22\bin\gtk-demo.exe should run from the windows command prompt, and pop up a window with some GUI demos
* After setting your PATH to include <tt>c:\Program Files\GTK+-2.22\bin</tt> (and possibly log out and log in again) you should be able to start Python and try:
<source lang=py>import gtk
w = gtk.Window()
w.add(gtk.Label("hello"))
w.show_all()
</source>


scons --config=force -j4 IPOPT_LIBPATH=/mingw/lib IPOPT_PREFIX=/mingw IPOPT_LIBS=ipopt,coinmumps,coinmetis,coinlapack,coinblas,gfortran,stdc++
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


The above seems to work fine, except that it results in a dynamic link to <tt>libgfortran-3.dll</tt> that must be satisfied at runtime in order for IPOPT to work. Possibly a solution will be
== Building the ASCEND installer ==


F77FLAGS="-static" ./configure --host=x86_64-w64-mingw32 --prefix=/mingw
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.


Wait and see if that works...
Before you can build the installer, you need to download the NSIS [http://nsis.sourceforge.net/Inetc_plug-in Inetc plugin], and extract the inetc.dll file into your <tt>c:\Program Files (x86)\NSIS</tt> plugins folder.


== GDB ==
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+?)


* Download the GDB package from the MinGW-64 site [https://sourceforge.net/projects/mingw-w64/files/External%20binary%20packages%20%28Win64%20hosted%29/gdb/ 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])
[[Category:Development]]
* 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.

Latest revision as of 07:42, 5 December 2013

We now have a working version of ASCEND on 64-bit Windows. Before you can use these instructions, you need to carefully follow the rather long list of instructions for setting up a MinGW-w64 build environment. If you're interested in building ASCEND for other platforms, see building ASCEND.

Compile-time prerequisites

CUnit testing library

Note the directions for building and installing CUnit as per Developer's Manual#CUnit test suites. For MinGW-w64 use the following steps:

cd ~
svn co svn://svn.code.sf.net/p/cunit/code/branches/mingw64 cunit
cd cunit
./configure --prefix=/mingw --enable-examples --enable-debug
make
make install

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.

Currently, failing test cases on MinGW-w64 are:

    • 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)

You may be able to check the current build status on our buildbot.

SUNDIALS

SUNDIALS is used by the IDA solver in ASCEND. First download and save sundials-2.4.0 from the SUNDIALS download page. Unpack, build and install as follows:

tar zxf /c/Users/yourusername/Downloads/sundial-2.4.0.tar.gz
cd sundials-2.4.0
./configure --build=x86_64-w64-mingw32 --prefix=/mingw F77=gfortran
make
make install

SUNDIALS at v2.4.0 doesn't support DESTDIR=~/temp-install in the make install step, which is annoying becuase it's not quite as easy to 'catch' the installed files and distribute a binary.

Note, for 32-bit, use ./configure --prefix=/mingw F77=gfortran above. We need to test again whether the --build=x86_64-w64-mingw32 part is needed for 64-bit builds, or not.

IPOPT

IPOPT is a free open-source optimisation solver which can be accessed from ASCEND.

cd ~
wget http://www.coin-or.org/download/source/Ipopt/Ipopt-3.11.3.tgz 
tar zxf Ipopt-3.11.3.tgz
cd Ipopt-3.11.3
  • Download the third-party dependencies
cd ThirdParty/Blas && ./get.Blas
cd ../Metis && ./get.Metis
cd ../Mumps && ./get.Mumps
cd ../Lapack && ./get.Lapack
  • Configure and build IPOPT (configuration takes a several minutes, building takes ~15 min or so):
cd ~/Ipopt-3.11.3
./configure --enable-static=yes --enable-shared=no --prefix=/mingw ADD_FFLAGS="-fopenmp -static-libgcc" --disable-pthread-mumps
make
make install
make test

Note: above ./configure command is a special workaround for 64-bit Windows. Thanks for Stefan Vigerske and Tony Kelman for their help with these instructions (and for this page), and for the suggested changes to our MinGW-w64 set-up guidelines. See also IPOPT bug 215. It is probable that on 32-bit, a simpler command without the 'ADD_FFLAGS' will work OK, but it may change the resulting DLL dependencies of the final DLL/executables.

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 (although the static libary for IPOPT can be incorporated into a DLL as we have done for our IPOPT external solver in ASCEND).

Currently the resulting IPOPT depends on libgfortran and libstdc++. If you build the resulting static libraries into a DLL or an EXE, that DLL/EXE will have shared library dependencies on the ligfortran and libstdc++ DLLs that come with MinGW/MinGW-w64. We would rather like to have the code from of those external DLLs statically linked, but don't yet know how that's possible.

Building ASCEND

If your Windows build environment is set up correctly, and you have a current copy of the source code (either from our subversion repository or a source-code tarball), you should be able to simply run:

scons -j4

If your environment is set up correctly, your build should complete correctly on both 64-bit and 32-bit build environments.

To run test suites, try

scons test ascend solvers models
test/test_expectpass

This script should run all the test cases currently expected to pass. You can also try

scons test ascend solvers models MALLOC_DEBUG=1
test/test_expectpass_mallocdebug

to test those functions which require malloc debugging to also be tested. This latter set of tests removes some other ones because of known memory leakage.

Runtime prerequisites

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:

  • You should be able to start IPython (pylab mode) from the Start menu, without any errors output
  • c:\Program Files\GTK+-2.22\bin\gtk-demo.exe should run from the windows command prompt, and pop up a window with some GUI demos
  • After setting your PATH to include c:\Program Files\GTK+-2.22\bin (and possibly log out and log in again) you should be able to start 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.

Building the ASCEND 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+?)