Windows Installer

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

Recently some work has been done in maintaining a unified build system mxe-octave (a fork of 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.

Use make tar-dist or make zip-dist instead of nsis-installer if you want to build just an archive of the files to install on 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.

Use ./configure --disable-strip-dist-files 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 zip-dist or tar-dist installers.

Include gdb in the installer by running make gdb before making the nsis-installer target.

Creating Octave development versions for Windows with mxe-octave[edit]

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)

Build an Octave dist archive in Linux

Move that into mxe-octave and cross-build Octave + windows installer.

For ensuing builds after a first build, you'll only need to follow steps 2 + a little amended step 3 (see below)

Your author usually has "--enable-devel-tools --enable-octave=default --enable-binary-packages" 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" or "--enable-devel-tools --enable-octave=stable --enable-binary-packages --enable-windows64"

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 wil 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:

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.

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.

Step 2: To build your first Octave-for Windows development version:[edit]

once Octave runs fine in Linux (using make check and trying your mods using ./run-octave & from the build dir, all of this still on the Linux side), do:

make all dist

This will produce a dist archive called "octave-<version>.tar.gz" in the top 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).

Note: If you skip this step, mxe-octave will build using the source available from from the hydra site.
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.

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

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.

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.

Sometimes, when using the "--enable-binary-packages" flag, it happens that Octave-Forge packages with binary modules don't work well on the Windows side. Usually the cause is that the Octave dev version has changed too much since the last cross-build of the OF packages. Solution: just do in <mxe-octave>/:

touch src/of*.mk
make <OPTIONS>

mxe-octave will rebuild all OF packages then incl. the offending binary modules.

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.

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.

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.
The packages libgmp3-dev libmpfr4 libmpfr-dev libmpc-dev are needed for compiling the build-gcc.

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.

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:

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.

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.