How to Setup a Windows Buildbot Slave

Written by: Mikael Lyngvig.

Introduction

Building LLVM on Windows using the MinGW32 or MinGW64 toolchains can seem daunting at first.  After a few days of experimentation, you gradually come to realize that it is not that difficult at all.  However, I'd like to spare you these two or three days of experimentation so that you can easily set up your own Windows build slave - or, perhaps, just build LLVM and Clang manually under Windows using the MinGW toolchains.

There are a number of reasons why you'd want to use the MinGW tools instead of, say, Microsoft Visual Studio:

  1. Microsoft Visual Studio is closed source.
  2. Microsoft Visual Studio will set you back a quite considerable sum.
  3. Microsoft Visual Studio generally only works with Microsoft-prescribed tools and technologies.
  4. The LLVM Clang++ compiler does not yet support the Microsoft C++ ABI, for which reason you are effectively forced into using MinGW if you want to do C++ using Clang++ as the front-end.  This is seen by odd unresolved symbols when doing a link by asking Clang++ to figure out how to perform the link (what tools to invoke and what libraries to use).
  5. The LLVM Clang++ compiler does not yet support the Microsoft force_inline feature for which reason you have to use the MinGW header files (such as Windows.h) when building with Microsoft Visual C++.  So, either way, you'll have to use parts of MinGW - and if you are using parts of MinGW, then why not use all of them?

A user has reported, though, that it is possible to develop your project using Microsoft Visual Studio, if only you remember to use the MinGW linker (ld) instead of letting Clang++ invoke the Microsoft link.exe linker.  Please see Appendix A for a CMakefile snippet that illustrates in what order you should link the various libraries when using ld.

Unfortunately, the excellent OpenWatcom compiler does not support the C++ standard well enough that it can be used at all.

This document will provide you with a very precise step by step procedure for setting up a new Windows build slave from scratch, where from scratch means just that: All you need is the hardware (the machine you are going to turn into a build slave), the Windows installation media, and a reasonably fast Internet connection (I suggest you wire up the box, at least during the setup).

The procedure is already pretty well documented in the Getting Started with the LLVM System guide, but I found that there are sufficient unspecified things, that I believe it makes sense to make a Windows-specific guide.   If this guide fails you, you can always resort to the Getting Started with the LLVM System guide.

Due to general lack of knowledge of Cygwin, I've chosen a method that does not rely on Cygwin.  Some of the tools required by the build process, AFAIK, are installed with Cygwin, but you don't need to start up the Cygwin bash shell (a Unix equivalent to CMD.EXE), instead you can run the build from an ordinary Windows console window.  The Cygwin binaries directory is, however, added to the path used during the build so as to make Cygwin available to the build system.

Please notice that if you are completely new to the Windows console (CMD.EXE), then your best friend is this command: dir /b /p /s \file-you-are-looking-for*.  Using that command, you can quickly locate files that you cannot otherwise locate.  For instance, I am sometimes a bit lazy and don't write the full path of a command you need to execute.

This step-by-step build slave set up procedure was written by Mikael Lyngvig.  Please contact Mikael directly if you find errors or outdated material in this document.  Any and all errors in this document are solely the responsibility of the author.

Preparing the System

Before you start out setting up a Windows build slave, you should do a number of things:

  1. You should choose a box that is fast enough to act as a build slave (2,5 GHz Core 2 Duo and up).  If you pick a slower box, you'll regret it once you've spent hours setting up the machine and then realize that it is too slow to use.  Also, you want to make sure that there's at least 6 gigabytes of RAM in the machine as ld (the GNU linker) uses a lot of memory (about 5 gigabytes) when linking clang.exe with debug info in a Subversion build.
  2. You should dedicate the machine to be an LLVM build slave, otherwise you'll probably run into issues such as your main desktop (if that's the one you use as a build slave) suddenly becomes very slow while you're playing Skyrim because a background build has started and is pulling all the juice in the system.
  3. You should decide upon a partition layout for your new machine.  If you have only one harddisk in the system, you should probably reserve, say, 65 gigabytes to Windows and allocate the rest in one huge partition to be used by the build system.  If you have two or more harddisks, you can reserve one for Windows and other software, and use another as a dedicated build device.
  4. Then I suggest you start out by (re-)installing Windows from scratch.   The main reason for doing so is that you want to be 100 percent certain why the build succeeded or failed.  If you have all sorts of old software lying around on your system, you may likely get odd and/or unwanted results, which you can then waste precious time on figuring out how they came to be.
  5. When you install Windows, create a new user account named Build.  Give it any password you like, but be sure to not use a password that you already use on your network so as to make sure that hackers and hostile build masters cannot access all of your computers on your local network (Windows by default does not ask for a password when you connect to another computer if that other computer's user's password is identical to the one you are using on the connecting computer).
  6. Now that you've (re-)installed Windows, you need to run Windows Update (Control Panel, Windows Update) over and over again, until such a time that Windows has finally updated itself completely.  This can take hours and quite a few reboots.
  7. Don't install antivirus software (simply tell the Solution Center to keep quiet about missing antivirus software).  There are two reasons for this:
  8. Mark the user Build for automatic login.  On Windows 7, you do this by running the command control userpasswords2 and then uncheck the Users must enter a user name and password to use this computer. checkbox.  Then click the Apply button and enter the user name Build and the password that you gave this account.

So far, so good.  The next chapter will detail what software packages you need to install and in what order.

Software Setup

In this chapter, you'll be walked through downloading and installing all of the software packages that are needed to do a full build including running the test suite.  If you do not plan to run the test suite, you can leave out some of these components, but given the low price of secondary storage such as harddisks, there doesn't really seem to be a good reason to do so.

Installing MinGW 32-bit

Download and install MinGW(32) using the MinGW installer found at the MinGW project at SourceForge.  Download the file marked as the default download (mingw-get-inst-YYYYMMDD.exe).  Run it then select Download latest repository catalogues (the other choice may work too, I haven't tried it).  Install to C:\Mingw32 as you'll also be installing MinGW 64-bit later on.  Select and check all checkboxes (even though you won't be needing all of them) so as to be safe rather than sorry if future changes to LLVM makes more features mandatory.

Notice: If you want to use bsdtar instead of GNU tar, you need to invoke this command: msys-get install bsdtar.  I am saying this because bsdtar seems to be more reliable and feature complete than GNU tar.

Installing MinGW 64-bit

Install MinGW-W64 by downloading the most recent version from Drangon's MinGW-W64 prebuilt binaries.  Unzip it, using 7-Zip from www.7-Zip.org, to C:\MinGW64.  Extract to C:\ as the 7-zip archive already includes the \MinGW64 part (you may want to verify that this is still the case prior to unpacking to C:\).

Notice: If you want to do a MinGW 32-bit build and/or provide a MinGW 32-bit build slave, you do not need to install MinGW 64-bit.   In fact, you should avoid doing so in the name of keeping the overall system minimally configured so as to not experience bizarre errors and unexplainable behavior due to superflous tools.

Installing GnuWin32

Install GnuWin32 by following the Looking for the latest version? link at GnuWin32 on SourceForge.net.  Download and run the executable.  Once it has run to completion, you need to run both the download and install scripts that are in the download directory (please notice that you should specify an installation directory, say, C:\GnuWin32, to the install script).  The download directory is by default identical to C:\Users\Build\Downloads\GetGnuWin32.  You almost certainly don't need all of GnuWin32 to build LLVM/Clang, but better safe than sorry.

Installing Subversion

Download and install Subversion from the Subversion download page.  Pick SlikSVN (so as to avoid registering) then follow the link and pick the appropriate version of Slik-Subversion.   Install it.  It automatically adds itself to the global PATH environment variable, so it works right away (when you open up a new console window, that is).

Installing Python v2.x

Download and install the latest recommended 32-bit release of v2.x of Python from the Python website.  You need to download and install the 32-bit release because some tools rely on the Win32 bindings, which do not yet exist for the 64-bit version of Python (AFAIK).

Installing Python v2.x SetupTools

Download and install the latest version of SetupTools for Python from the PyPi page for the SetupTools.  Be sure to pick the version that matches your Python version!

Installing Cygwin

Download and install the most recent Cygwin release from the Cygwin website.  Now for the most painful part of this guide: Picking what Cygwin components you want to install.  Unfortunately, there's no install all feature in the Cygwin installation program (perhaps because the total size is rather large), so you have to use the GUI setup program and manually pick these items:

  1. Devel/DejaGnu (search without hitting Enter as hitting Enter causes the setup program to proceed).
  2. Interpreter/tcl.
  3. Tcl/expect.

Post-Installation Setup

After you've installed all of the above, you need a small batch file (shell script) to set up your environment variables.  According to my experiences, you only need to set up the PATH environment variable.   So, go ahead and create a file named setenv.bat in the outermost directory of your LLVM build tree (D:\bld), and copy and paste the CMD.EXE code snippet below into it:

@echo off
rem This script sets up the paths BEFORE the system tools
rem so as to avoid accidentally invoking Windows tools.

rem Set up Cygwin as the fifth item in the search path
path c:\Cygwin\bin;%path%

rem Set up Python as the fourth item in the search path
path c:\Python27;C:\Python27\Scripts;%path%

rem Set up GnuWin32 as the third item in the search path
path c:\GnuWin32\bin;%path%

rem Set up MingW32 as the second item in the search path
path c:\Mingw32;c:\Mingw32\msys\1.0\bin;%path%

rem Set up MingW64 as the first item in the search path
path c:\Mingw64\bin;%path%

Notice: If you are targetting MinGW 32-bit, please leave out the last pair of lines (rem Set up MingW64... and path c:\Mingw64\bin;%path%).

Testing the Build Environment

Before we proceed to setting up the build slave, we need to verify that the configured environment is actually capable of building LLVM and Clang.  To this end, we'll manually pull all of LLVM, Clang, and the test suite and then manually start a build.  Once this has commenced and completed, we can do the formal steps required to register our new build slave with the LLVM build master.

Pulling the Sources

Open a command-prompt (CMD.EXE, found under Accessories in the Start Menu), and change to the directory on D: where you will be building LLVM:

d:
cd \bld
setenv.bat
md llvm
cd llvm

Notice: If you are only aiming to build LLVM and Clang using MinGW, you should disable your antivirus solution before proceeding.  Disable it for at least 15 minutes so that you can pull all sources without interruption.

Now you can pull the sources by using these four Subversion commands:

svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm

cd llvm\tools
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang

cd ..\projects
svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt

svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite

If you want to save yourself some work, you can copy and paste the above code snippet into a batch file by the name svnpull.bat and then run that batch file.  Then you don't have wait for each command to complete before pasting the next command.

If everything went okay and there were no error messages, you've succesfully pulled all of the relevant sources from www.llvm.org.

Making the Makefiles

Now you just need to initiate the build and then wait for a long while (about an hour) until everything has been built:

cd \bld
md llvm-build
cd llvm-build
cmake -G "MinGW Makefiles" ..\llvm

Please notice that my version of CMake (version 2.8.8) fails with a bizarre error message about some internal variable not having been set correctly when CMake was built.  I don't know the reason of this error, but I do know that if you invoke CMake a second time, with the same arguments as before, it will succeed.  Or, it did succeed on my systems...

Building the Sources

You are now ready to launch the test build:

make -j2

The option -j2 to Make instructs it to use multiple simultaneous processes when building so that it builds two files in parallel instead of just one.  If you have a Sandy Bridge Core i7, an Ivy Bridge Core i5, or an Ivy Bridge Core i7, you can use the value -j4 for even faster builds.  If you are using a single-core or single-processor system, you should leave out the -j option altogether so that Make uses only one process at a time.

Making a Buildbot Slave

This procedure is already well documented in the document How to Add Your Build Configuration to LLVM Buildbot Infrastructure, but this document aims to provide a concise and complete procedure for how to set up a Windows buildbot slave, so let's go through the few final steps in this rather long process.

Installing the Buildbot Slave

The process is very simple due to the fact that we have already installed Python's SetupTools:

cd \bld
mkdir llvm-slave
cd llvm-slave
easy_install virtualenv
virtualenv sandbox
sandbox\scripts\activate
easy_install buildbot-slave

After some downloading and installing, your new Buildbot slave should now be installed.  Please notice that all dependent packages were downloaded automatically so that you do not need to worry about installing Twisted and the remainder of packages that buildbot uses.

buildslave create-slave d:\bld\llvm-slave lab.llvm.org:9990 yourname1 password

Please write down or remember yourname1 and password: You are later going to email them to the build master at LLVM.org.  Also, please notice that I am so optimistic that I suggested you call your first build slave for "yourname1": I hope that you will one day add another build slave and perhaps another one so that LLVM gets all the build power it ever needs :-).

Now you need to edit two text files so as to provide the LLVM build server (and especially its staff) cruicial information about you and your system.   First, change into the directory info and edit the file admin (I'm showing you my file, don't reuse it blindly, but edit it to match your own values):

Mikael Lyngvig <mikael@lyngvig.org>

Save and close the admin file and then edit the host file (again, I'm showing you my configuration):

Windows 7 x64 Danish
Intel Atom 330 (X2) 1.60 GHz, 2 GB RAM

GNU g++ 4.7.1
GNU binutils 2.22
CMake 2.8.8
NO Microsoft Visual Studio installed!

If you're still awake and reading this far, you'll notice that the above system is a very slow machine...  And, yes, I did initially hope to use a spare Atom 330 box I had, but real-life experience has taught me that the GNU toolchain needs much, much more than that - especially when linking clang.exe: The build system uses about 2.6 gigabytes memory when linking clang.exe so a system with only two gigabytes of memory is simply insufficient to use as a build slave.  I got excessive trashing in return for my naivity and it took five hours of linking to link clang.exe...

Starting the Buildbot Slave

Now you just need to verify that you can actually start the buildbot slave:

buildslave start d:\bld\llvm-slave

To see if it runs, type this command:

tail -f d:\bld\llvm-slave\twistd.log

There should be lots of lines similar to the ones shown below:

2009-07-29 20:59:18+0200 [Broker,client] message from master: attached
2009-07-29 20:59:18+0200 [Broker,client] SlaveBuilder.remote_print(buildbot-full): message from master: attached
2009-07-29 20:59:18+0200 [Broker,client] sending application-level keepalives every 600 seconds

Now hit Ctrl-C to abort the slave so that you can finish the last few steps of this installation guide.

Starting the Slave when Windows Boots

Now you need to create a new batch file in d:\startup.bat:

@echo off
setlocal
call d:\setenv.bat
pushd d:\bld\llvm-slave
call sandbox\scripts\activate
popd
buildslave start d:\bld\llvm-slave
endlocal

Now we're almost at the end of this long process:

Open Windows Explorer and Copy and Paste c:\Users\Build\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\ Startup into the Address bar at the very top of Internet Explorer.  Then right-click on a white area on the right side of the two panes that appear, and select New, then Shortcut, type d:\startup.bat in the edit field that appears, and then hit Next and name it something appropriate such as Buildslave startup .

Booting the Slave as a Test

Now you just need to restart your build slave and execute the tail -f d:\bld\llvm-slave\twistd.log command to see whether or not your build slave has started.  Please do not let your slave run until after you have received word from the LLVM.org build master that your slave has been accepted as a build slave.  Otherwise, the build slave will attempt to connect to the LLVM server over and over again indefinitely until such a time that you stop it again or it is accepted as a build slave.

Congratulations, You Are Now (Almost) an LLVM Builder!

All you need to do now is to send off your username (username1) and your password (password) to the build master at LLVM.org: Her name is Galina Kistanova and she has the final say on whether your machine is powerful enough to be admitted into the exclusive group of LLVM build machines.

If you have comments, critique, ideas, proposals about this article, etc., please feel to write the author.

Appendix A: CMakefile Snippet Illustrating Link Order

Below you'll find a snippet kindly contributed by Nathan Jeffords, which illustrates the link order of the LLVM libraries:

${PLATFORM_LIBS}

#LLVMX86Disassembler
#LLVMX86AsmParser
LLVMX86AsmPrinter
LLVMX86CodeGen
LLVMX86Utils
LLVMX86Desc
LLVMX86Info

LLVMSelectionDAG

LLVMAsmPrinter

#LLVMJIT
#LLVMExecutionEngine

LLVMCodeGen
LLVMScalarOpts
LLVMTransformUtils

#LLVMipa
LLVMAnalysis
LLVMTarget

LLVMMCParser
LLVMMC

LLVMCore
LLVMSupport

Appendix B: Debugging MinGW Programs on Windows

You basically have three choices for debugging MinGW programs on Windows (that I know of!):

  1. GDB - The GNU Debugger.  This is mostly intended for nostalgic users who miss early 1980s debugging.
  2. DDD - The Data Display Debugger.  This requires that you install Cygwin, but, hey, you already did that.  If you did not install ddd when you installed Cygwin, you have to restart the Cygwin setup program and then type ddd in the search pane, select ddd, and press Enter to complete the installation.  Please notice that I did not manage to get ddd to work during the initial tries.  I guess it is because I need an X11 server.
  3. ADG - The Affinic Debugger GUI.  I tried this debugger but it only works with the Cygwin gdb, which does not support x86_64 (64-bit) Windows.

Once you've built all of LLVM and Clang using debug symbols, the default for Subversion sources, you should be able to fire up the debugger you've chosen and simply pass the path of the program you want to debug, and any arguments to it, as the arguments following the program name:

gdb d:\bld\llvm-slave\llvm\bin\clang.exe -c test.c

or

ddd d:\bld\llvm-slave\llvm\bin\clang.exe -c test.c

or

adg d:\bld\llvm-slave\llvm\bin\clang.exe -c test.c

Both of the GUI frontends run on top of gdb for which reason they cannot support executable formats not supported by gdb.


Valid CSS Valid HTML 4.01 Mikael Lyngvig
The LLVM Compiler Infrastructure
Last modified: $Date: 2012-05-27 09:13:00 +0200 (Sun, 27 May 2012) $