Win-builds

(Free) Software Building and Packaging For Windows

Download and Installation From Linux

No Linux binaries are provided because of the differences between distributions. The usual approach is to build the cross-compiler on the host system and then re-use the pre-built windows packages (since they are independent of the system used to build).

There are three steps:

  1. build yypkg
  2. build the cross-compiler
  3. acquire or build the windows binaries

The packages are split into three series: native, cross_toolchain and windows:

  • native adds native tools which must be of a specific version; for instance, it installs EFL because the cross-compilation of EFL needs to run tools which must be of the exact same version;
  • cross_toolchain builds the cross-compilation toolchain;
  • windows cross-compiles the binaries that will run on windows

Building takes a fairly large amount of space: up to 2GB for native_toolchain, 2GB for cross_toolchain_* and 7.5GB for windows_* (but this series can be retrieved instead of being built). Around 90% of this space is made up of temporary files in tmp directories. At peak it can also use a lot of memory, having 2GB of memory available (swap excluded) is advised.

Dependencies

The per-distributions package lists below are here to help you get all the dependencies easily. The Debian/Ubuntu list is exhaustive and is the reference. For other distributions, if you are able to complete the lists with the right package name, please send it either on the users mailing list or on the bug tracker.

Debian (squeeze or wheezy) and Ubuntu (>= 12.04)

apt-get install ocaml-nox ocaml-findlib libarchive-dev bsdtar texinfo \
libudev-dev intltool libpng-dev gtk-doc-tools tcl8.5 libgdk-pixbuf2.0-dev yasm \
autotools-dev autopoint automake flex bison libdbus-1-dev libgmp-dev \
libmpfr-dev libmpc-dev xutils-dev git libgtk2.0-bin texi2html cmake texinfo \
librsvg2-bin imagemagick liblzma5 liblzma-dev gperf libreadline6-dev
apt-get build-dep libelementary-dev

There are several issues when building on older Debian and Ubuntu versions. You will avoid all of them but two if you re-use the pre-built packages from win-builds.org but you may encounter them when building your own software. Upgrading your distribution is strongly advised.

  • Debian wheezy and Ubuntu 12.04 have an ocamlfind version that is too old to build yypkg. You can safely install a new version by hand on top of the system one.
  • Debian wheezy and Ubuntu 12.04 have an old autoreconf that generates bad code; avoid calling it when developing, use a backport or migrate. Build scripts do their best to avoid calling it but it is needed for some packages (madplay, libtheora and libxml2 [can be commented out]) which can therefore not be rebuilt on vanilla Debian wheezy and Ubuntu 12.04.
  • Debian wheezy has old yasm which x264 doesn’t handle; disable x264’s build and its use in ffmpeg (edit build script config and remove x264 from the dependency list of ffmpeg), use a backport or migrate.
  • Qt doesn’t build on debian wheezy for 32b; cause is not known. This prevents building with Qt tools (qmake, moc, etc.).

Arch Linux

Install the following from the main repositories:

intltool ocaml ocaml-findlib wget

Install the following from AUR:

makedepend

You might also have to read and adapt the list in the Debian section to fit Arch Linux.

Exherbo

List below is incomplete: read and adapt the list in the Debian section to fit Exherbo.

cave resolve -x dev-ocaml/findlib dev-lang/ocaml '>=app-arch/libarchive-3.1.2-r2'

Slackware

A default slackware install ships almost everything needed. The only exceptions are OCaml and ocaml-findlib (both on Slackbuilds.org).

They can be installed through sbopkg with the following command:

sbopkg -i "ocaml ocaml-findlib"

Slackware -current as of September 2014 has proper software for the build and is the main development platform for win-builds.

Previous Slackware versions have some components that are too old. Overall they should work except for their older version of automake which can be an issue for madplay, libtheora and libxml2 (see the section above for Debian). It is strongly advised to migrate to -current (or any release more recent than 14.1) if rebuilding these packages is wanted.

Retrieve sources

Run the following to get all the source files:

for repo in win-builds mingw slackware64-current slackbuilds.org; do
  git clone http://git.notk.org/gitolite/win-builds/${repo}.git
done

This can fail with git 1.7.2 and is fixed in git 1.8.0 (commit “http: fix segfault in handle_curl_result”).

When the build runs, if some source tarball is not available on disk or has a SHA1 which doesn’t match, it will be downloaded from the source mirror, overwriting any existing file.

Yypkg

Build of yypkg and its dependencies is automated; run

make -C win-builds/yypkg

Then, install as root (it copies a single executable to /usr/local/bin), run:

make -C win-builds/yypkg install

To install to a different location, set the BINDIR variable:

make -C win-builds/yypkg install BINDIR=/usr/local/bin

Build the cross-compiler

Building the packages requires a root environment (for chown and umask); such an environment can also be emulated through fakeroot for convenience.

Everything will be installed inside /opt. The reason is that it is available on all systems and binaries tend to store paths, making them not portable if paths change. If you intend to rebuild all packages on your machine anyway, you can edit build/config.ml, look for /opt/ and replace it with the value you wish.

If a build fails, you should look at the log file stored as @@VERSION@@/logs/<series>/<package_name>.

As root

make -C win-builds NATIVE_TOOLCHAIN=all CROSS_TOOLCHAIN=all

Or, using fakeroot

First create the needed directories as root and chown them to yourself; symlinks will work just fine:

mkdir opt
for d in native_toolchain cross_toolchain_{32,64} windows_{32,64}; do
  mkdir $(pwd)/opt/${d}
  sudo ln -s $(pwd)/opt/${d} /opt/${d}
done

Then:

fakeroot make -C win-builds NATIVE_TOOLCHAIN=all CROSS_TOOLCHAIN=all

Get the Windows binaries

There are two approaches possible:

Download package (a couple minutes of download (2*110MB))

make -C win-builds WINDOWS=download

A few commands will try to run at the very end of the installation and will fail. These can be safely ignored.

Build the packages yourself (a few hours of CPU time)

make -C win-builds WINDOWS=all

Customization

Selective rebuilds

Chosing which packages are to be built is done through environment variables. There are 7 of them:

  • WINDOWS_32, WINDOWS_64: packages which executables will run on Windows for 32 or 64 bits
  • WINDOWS: short-hand: WINDOWS=foo is equivalent to WINDOWS_32=foo WINDOWS_64=foo
  • CROSS_TOOLCHAIN_32, CROSS_TOOLCHAIN_64: the cross-compilation toolchain which runs on your current system and targets Windows for 32 or 64 bits
  • CROSS_TOOLCHAIN: short-hand: CROSS_TOOLCHAIN=foo is equivalent to CROSS_TOOLCHAIN_32=foo CROSS_TOOLCHAIN_64=foo
  • NATIVE_TOOLCHAIN: some build-time dependencies for packages above; they are either common but required to be at a specific version or uncommon

The value of these environment variables is the list of packages to build. As an example, to build only the cross_toolchain and windows series, one would run:

make -C win-builds CROSS_TOOLCHAIN=all WINDOWS=all

The package all is virtual and selects every stable package from the series.

When a package has variants (several configuration presets), the identifier is of the form ${package}:${preset}.

Cross-series dependencies are not handled meaning that in this specific example, you need to have build the NATIVE_TOOLCHAIN series first.

Last, if you want to build a specific set of packages, you need to call make as such:

make -C win-builds WINDOWS=libjpeg,libpng,lua

Packages will only get rebuilt if at least one of their sources is more recent than the output package. However, the rebuild of a package doesn't trigger the rebuild of packages that depend on it in order to avoid excessive rebuilds (unless for specific cases, this isn’t a problem thanks to the use of shared libraries in win-builds).

Build script configuration

The configuration for most packages is stored directly inside the build scripts. The packages which have variants have their configuration in a separate file in the same directory as the build script and named config-${variant}.

Modify the package lists

The list of packages to build is stored inside three files: win-builds/native_toolchain.ml, win-builds/cross_toolchain.ml, win-builds/windows.ml as straightforward OCaml code.

A package description is made of a name, a variant (which is mostly useful for bootstrapping a minimal version of a package before being able to build the full one), a directory where its sources are stored, its dependencies, version, build number and sources.

Below is the description for the freetype package from the windows series:

let freetype = add ("freetype", None)
  ~dir:"slackware64-current/l"
  ~dependencies:[ zlib; libpng ]
  ~version:"2.5.0.1"
  ~build:1
  ~sources:[
    "freetype-${VERSION}.tar.xz";
    "freetype.illadvisederror.diff.gz";
    "freetype.subpixel.rendering.diff.gz";
  ]
in

The package is named freetyp“, doesn’t have a variant (None in the code), is stored inside the slackware64-current/l directory, depends on zlib and libpng, is at version 2.5.0.1, first build, and has three package-specific sources: its source tarball and two patches.