Windows Installer: Difference between revisions

Jump to navigation Jump to search
1,276 bytes added ,  14 October 2019
m
(10 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 compliant systems. There have been many efforts in the past to build ports of GNU 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 Windows installer using [[MXE|mxe-octave]] (a fork of [http://mxe.cc/ MXE]).
This page contains instructions about creating a MS Windows installer using [[MXE|mxe-octave]] (a fork of [http://mxe.cc/ MXE]).
This means, '''the Microsoft Windows installer is [https://en.wikipedia.org/wiki/Cross_compiler cross-compiled] using a GNU/Linux system'''.
This means, '''the MS Windows installer is [https://en.wikipedia.org/wiki/Cross_compiler cross-compiled] using a GNU/Linux system'''.


==Steps to create Windows Installer==
==Creating the MS Windows Installer==


===General steps===
===General steps===
Line 19: Line 19:
====<code>./configure</code>====
====<code>./configure</code>====


The current 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"''').
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"''').


{| class="wikitable"
{| class="wikitable"
Line 31: Line 31:
   --enable-binary-packages        \
   --enable-binary-packages        \
   --with-ccache                    \
   --with-ccache                    \
   --enable-octave=<octave version> \
   --enable-octave=<octave version>
  --enable-windows-64              \
  --enable-64
</pre>
</pre>
| <pre style="min-width:330px;">
| <pre style="min-width:330px;">
Line 41: Line 39:
   --with-ccache                    \
   --with-ccache                    \
   --enable-octave=<octave version> \
   --enable-octave=<octave version> \
  --enable-windows-64              \
  --enable-64                      \
   --enable-fortran-int64
   --enable-fortran-int64
</pre>
</pre>
Line 58: Line 54:


* <code>--enable-devel-tools</code>: Include gdb and an MSYS shell in the binary.
* <code>--enable-devel-tools</code>: Include gdb and an MSYS shell in the binary.
** 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 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.
** 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.
* <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.
* <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>--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>--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>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 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>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>--enable-windows-64</code>: Build for 64-bit MS Windows.
* <code>--disable-windows-64</code>: Build for 32-bit MS Windows.
* <code>--enable-64</code>: Let Octave use 64-bit integers for indexing.
* <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>--enable-fortran-int64</code>: Use 64-bit integers in Fortran code and especially in numerical library code.
* <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.


====<code>make</code>====
====<code>make</code>====


* 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.
* 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 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.
* 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.
* Include gdb in the installer by running <code>make gdb</code> before making the <code>nsis-installer</code> target.
* Include gdb in the installer by running <code>make gdb</code> before making the <code>nsis-installer</code> target.
Line 92: Line 89:
===Remarks===
===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.
* 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 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)
* 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.
* To keep mxe-octave up-to-date, from time to time do:
* To keep mxe-octave up-to-date, from time to time do:
  hg -v pull
  hg -v pull
  hg -v update
  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.
* 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's no more use for the log subdirs for each package, so you can wipe them all.
* 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:
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.
* 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 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.
* 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.


===Troubleshooting===
===Troubleshooting===


* The error message displayed by make is simply the last 10 lines of the log file.  This may truncate the actual error message.
* 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.
* 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.
* 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.
* 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.
* 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.
* 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.
* 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.
* 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.
* (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.
* 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.


==Trying out cross-built Octave on Linux through VirtualBox==
==Testing using virtual machines==


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.
Microsoft provides several virtual machine (e.g. VirtualBox) disk images of MS Windows for 90 days of testing https://developer.microsoft.com/en-us/microsoft-edge/tools/vms/. While primarily meant for testing the MS-Edge browser, the license (given on that page) for these images does not limit the use of these images to just MS-Edge. So it is perfectly possible to also test GNU 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:
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.
* 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:
Some advantages:
* Either install (or unpack) Octave into Windows 10, or
* No dedicated MS Windows machine or rebooting from Linux is needed;
* Create a shortcut to octave.vbs in the dist/octave subdir on Linux.
* The <strike>latest</strike> 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:
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.


Line 140: Line 128:
<references/>
<references/>


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

edits

Navigation menu