Windows Installer: Difference between revisions

From Octave
Jump to navigation Jump to search
(of-* packages now depend on Octave)
(→‎Testing using virtual machines: Add URL to more general VM test disc image)
(22 intermediate revisions by 3 users not shown)
Line 1: Line 1:
:''This article is about how to make the Windows installer; if you'd like just to use the installer, see [[Octave for Microsoft Windows]].''
:''This article is about how to make the Microsoft Windows installer; if you'd like just to use the installer, see [[Octave for Microsoft Windows]].''
GNU Octave is primarily developed on GNU/Linux and other POSIX conformal systems. There have been many efforts in the past to build ports of GNU Octave for Windows. Take a look at the various ports of Octave available for Windows [http://wiki.octave.org/Octave_for_Windows here].
GNU Octave is primarily developed on GNU/Linux and other POSIX compliant systems. There have been many efforts in the past to build ports of GNU Octave for Microsoft Windows.
This page contains instructions about creating a MS Windows installer using [[MXE|mxe-octave]] (a fork of [http://mxe.cc/ MXE]).
This means, '''the MS Windows installer is [https://en.wikipedia.org/wiki/Cross_compiler cross-compiled] using a GNU/Linux system'''.


Recently some work has been done in maintaining a unified build system [http://wiki.octave.org/MXE '''mxe-octave'''] (a fork of [http://mxe.cc/ MXE]) which anyone can use to produce cross as well as native builds of GNU Octave for Windows and Mac OS X platforms. This page contains instructions about creating a Windows installer using mxe-octave.
==Creating the MS Windows Installer==


==Steps to create Windows Installer==
===General steps===


# [http://wiki.octave.org/Windows_Installer#Installing_requirements_of_MXE_Octave Install all requirements of MXE Octave].
# Install the MXE build requirements.<ref>The requirements for each system are listed in the repository https://hg.octave.org/mxe-octave/file/tip/index.html.  Start with the second step to read the {{Path|index.html}} file on your local machine.</ref>
# <code>hg clone http://hg.octave.org/mxe-octave/</code>
# <code>hg clone https://hg.octave.org/mxe-octave</code><ref>Use <code>hg clone https://hg.octave.org/mxe-octave <name of mxe-octave build dir></code> to choose another directory.</ref>
# <code>cd mxe-octave</code>
# <code>cd mxe-octave</code>
# <code>./bootstrap</code>
# <code>./bootstrap</code>
Line 13: Line 15:
# <code>make all nsis-installer</code>
# <code>make all nsis-installer</code>


===Tweaks===
===Step details===


* Use <code>make all 7z-dist</code>, <code>make all tar-dist</code> or <code>make all zip-dist</code> instead of <code>make all nsis-installer</code> if you want to build just an archive of the files to install on Windows instead of an installer wizard.
====<code>./configure</code>====
* By default, packages will be built one at a time, but you may use <code>make JOBS=4</code> (choose a number other than 4 that is appropriate for your system) to build each package in parallel.  You may also combine this with the <code>-j</code> option for Make to build more than one package at a time, but be careful as using <code>make -j4 JOBS=4</code> can result in as many as 16 jobs running at once.
* Use <code>./configure --disable-strip-dist-files</code> if you want to keep debug symbols in the installed binaries for debugging on Windows. Beware as the total Octave distribution will be > 2 GB, the max. size for an NSIS installer. Your only options are to make 7z-dist, zip-dist or tar-dist installers.
* Include gdb in the installer by running <code>make gdb</code> before making the <code>nsis-installer</code> target.


===Creating Octave development versions for Windows with mxe-octave===
The current Microsoft Windows installers are build in three "flavors": for common 64- and 32-bit systems ('''"w64"''' and '''"w32"''') and for 64-bit systems exceeding 32 GB of main memory to store large data structures ('''"w64-64"''').
To roll your own octave for windows version with your favorite mods and patches, you can do as follows:


# Make the cross-build environment for Octave (=mxe-octave; see above)
{| class="wikitable"
# Build an Octave dist archive in Linux
! "w64" (recommended)
# Move that into mxe-octave and cross-build Octave + windows installer.
! "w64-64"
For ensuing builds after a first build, you'll only need to follow steps 2 + a little amended step 3 (see below)
! "w32"
|-style="vertical-align:top;"
| <pre style="min-width:330px;">
./configure                        \
  --enable-devel-tools            \
  --enable-binary-packages        \
  --with-ccache                    \
  --enable-octave=<octave version>
</pre>
| <pre style="min-width:330px;">
./configure                        \
  --enable-devel-tools            \
  --enable-binary-packages        \
  --with-ccache                    \
  --enable-octave=<octave version> \
  --enable-fortran-int64
</pre>
| <pre style="min-width:330px;">
./configure                        \
  --enable-devel-tools            \
  --enable-binary-packages        \
  --with-ccache                    \
  --enable-octave=<octave version> \
  --disable-windows-64
</pre>
|}


====Step 1: Prepare mxe-octave====
The individual options have the following meaning (see also <code>./configure --help</code>):
Clone the mxe-octave repo to some directory of your choice:
http://hg.octave.org/mxe-octave <name of mxe-octave build dir>
where <name of mxe-octave build dir> is some other name than just the default "mxe-octave".
Once downloaded, go into the <name of mxe-octave build dir> subdir and do:
./bootstrap
./configure <options you want>
make all nsis-installer JOBS=<some number>
Your author usually has "--enable-devel-tools --enable-octave=default --enable-binary-packages --enable-ccache" as configure options and use JOBS=7 on my core i5 system.
For stable branch it is "--enable-devel-tools --enable-octave=stable --enable-binary-packages --enable-64 --enable-fortran-int64 --enable-ccache" or "--enable-devel-tools --enable-octave=stable --enable-binary-packages --enable-windows64 --enable-ccache"
* The first configure option also includes gdb and an MSYS shell in the binary.
* The second avoids the ~700 MB max. array size limit for 32-bit executables but Octave will only run on 64-bit Windows (most Windows systems are 64 bit anyway these days). Note: this option does NOT imply 64-bit indexing.
* The third option is just for a placeholder; it'll invoke src/default-octave.mk (one of the three octave .mk files in mxe: src/stable-octave.mk and src/octave.mk, corresponding to the "--enable-octave=" configure option), I found that octave.mk lags a bit behind
* the fourth option cross-compiles the binary modules in Octave-Forge packages, which will save time when installing them once in Windows.
If you seriously want to work with gdb, also have --disable-strip-dist-files as configure option. However, in that case chances are that you cannot build an .exe installer anymore as it becomes too big for NSIS (that has a 2 GB installer file size limit) so instead of "make nsis-installer" you'll need to invoke
make zip-dist <options>
....and this results in all Octave dependencies being built in mxe-octave, plus (stable) Octave, plus an initial version of a binary Octave-Windows installer in the <mxe-octave build>/dist/ subdirectoy.


It can happen that you meet problems with Java. To build Octave with Java support built-in, mxe-octave needs:
* <code>--enable-devel-tools</code>: Include gdb and an MSYS shell in the binary.
* A Java JDK (Java Development Kit) on the '''host''' system. IOW, the javac (Java compiler) and jar (Java archiver) executables should be in the PATH.
** If you seriously want to work with gdb, you need <code>--disable-strip-dist-files</code> as configure option to keep debug symbols in the installed binaries for debugging on MS Windows. Beware as the total Octave distribution will be > 2 GB, the max. size for an NSIS installer. Your only options are to make 7z-dist, zip-dist or tar-dist installers.
* Java include files for windows (win32, even for w64 builds). They should reside in "<mxe-octave build dir>/usr/x86_64-w64-mingw32/include/java/win32". If not present, mxe-octave downloads them but this can occasionally go wrong. On a multi-boot system a solution (note: dirty hack warning!) is symlinking to the Windows include files on the Windows partition from the mxe-octave location.
* <code>--enable-binary-packages</code>: Cross-compile binary modules in [[Octave Forge]] packages. This saves time when installing them once the installation runs on Microsoft Windows. Furthermore, some packages require patches to cross-compile successfully (or with current Octave versions). Those additional patches would be missing when compiling the original packages from Octave Forge on Windows later on. Some Octave Forge packages require a working Octave during compilation. Therefore, the correct version(!) of Octave must be installed on the host system.
* <code>--with-ccache</code>: The usage of [https://ccache.dev/ ccache] may speed up repetitive compilation drastically.
* <code>--enable-octave=<octave version></code>: Build a specific version of GNU Octave, which can be one of:
** <code>release</code> use {{Path|src/release-octave.mk}}, download and build the latest GNU Octave release.
** <code>stable</code> or <code>default</code> uses {{Path|src/stable-octave.mk}} or {{Path|src/default-octave.mk}}, respectively. This builds from a self-created distribution tarball from the "stable" or "default" development branch of GNU Octave.  See [[#Build installers for Octave development versions|below]] for details.
* <code>--disable-windows-64</code>: Build for 32-bit MS Windows.
* <code>--enable-fortran-int64</code>: Use 64-bit integers in Fortran code and especially in numerical library code.  This option only affects the size of integers used in Fortran code like the BLAS and LAPACK libraries. On 64-bit systems, Octave always uses 64-bit integers for indexing and basic array operations.  See [[Enable large arrays: Build octave such that it can use arrays larger than 2Gb.|Enable large arrays]] for details.
* <code>--disable-system-opengl</code>: Include software OpenGL libraries. This might help when working with buggy graphics card drivers, but might be slower than hardware accelerated rendering.
* <code>--with-pkg-dir=../mxe-octave-pkg</code>: If you are working with several build trees, you can share a common package directory.


====Step 2: To build your first Octave-for Windows development version:====
====<code>make</code>====
* build Octave on Linux (in separate source and build trees) including your favorite mods and patches.
* once Octave runs fine in Linux (using make check and trying your mods using ./run-octave --gui & from the build dir, all of this still on the Linux side), do:
<code>make dist-lzip DIST_IGNORE_HG_STATE=1</code>
* This will produce a dist archive called "octave-<version>.tar.lz" in the top build directory.  Move or copy this dist archive to the <mxe-octave build>/pkg folder (or symlink to it from there)


Note that this step requires the Octave be configured with Java (i.e., you need javac and jar on your system).
* Use <code>make all 7z-dist</code>, <code>make all tar-dist</code> or <code>make all zip-dist</code> instead of <code>make all nsis-installer</code> if you want to build just an archive of the files to install on MS Windows instead of an installer wizard.
 
* By default, packages will be built one at a time, but you may use <code>make JOBS=4</code> (choose a number other than 4 that is appropriate for your system) to build each package in parallelYou may also combine this with the <code>-j</code> option for Make to build more than one package at a time, but be careful as using <code>make -j4 JOBS=4</code> can result in as many as 16 jobs running at once.
{{Note|If you skip this step, mxe-octave will build using the source available from from the [http://hydra.nixos.org/job/gnu/octave-default/tarball/latest/download hydra site].
* Include gdb in the installer by running <code>make gdb</code> before making the <code>nsis-installer</code> target.
This archive is always slightly behind the latest development branch of the source repository and is missing the metadata that indicates which Mercurial revision it was built from.}}
 
==== Step 3: Building the Octave installer====
* be sure to adapt <mxe-octave build>/src/default-octave.mk to read "## No Checksum" at the $(PKG)_CHECKSUM line and check octave version and archive type (tar.lz rather than tar.bz2). The checksum is only needed when you download a dist archive from the Internet, not so much when you copy it within your own home network, let alone your own computer.
* check if in the top of the main Makefile "default-octave" is mentioned for OCTAVE_TARGET rather than "stable-octave" of just "octave" (that name refers to the .mk filename in the src folder).
* ... and then run (in the <mxe-octave build> folder)
make all nsis-installer <options>
-or-
make all 7z-dist <options>
====Step 3A (second and later builds)====
For next builds, mxe-octave is already configured and all dependencies have been built so the only thing to do is having a new Octave version + installer built:
* move/copy the dist archive from step 2 into mxe-octave's pkg subdir
* in <mxe-octave build> root dir do:
touch src/default-octave.mk
(to be sure mxe-octave picks up the new Octave archive). If you've renamed the dist archive, be sure it matches with the package name in src/default-octave.mk.
Then do:
  make all nsis-installer
-or-
make all 7z-dist
====Step 4: Install on Windows====
* move the installer in <mxe-octave build>/dist/ to the Windows side (USB thumb drive, LAN copy, whatever).
* install it there.
If you've made a 7z-dist you'll have to manually create the desktop and Start Menu shortcuts (for octave and the MSYS-shell).


====Remarks====
* If you have several mxe-octave build dirs (for e.g., stable and several development versions) it is handy to have a separate pkg subdir symlinked to from all mxe-octave build dirs. That will save a lot of downloading bandwidth.
* As of late Dec 2015, mxe-octave allows out-of-tree builds, which makes it a lot easier to build separate Octave versions with the same mxe-octave tree. (See http://hg.octave.org/mxe-octave/rev/0962acdde3be)
* To keep mxe-octave up-to-date, from time to time do:
hg -v pull
hg -v update
* However, do not keep mxe-octave build dirs for too long. I'd suggest to wipe a build dir after at most two or three months and start over with a fresh clone a la Step 1.
* In the mean time, regularly clean up <mxe-octave build>/log to save disk space. After a first successful build there's no more use for the log subdirs for each package, so you can wipe them all.


====If things go wrong====
===Build installers for Octave development versions===
It is possible that, for example, the build of Octave in step 2 works but that if fails in step 3.  Here are some troubleshooting tips.
* The error message displayed by make is simply the last 10 lines of the log file.  This may truncate the actual error message.
* Sometimes running "make" a second time without changing anything will fix the problem.  In particular, autotools rebuilds some files in the first make which may cause the second make to succeed.
* If it is building Octave that failed, the source will be left in <mxe-octave build>/tmp-default-octave and it is possible to run "configure && make" in that directory.
* The configuration will be for the target system, not your own.  In particular, if you have not installed all of the packages that MXE-octave installs, then your configuration will be different.  However, some configuration variables will differ even if you have the same packages, and some compiler features may be available on the host system that are not available in cross-compile mode.
* A possible causes for build failure is having files in your local source or build directory that are not listed in the module.mk files; these are not copied into the dist archive.
* (philip, confirmed by oheim) On my core i5 desktop system with a fast SSD, mxe-octave builds usually fails at libmng, suspectedly because of a race condition related to disk I/O. A way to get past this is by specifying "make nsis-installer JOBS=1", if required repeatedly (sometimes 5 or 6 times), interrupting the build in the next step/dependency once libmng has been built fine, and restarting with "make nsis-installer JOBS=<higher number>". As of Dec. 2015 it is only libmng that has this issue.


==Installing requirements of MXE Octave==
# Build the "stable" or "default" Octave development branch on Linux (in separate source and build trees) including your favorite modifications and patches.  Octave must be configured with Java support.  How to do this depends on your Linux distribution, see [[Octave for GNU/Linux]].
MXE Octave requires a recent Unix system where all components as stated below are installed.
# Verify that Octave runs fine in Linux (for example using <code>make check</code> and by trying to run your build <code>./run-octave --gui</code>).
# Create a distribution archive called '''"octave-<version>.tar.lz"''' in the top build directory with <code>make dist-lzip DIST_IGNORE_HG_STATE=1</code>.
# Move or copy '''"octave-<version>.tar.lz"''' to the {{Path|<mxe-octave build>/pkg}} folder (or create a symbolic link to it).
# Follow the [[#General steps|general steps]] and ensure the configuration with either of <code>--enable-octave=stable</code> or <code>--enable-octave=default</code>.
# Move the final installer in {{Path|<mxe-octave build>/dist}} to some Microsoft Windows machine (USB thumb drive, LAN copy, whatever) and install it "as usual".  If you created an archive, using <code>make all 7z-dist</code> for example, you'll have to manually create the desktop and start menu shortcuts (for GNU Octave and the MSYS-shell).


===Debian (GNU/kFreeBSD & GNU/Linux)===
For next builds, mxe-octave is already configured and all dependencies have been built so the only thing to do is to create a new '''"octave-<version>.tar.lz"''' and repeating the steps above.  This should be much faster than the first run.  If the new '''"octave-<version>.tar.lz"''' is not build and ignored, try the following:
aptitude install -R autoconf automake bash bison bzip2 \
                    cmake flex gettext git g++ intltool \
                    libffi-dev libtool libltdl-dev \
                    mercurial openssl libssl-dev \
                    libxml-parser-perl make patch perl \
                    pkg-config scons sed unzip wget \
                    xz-utils yasm autopoint zip


On 64-bit Debian, install also:
touch src/default-octave.mk


aptitude install -R g++-multilib libc6-dev-i386
If you've renamed '''"octave-<version>.tar.lz"''', be sure it matches with the package name in {{Path|src/default-octave.mk}}.


If you are using Ubuntu, then you can do <code>apt-get install foo</code> instead of <code>aptitude install -R foo</code>.
===Remarks===


On a fresh Linux Mint 16 x86_64, in addition to the above also install:
* If you have several mxe-octave build dirs (for e.g., stable and several development versions) it is handy to have a separate {{Path|pkg}} subdirectory where all mxe-octave build directories link to via an symbolic link, for example. That saves a lot of downloading bandwidth.
 
* As of late December 2015, [https://hg.octave.org/mxe-octave/rev/0962acdde3be mxe-octave allows out-of-tree builds]. This makes it easier to build separate Octave versions with the same mxe-octave tree.
sudo apt-get install libc6-dev-i386 gcc-multilib libgmp3-dev libmpfr4 libmpfr-dev
* To keep mxe-octave up-to-date, from time to time do:
sudo apt-get build-dep gcc-4.8
  hg -v pull
 
hg -v update
If not installed you will get error messages like  "/usr/include/stdc-predef.h:30:26: fatal error: bits/predefs.h: No such file or directory" or "/usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-linux-gnu/4.8/libgcc.a when searching for -lgcc" when compiling ocaml-core.
* However, do not keep mxe-octave build dirs for too long. I'd suggest to wipe a build dir after at most two or three months and start over with a fresh clone, see [#General steps|general steps].
The packages libgmp3-dev libmpfr4 libmpfr-dev libmpc-dev are needed for compiling the build-gcc.
* In the mean time, regularly clean up {{Path|<mxe-octave build>/log}} to save disk space. After a first successful build there is no more use for the log subdirectories for each package. One can safely wipe them all.
 
* It can happen that you meet problems with Java. To build Octave with Java support built-in, mxe-octave needs:
===Fedora===
** A Java JDK (Java Development Kit) on the '''host''' system. In other words, the javac (Java compiler) and jar (Java archiver) executables should be in the PATH-system-variable.
yum install autoconf automake bash bison bzip2 cmake \
** Java include files for MS Windows ("w32", even for "w64" builds). They should reside in {{Path|<mxe-octave build dir>/usr/x86_64-w64-mingw32/include/java/win32}}. If they are not present, mxe-octave downloads them automatically, but this can occasionally go wrong. On a multi-boot system a solution (note: dirty hack warning!) is symlinking to the MS Windows include files on the MS Windows partition from the mxe-octave location.
            flex gcc-c++ gettext git intltool make sed \
            libffi-devel libtool openssl-devel patch perl pkgconfig \
            scons yasm unzip wget xz
On 64-bit Fedora, there are [http://wiki.octave.org/Windows_Installer#Open_Issues_with_NSIS open issues with the NSIS] package.
 
===FreeBSD===
  pkg_add -r automake111 autoconf268 bash bison cmake \
            flex gettext git gmake gsed intltool libffi libtool \
            openssl patch perl p5-XML-Parser pkg-config \
            scons unzip wget yasm
 
Ensure that /usr/local/bin precedes /usr/bin in your $PATH:<br>
For C style shells, edit .cshrc
setenv PATH /usr/local/bin:$PATH
For Bourne shells, edit .profile
export PATH = /usr/local/bin:$PATH
 
On 64-bit FreeBSD, there are [http://wiki.octave.org/Windows_Installer#Open_Issues_with_NSIS open issues with the NSIS] package.
 
===Frugalware===
pacman-g2 -S autoconf automake bash bzip2 bison cmake \
              flex gcc gettext git intltool make sed libffi libtool \
              openssl patch perl perl-xml-parser pkgconfig \
              scons unzip wget xz xz-lzma yasm
On 64-bit Frugalware, there are [http://wiki.octave.org/Windows_Installer#Open_Issues_with_NSIS open issues with the NSIS] package.  
 
===Gentoo===
emerge sys-devel/autoconf sys-devel/automake \
        app-shells/bash sys-devel/bison app-arch/bzip2 \
        dev-util/cmake sys-devel/flex sys-devel/gcc \
        sys-devel/gettext dev-vcs/git \
        dev-util/intltool sys-devel/make sys-apps/sed \
        dev-libs/libffi sys-devel/libtool dev-libs/openssl sys-devel/patch \
        dev-lang/perl dev-perl/XML-Parser \
        dev-util/pkgconfig dev-util/scons app-arch/unzip \
        net-misc/wget app-arch/xz-utils dev-lang/yasm
 
===Mac OS X===
Install [http://developer.apple.com/xcode/ Xcode 4] and [http://www.macports.org/ MacPorts], then run:
 
sudo port install autoconf automake bison cmake flex \
                  gettext git-core gsed intltool libffi libtool \
                  openssl p5-xml-parser pkgconfig scons \
                  wget xz yasm


Mac OS X versions ≤ 10.6 are no longer supported.
===Troubleshooting===


===MingW===
* The error message displayed by <code>make</code> is simply the last lines of the log file.  This may truncate the actual error message.  Find the full error messages in the {{Path|<mxe-octave build>/log}} directory.
Make sure to update and upgrade packages as some of the default versions of packages are too old to work correctly.
* Sometimes running <code>make</code> a second time without changing anything will fix the problem.  In particular, <code>autotools</code> rebuilds some files in the first call <code>make</code>, which may cause the second call of <code>make</code> to succeed.
  mingw-get update
* If it is building Octave that failed, the source will be left in {{Path|<mxe-octave build>/tmp-default-octave}} and it is possible to run "configure && make" in that directory.
mingw-get upgrade
* The configuration will be for the target system, not your own.  In particular, if you have not installed all of the packages that mxe-octave installs, then your configuration will be different.  However, some configuration variables will differ even if you have the same packages, and some compiler features may be available on the host system that are not available in cross-compile mode.
* A possible causes for build failure is having files in your local source or build directory that are not listed in the {{Path|module.mk}} files; these are not copied into the dist archive.
* Sometimes mxe-octave builds fail at "libmng". This may be due to a race condition related to disk I/O when using a fast SSD harddisk. A way to get past this is by specifying "make nsis-installer JOBS=1", if required repeatedly (sometimes 5 or 6 times), interrupting the build in the next step/dependency once "libmng" has been built fine, and restarting with "make nsis-installer JOBS=<higher number>". As of December 2015 it is only libmng that has this issue.


And then get required packages.
==Testing using virtual machines==
mingw-get install autoconf bash msys-bison msys-flex gcc gcc-c++ \
                  gcc-fortran gettext msys-m4 msys-make msys-sed \
                  libiconv msys-openssl msys-patch msys-perl \
                  msys-libarchive msys-unzip msys-wget msys-bsdtar
   
You will also need to install Windows versions of Python and Ghostscript and ensure they are in visible in the PATH.


===OpenSUSE===
Microsoft provides several virtual machine (e.g. VirtualBox) disk images of MS Windows for about one month of testing
zypper install -R autoconf automake bash bison bzip2 \
* https://developer.microsoft.com/en-us/windows/downloads/virtual-machines
                  cmake flex gcc-c++ gettext-tools git \
* https://developer.microsoft.com/en-us/microsoft-edge/tools/vms (primarily meant for testing the MS-Edge browser)
                  intltool libffi-devel libtool make openssl \
The license (given on that page) for these images does not limit the use of these images. So it is perfectly possible to also test GNU Octave.
                  libopenssl-devel patch perl \
                  perl-XML-Parser pkg-config scons \
                  sed unzip wget xz yasm


On 64-bit openSUSE, install also:
The key idea is to create a shared folder inside the virtual machine to the mxe-octave build directory. It is advised to make it read-only. Either install (or unpack) Octave into MS Windows 10, or create a shortcut to {{Path|octave.vbs}} in the {{Path|<mxe-octave build dir>/dist/octave}} subdirectory on the Linux side.
  zypper install -R gcc-32bit glibc-devel-32bit \
                  libgcc46-32bit libgomp46-32bit \
                  libstdc++46-devel-32bit


==Creating an NSIS based installer==
Some advantages:
The <code>make nsis-installer</code> command produces a NSIS installer that is ready to be distributed.
* No dedicated MS Windows machine or rebooting from Linux is needed;
 
* The <strike>latest</strike> MS Windows 10 version is always available;
==Trying out cross-built Octave on Linux through VirtualBox==
* Building the installer archives (zip, 7z, ...) isn't needed. One can interrupt the build process after the local installation of Octave has been made in the dist/octave subdirectory of mxe-octave, i.e., when the message "generating installer" (or "zip...") is shown. This saves about 10-15 minutes. Of course one can also use the common distribution formats for the virtual MS Windows machine.
Micosoft makes pre-built Windows 10 virtual disk images available for testing. While primarily meant for testing the MS-Edge browser, the license for these images does not limit the use of these images to just MS-Edge. So it is perfectly possible to also test Octave.
There are several advantages:
* Rebooting from Linux to Windows isn't needed;
* The latest Windows 10 version is always available;
* Building the installer or zip/7z/<whatever> archives itself isn't needed. One can interrupt the build process after the entire installation of Octave has been made in the dist/octave subdirectory of mxe-octave, i.e., when the message "generating installer" (or "zip...") is shown, saving ~10-15 minutes.
Of course one an also install (or unpack) octave into the virtualized Windows 10.
 
Steps:
* Install Virtualbox
* Grab a copy of the Windows 10 image here:  https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/
* Unpack and import the disk image into VirtualBox.
* In VirtualBox, select Settings | Shared folders and setup access from Windows 10 to the Linux subdir where you but mxe-octave. It is advised to make it read-only.
 
Then:
* Either install (or unpack) Octave into Windows 10, or
* Create a shortcut to octave.vbs in the dist/octave subdir on Linux.


Hints:
Hints:
* I adapted mxe-octave/binary-dist-rules.mk to have a consistent name for the dist/octave subdir (i.e., without time/date/bitwidth suffixes) so that in Windows the shortcut doesn't need adaptation after each cross-build action. Maybe it is better if binary-dist-rules.mk has a rule to create a symlink "dist/octave/" pointing to the latest cross-build.
* When adapting {{Path|mxe-octave/binary-dist-rules.mk}} to have a consistent name for the {{Path|<mxe-octave build dir>/dist/octave}} subdirectory (i.e., without time/date/bitwidth suffixes) so that in MS Windows the shortcut doesn't need adaptation after each cross-build action. Maybe it is better if {{Path|mxe-octave/binary-dist-rules.mk}} has a rule to create a symlink {{Path|<mxe-octave build dir>/dist/octave}} pointing to the latest cross-build.
* The image expires after 90 days. But if you make a VirtualBox snapshot it will last longer, and you don't need to uninstall Octave each time before installing a new build.
* The image expires after 90 days. But if you make a VirtualBox snapshot it will last longer, and you don't need to uninstall Octave each time before installing a new build.


==Footnotes==
<references/>


[[Category:Building]]
[[Category:Packaging]]
[[Category:Packaging]]
[[Category:Microsoft Windows]]

Revision as of 14:42, 27 December 2019

This article is about how to make the Microsoft Windows installer; if you'd like just to use the installer, see Octave for Microsoft Windows.

GNU Octave is primarily developed on GNU/Linux and other POSIX compliant systems. There have been many efforts in the past to build ports of GNU Octave for Microsoft Windows. This page contains instructions about creating a MS Windows installer using mxe-octave (a fork of MXE). This means, the MS Windows installer is cross-compiled using a GNU/Linux system.

Creating the MS Windows Installer

General steps

  1. Install the MXE build requirements.[1]
  2. hg clone https://hg.octave.org/mxe-octave[2]
  3. cd mxe-octave
  4. ./bootstrap
  5. ./configure
  6. make all nsis-installer

Step details

./configure

The current Microsoft Windows installers are build in three "flavors": for common 64- and 32-bit systems ("w64" and "w32") and for 64-bit systems exceeding 32 GB of main memory to store large data structures ("w64-64").

"w64" (recommended) "w64-64" "w32"
./configure                        \
  --enable-devel-tools             \
  --enable-binary-packages         \
  --with-ccache                    \
  --enable-octave=<octave version>
./configure                        \
  --enable-devel-tools             \
  --enable-binary-packages         \
  --with-ccache                    \
  --enable-octave=<octave version> \
  --enable-fortran-int64
./configure                        \
  --enable-devel-tools             \
  --enable-binary-packages         \
  --with-ccache                    \
  --enable-octave=<octave version> \
  --disable-windows-64

The individual options have the following meaning (see also ./configure --help):

  • --enable-devel-tools: Include gdb and an MSYS shell in the binary.
    • If you seriously want to work with gdb, you need --disable-strip-dist-files as configure option to keep debug symbols in the installed binaries for debugging on MS Windows. Beware as the total Octave distribution will be > 2 GB, the max. size for an NSIS installer. Your only options are to make 7z-dist, zip-dist or tar-dist installers.
  • --enable-binary-packages: Cross-compile binary modules in Octave Forge packages. This saves time when installing them once the installation runs on Microsoft Windows. Furthermore, some packages require patches to cross-compile successfully (or with current Octave versions). Those additional patches would be missing when compiling the original packages from Octave Forge on Windows later on. Some Octave Forge packages require a working Octave during compilation. Therefore, the correct version(!) of Octave must be installed on the host system.
  • --with-ccache: The usage of ccache may speed up repetitive compilation drastically.
  • --enable-octave=<octave version>: Build a specific version of GNU Octave, which can be one of:
    • release use src/release-octave.mk, download and build the latest GNU Octave release.
    • stable or default uses src/stable-octave.mk or src/default-octave.mk, respectively. This builds from a self-created distribution tarball from the "stable" or "default" development branch of GNU Octave. See below for details.
  • --disable-windows-64: Build for 32-bit MS Windows.
  • --enable-fortran-int64: Use 64-bit integers in Fortran code and especially in numerical library code. This option only affects the size of integers used in Fortran code like the BLAS and LAPACK libraries. On 64-bit systems, Octave always uses 64-bit integers for indexing and basic array operations. See Enable large arrays for details.
  • --disable-system-opengl: Include software OpenGL libraries. This might help when working with buggy graphics card drivers, but might be slower than hardware accelerated rendering.
  • --with-pkg-dir=../mxe-octave-pkg: If you are working with several build trees, you can share a common package directory.

make

  • Use make all 7z-dist, make all tar-dist or make all zip-dist instead of make all nsis-installer if you want to build just an archive of the files to install on MS Windows instead of an installer wizard.
  • By default, packages will be built one at a time, but you may use make JOBS=4 (choose a number other than 4 that is appropriate for your system) to build each package in parallel. You may also combine this with the -j option for Make to build more than one package at a time, but be careful as using make -j4 JOBS=4 can result in as many as 16 jobs running at once.
  • Include gdb in the installer by running make gdb before making the nsis-installer target.


Build installers for Octave development versions

  1. Build the "stable" or "default" Octave development branch on Linux (in separate source and build trees) including your favorite modifications and patches. Octave must be configured with Java support. How to do this depends on your Linux distribution, see Octave for GNU/Linux.
  2. Verify that Octave runs fine in Linux (for example using make check and by trying to run your build ./run-octave --gui).
  3. Create a distribution archive called "octave-<version>.tar.lz" in the top build directory with make dist-lzip DIST_IGNORE_HG_STATE=1.
  4. Move or copy "octave-<version>.tar.lz" to the <mxe-octave build>/pkg folder (or create a symbolic link to it).
  5. Follow the general steps and ensure the configuration with either of --enable-octave=stable or --enable-octave=default.
  6. Move the final installer in <mxe-octave build>/dist to some Microsoft Windows machine (USB thumb drive, LAN copy, whatever) and install it "as usual". If you created an archive, using make all 7z-dist for example, you'll have to manually create the desktop and start menu shortcuts (for GNU Octave and the MSYS-shell).

For next builds, mxe-octave is already configured and all dependencies have been built so the only thing to do is to create a new "octave-<version>.tar.lz" and repeating the steps above. This should be much faster than the first run. If the new "octave-<version>.tar.lz" is not build and ignored, try the following:

touch src/default-octave.mk

If you've renamed "octave-<version>.tar.lz", be sure it matches with the package name in src/default-octave.mk.

Remarks

  • If you have several mxe-octave build dirs (for e.g., stable and several development versions) it is handy to have a separate pkg subdirectory where all mxe-octave build directories link to via an symbolic link, for example. That saves a lot of downloading bandwidth.
  • As of late December 2015, mxe-octave allows out-of-tree builds. This makes it easier to build separate Octave versions with the same mxe-octave tree.
  • To keep mxe-octave up-to-date, from time to time do:
hg -v pull
hg -v update
  • However, do not keep mxe-octave build dirs for too long. I'd suggest to wipe a build dir after at most two or three months and start over with a fresh clone, see [#General steps|general steps].
  • In the mean time, regularly clean up <mxe-octave build>/log to save disk space. After a first successful build there is no more use for the log subdirectories for each package. One can safely wipe them all.
  • It can happen that you meet problems with Java. To build Octave with Java support built-in, mxe-octave needs:
    • A Java JDK (Java Development Kit) on the host system. In other words, the javac (Java compiler) and jar (Java archiver) executables should be in the PATH-system-variable.
    • Java include files for MS Windows ("w32", even for "w64" builds). They should reside in <mxe-octave build dir>/usr/x86_64-w64-mingw32/include/java/win32. If they are not present, mxe-octave downloads them automatically, but this can occasionally go wrong. On a multi-boot system a solution (note: dirty hack warning!) is symlinking to the MS Windows include files on the MS Windows partition from the mxe-octave location.

Troubleshooting

  • The error message displayed by make is simply the last lines of the log file. This may truncate the actual error message. Find the full error messages in the <mxe-octave build>/log directory.
  • Sometimes running make a second time without changing anything will fix the problem. In particular, autotools rebuilds some files in the first call make, which may cause the second call of make to succeed.
  • If it is building Octave that failed, the source will be left in <mxe-octave build>/tmp-default-octave and it is possible to run "configure && make" in that directory.
  • The configuration will be for the target system, not your own. In particular, if you have not installed all of the packages that mxe-octave installs, then your configuration will be different. However, some configuration variables will differ even if you have the same packages, and some compiler features may be available on the host system that are not available in cross-compile mode.
  • A possible causes for build failure is having files in your local source or build directory that are not listed in the module.mk files; these are not copied into the dist archive.
  • Sometimes mxe-octave builds fail at "libmng". This may be due to a race condition related to disk I/O when using a fast SSD harddisk. A way to get past this is by specifying "make nsis-installer JOBS=1", if required repeatedly (sometimes 5 or 6 times), interrupting the build in the next step/dependency once "libmng" has been built fine, and restarting with "make nsis-installer JOBS=<higher number>". As of December 2015 it is only libmng that has this issue.

Testing using virtual machines

Microsoft provides several virtual machine (e.g. VirtualBox) disk images of MS Windows for about one month of testing

The license (given on that page) for these images does not limit the use of these images. So it is perfectly possible to also test GNU Octave.

The key idea is to create a shared folder inside the virtual machine to the mxe-octave build directory. It is advised to make it read-only. Either install (or unpack) Octave into MS Windows 10, or create a shortcut to octave.vbs in the <mxe-octave build dir>/dist/octave subdirectory on the Linux side.

Some advantages:

  • No dedicated MS Windows machine or rebooting from Linux is needed;
  • The latest MS Windows 10 version is always available;
  • Building the installer archives (zip, 7z, ...) isn't needed. One can interrupt the build process after the local installation of Octave has been made in the dist/octave subdirectory of mxe-octave, i.e., when the message "generating installer" (or "zip...") is shown. This saves about 10-15 minutes. Of course one can also use the common distribution formats for the virtual MS Windows machine.

Hints:

  • When adapting mxe-octave/binary-dist-rules.mk to have a consistent name for the <mxe-octave build dir>/dist/octave subdirectory (i.e., without time/date/bitwidth suffixes) so that in MS Windows the shortcut doesn't need adaptation after each cross-build action. Maybe it is better if mxe-octave/binary-dist-rules.mk has a rule to create a symlink <mxe-octave build dir>/dist/octave pointing to the latest cross-build.
  • The image expires after 90 days. But if you make a VirtualBox snapshot it will last longer, and you don't need to uninstall Octave each time before installing a new build.

Footnotes

  1. The requirements for each system are listed in the repository https://hg.octave.org/mxe-octave/file/tip/index.html. Start with the second step to read the index.html file on your local machine.
  2. Use hg clone https://hg.octave.org/mxe-octave <name of mxe-octave build dir> to choose another directory.