Building windows binaries on linux

Win-builds

(Free) Software Building and Packaging For Windows

Table of Contents

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:

The packages are split into three series: native , cross_toolchain and 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)

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.

Arch Linux

Install the following from the main repositories:

Install the following from AUR:

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.

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:

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:

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

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

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

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/ /

As root

Or, using fakeroot

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

Get the Windows binaries

There are two approaches possible:

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

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)

Customization

Selective rebuilds

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

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:

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 $:$ .

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:

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

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:

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.

Источник

Building windows binaries on linux

Copy raw contents

WINDOWS BUILD NOTES

Below are some notes on how to build Bitcoin Core for Windows.

The options known to work for building Bitcoin Core on Windows are:

• On Linux, using the Mingw-w64 cross compiler tool chain.
• On Windows, using Windows Subsystem for Linux (WSL) and Mingw-w64.
• On Windows, using Microsoft Visual Studio. See README.md.

Other options which may work, but which have not been extensively tested are (please contribute instructions):

• On Windows, using a POSIX compatibility layer application such as cygwin or msys2.

Installing Windows Subsystem for Linux

Follow the upstream installation instructions, available here.

Cross-compilation for Ubuntu and Windows Subsystem for Linux

The steps below can be performed on Ubuntu or WSL. The depends system will also work on other Linux distributions, however the commands for installing the toolchain will be different.

First, install the general dependencies:

A host toolchain ( build-essential ) is necessary because some dependency packages need to build host utilities that are used in the build process.

See dependencies.md for a complete overview.

If you want to build the windows installer with make deploy you need NSIS:

Acquire the source in the usual way:

Building for 64-bit Windows

The first step is to install the mingw-w64 cross-compilation tool chain:

Next, set the default mingw32 g++ compiler option to POSIX 1 :

After running the above command, you should see output similar to that below. Choose the option that ends with posix .

Once the toolchain is installed the build steps are common:

Note that for WSL the Bitcoin Core source path MUST be somewhere in the default mount file system, for example /usr/src/bitcoin, AND not under /mnt/d/. If this is not the case the dependency autoconf scripts will fail. This means you cannot use a directory that is located directly on the host Windows file system to perform the build.

Additional WSL Note: WSL support for launching Win32 applications results in Autoconf configure scripts being able to execute Windows Portable Executable files. This can cause unexpected behaviour during the build, such as Win32 error dialogs for missing libraries. The recommended approach is to temporarily disable WSL support for Win32 applications.

For further documentation on the depends system see README.md in the depends directory.

After building using the Windows subsystem it can be useful to copy the compiled executables to a directory on the Windows drive in the same directory structure as they appear in the release .zip archive. This can be done in the following way. This will install to c:\workspace\bitcoin , for example:

You can also create an installer using:

1: Starting from Ubuntu Xenial 16.04, both the 32 and 64 bit Mingw-w64 packages install two different compiler options to allow a choice between either posix or win32 threads. The default option is win32 threads which is the more efficient since it will result in binary code that links directly with the Windows kernel32.lib. Unfortunately, the headers required to support win32 threads conflict with some of the classes in the C++11 standard library, in particular std::mutex. It’s not possible to build the Bitcoin Core code using the win32 version of the Mingw-w64 cross compilers (at least not without modifying headers in the Bitcoin Core source code).

Источник

Creating Linux binaries

Creating Linux binaries that can be downloaded and run on any distro (like .dmg packages for OSX or .exe installers for Windows) has traditionally been difficult. This is even more tricky if you want to use modern compilers and features, which is especially desired in game development. There is still no simple turn-key solution for this problem but with a bit of setup it can be relatively straightforward.

Installing system and GCC

First you need to do a fresh operating system install. You can use spare hardware, VirtualBox, cloud or whatever you want. Note that the distro you install must be at least as old as the oldest release you wish to support. Debian stable is usually a good choice, though immediately after its release you might want to use Debian oldstable or the previous Ubuntu LTS. The oldest supported version of CentOS is also a good choice.

Once you have installed the system, you need to install build-dependencies for GCC. In Debian-based distros this can be done with the following commands:

Then create a src subdirectory in your home directory. Copy-paste the following into install_gcc.sh and execute it.

Then finally add the following lines to your .bashrc .

Log out and back in and now your build environment is ready to use.

Adding other tools

Old distros might have too old versions of some tools. For Meson this could include Python 3 and Ninja. If this is the case you need to download, build and install new versions into

/devroot in the usual way.

Adding dependencies

You want to embed and statically link every dependency you can (especially C++ dependencies). Meson’s Wrap package manager might be of use here. This is equivalent to what you would do on Windows, OSX, Android etc. Sometimes static linking is not possible. In these cases you need to copy the .so files inside your package. Let’s use SDL2 as an example. First we download and install it as usual giving it our custom install prefix (that is, ./configure —prefix=$/devroot ). This makes Meson’s dependency detector pick it up automatically.

Building and installing

Building happens in much the same way as normally. There are just two things to note. First, you must tell GCC to link the C++ standard library statically. If you don’t then your app is guaranteed to break as different distros have binary-incompatible C++ libraries. The second thing is that you need to point your install prefix to some empty staging area. Here’s the Meson command to do that:

The aim is to put the executable in /tmp/myapp/bin and shared libraries to /tmp/myapp/lib . The next thing you need is the embedder. It takes your dependencies (in this case only libSDL2-2.0.so.0 ) and copies them in the lib directory. Depending on your use case you can either copy the files by hand or write a script that parses the output of ldd binary_file . Be sure not to copy system libraries ( libc , libpthread , libm etc). For an example, see the sample project.

Make the script run during install with this:

Источник

booherbg / gist:f812c9145d157d8945b2

How to build Golang windows/arm static binaries from linux

Alternate title: Cross compiling Windows/Darwin/Linux amd64/386/arm all from linux

After fumbling around trying to figure out the go toolchain and cross compilation configuration, I ran across the wiki page on Go’s homepage. It’s super helpful, and worked out of the box. I’m including the necessary scripts here in case they get changed or lost, and we can help Google find it (since it’s the first real source I’ve found that «Just Worked»). http://code.google.com/p/go-wiki/wiki/WindowsCrossCompiling

I also went a step further, and built for windows/amd64 and linux/arm

Set yourself up for windows cross compile!

Now, go build yourself a static windows go binary!

And just for kicks — let’s cross compile for darwin (OSX Native)

Just be aware that there are some side effects in this method because CGO_ENABLED=0. With the latest versions of Go, however, I was able to run a small http server without issues, and another server that connects to postgres through a third party go library (although I didn’t actually set up postgres on windows — but the program ran and returned a standard database connection error message). Pretty slick!

Building for ARM

Building for ARM is just as straight forward, except you have to re-run make.bash (because you have to switch your toolchain from x86 to ARM). If not, you’ll do:

Back to the go build root — get all set up for arm

Источник

eknori.de

the weird world of eknori

Build Windows executables on Linux

If you have to build a binary ( .exe, .dll, … ) from source code for LINUX and WINDOWS, you need at least one build environment for each operating system.
In today’s world, this is not a big deal, because we can have as many virtual machines as we want thanks to VMWARE ( or VirtualBox ).
But this could become a complex environment and might also increase license costs to name just a few problems.

Many of us use Linux as our primary operating system. So the question is: “Can we use Linux to compile and link Windows executables?”

The concept of targeting a different platform than the compiler is running on is not new, and is known as cross-compilation.

Cross-compiling Windows binaries on Linux may have many benefits to it.

• Reduced operating system complexity.
  On cross-platform projects that are also built on Linux, we can get one less operating system to maintain.

• Access to Unix build tools.
  Build tools such as make, autoconf, automake and Unix utilities as grep, sed, and cat, to mention a few, become available for use in Windows builds as well. Even though projects such as MSYS port a few of these utilities to Windows, the performance is generally lower, and the versions are older and less supported than the native Unix counterparts. Also, if you already have a build environment set up under Linux, you don’t have to set it up again on Windows, but just use the existing one.

• Lower license costs.
  As we know, Windows costs in terms of license fees. Building on Linux, developers do not need to have a Windows installation on their machines, but maybe just a central Windows installation for testing purposes.

On a Linux build environment, a gcc that compiles native binaries is usually installed in “/usr/bin”.
Native headers and libraries are in turn found in “/usr/include” and “/usr/lib”, respectively.
We can see that all these directories are rooted in “/usr”.

Any number of cross-compiler environments can be installed on the same system, as long as they are rooted in different directories.

To compile and link a Windows executable on Linux do the following

For 64Bit, open “Toolchains targetting Win64″ , followed by “Automated Builds” and download a recent version to /tmp
For 32Bit, open “Toolchains targetting Win32″ , followed by “Automated Builds” and download a recent version to /tmp

(2) Create 2 directories mkdir /opt/mingw32 and mkdir /opt/mingw64

(3) Unpack the .b2z files to the according directories

For 64Bit tar xvf mingw-w64-bin_x86_64-linux_20131228.tar.bz2 -C /opt/mingw64
For 32Bit tar xvf mingw-w32-bin_x86_64-linux_20131227.tar.bz2 -C /opt/mingw32

(4) Create a new hello.c file in /tmp and paste the following code into it

(5) Next, you can build the Windows binaries using the following commands

For 64Bit /opt/mingw64/bin/x86_64-w64-mingw32-gcc /tmp/hello.c -o /tmp/hello-w64.exe
For 32Bit /opt/mingw32/bin/i686-w64-mingw32-gcc /tmp/hello.c -o /tmp/hello-w32.exe

You now have to Windows binaries that can be downloaded to a Windows environment.

Well, this is just a simple sample and for more complex projects you probably have to do a little more work, but it should give you the idea, how cross-compiling can be implemented.

2 thoughts on “ Build Windows executables on Linux ”

Wow Ulrich that is a very cool solution. The next step would be to test your win32 exceutables with Wine on your Linux box 😉

Источник