Win64 Utility Build Scripts
These scripts provide an automated process for building various GNU and other
tools for Windows. In many cases, the build is a simple
process, but occasionally patches are needed. The patches are included in this
repository, in Mercurial patch queue format.
To build the utilities, the 64-bit mingw toolchain and an msys environment are required. It is quite possible that the tools will build under 32-bit mingw as well, but I have not tested this. The specific toolchain I used is:
This is downloadable from http://mingw-w64.sourceforge.net/.
Using other versions of mingw in place of the reubenvb one causes build errors. It looks like the gnulib code redefines some stat #defines in a way that is not compatible with other versions.
The msys environment can be obtained from http://www.mingw.org - using
mingw-get. The following packages are needed:
msys-m4 for gmp
msys-perl for openssl configure
msys-bison for bc`
msys-vim for general editing (not essential)
There is a full msys bundle available from
msys+7za+wget+svn+git+mercurial+cvs-rev12.7z) but the Mercurial
executable included has some issues (see below).
You need to set
/mingw to point to the mingw install directory in
<msys>/etc/fstab and run the msys shell using
<msys>/bin/sh.exe --login -i
In addition, a working version of Mercurial is required. The simplest solution
is to have Windows Mercurial installed and on your
$PATH before starting
the msys shell. The
hg command will then be available in msys.
If you use the msys from
external-binary-packages mentioned above, this
includes a copy of Mercurial, which appears to be broken. To be honest I
haven't bothered trying to work out why. The simplest solution is just to
hg.exe from the msys installation and use the Windows copy as above.
The Windows PATH should be very clean before starting msys. In particular, having GNU tools like gnuwin32 in PATH can completely confuse the configure process. For my most recent build, I had only the following in $PATH:
C:\Windows\system32 C:\Windows C:\Windows\System32\Wbem C:\Program Files\Mercurial\ C:\Utils\Vim
And of thses, Vim is not needed (there is a vim provided in msys).
The build scripts create static builds of the tools - all required libraries are linked directly in, producing executables with no external dependencies. This is a deliberate choice, even though I suspect that many people will object to the use of static builds. My main reason for taking this approach was that I wanted single file tools - no DLLs or supporting files to ship. This allows me to ship the exes with other build scripts, without any fear that I'll forget an essential DLL or dependency.
The usual objection to static builds is dependency management. What if a new release of a key library comes out with security fixes or something like that. My answer, to be honest, is that I don't really care! Until I started creating these builds, I was using Gnuwin32 builds, which are frankly ancient, and are going to be far more of a security risk than anything I build. Also the build process is straightforward enough that a rebuild when a new release comes out shouldn't be hard (and if it is, it will be for portability reasons that will affect a dynamic build just as much...)
For the same reason (single-file executables) I do not include internationalised messages (as these need the message catalogs to be shipped with the executable). It's not an issue for me, and again if someone wants to add the gettext library into the build process, it shouldn't be hard to do so. If you prefer dynamic builds, it shouldn't be too hard to modify the scripts.
The following utilities are includes (all in the bin directory).
download- downloads the archives from the internet
unpack- unpack the archive, initialise the source directory as a Mercurial repository and extract the build patches as a patch queue
configure- configure the sources
build- build the binaries
makepatch- refresh the master patch directory from the current Mercurial patch queue
clean- reset the source directory to the newly-unpacked state
The Gnu Autoconf process checks for dependencies at configure time, and configures the code to disable features where the necessary dependencies are not present. It is therefore essential to build and install all prerequisites before configuring a package. I will create a proper list of dependencies in due course, but for now the following build order is what I have used:
- autoconf (for coreutils)
- automake (for coreutils)
The packages with the most dependencies here are libarchive and wget. Most of the libraries are needed for one or the other of these.
The following packages are in progress:
- ncurses - experimental patche based on Eli Zaretskii's ezwinports build not sure it's working
- readline - no patches needed but needs ncurses and seems to fail
The following may be worth looking at:
- Get more of coreutils working
- Python ports of some coreutils (df, du, maybe others)
- Python pipe utils (joins, groups, things like that)
If you use a copy of gcc other than version 4.6.3, gzip seems to fail because of issues with MSVC_INVALID_PARAMETER_HANDLING. This looks like a compatibility issue between gcc and the gzip (gnulib) package.
The following utilities use specific runtime data files:
- openssl - certificates named cert.pem or curl-ca-bundle.crt
- wget - certificates as for openssl
- wget - config file wget.ini
- file - magic definitions magic.mgc
All of these are expected to be in the directory containing the executable. Note that other locations are checked (depending on the tool) but I consider those to be secondary for my usage.
The certificate filename curl-ca-bundle.crt for openssl is for compatibility with curl. However, I may remove this as I typically don't install curl in the same directory as these utilities.