LLVM/Clang on Windows/MinGW revisited

Configuring a Static Build

A static build has the nice property that everything will be self-contained. That’s especially useful for the Clang tools – like clang-format. Being able to copy clang-format.exe around and use it from anywhere without the need of a properly set up toolchain environment definitely outweighs the disadvantage of slightly larger sizes of the binaries.

Run CMake from the build directory. Adjust paths as needed. If you need a full overview over the valid options, have a look at llvm-3.9.1.src\docs\CMake.rst.

cmake %tcroot%\src\std\llvm-3.9.1.src -G Ninja -DCMAKE_BUILD_TYPE=Release ^
-DLLVM_TARGETS_TO_BUILD=AArch64;ARM;X86;AMDGPU ^
-DLLVM_BUILD_TOOLS=ON -DLLVM_INCLUDE_EXAMPLES=OFF ^
-DLLVM_BUILD_TESTS=OFF -DLLVM_INCLUDE_TESTS=OFF ^
-DLLVM_ENABLE_EH=ON -DLLVM_ENABLE_RTTI=ON ^
-DCMAKE_C_COMPILER=gcc -DCMAKE_CXX_COMPILER=g++ ^
-DCMAKE_CXX_FLAGS=-std=c++11 ^
-DGCC_INSTALL_PREFIX=%syspath% -DCMAKE_INSTALL_PREFIX=%syspath% ^
-DCMAKE_EXE_LINKER_FLAGS="-static-libgcc -static-libstdc++ -static -lstdc++ -lpthread" ^
-DBUILD_SHARED_LIBS=OFF ^
-DLLVM_PARALLEL_COMPILE_JOBS=6 -DLLVM_PARALLEL_LINK_JOBS=6

Some notes about the command line:

• The targets are the target architectures LLVM/Clang will be able to produce binaries for. Shown here are ARM 64bit, ARM 32bit, x86 (both 64bit and 32bit) and AMD graphics cards, as these are the only architectures I’ll ever need. The directories in llvm-3.9.1.src\lib\Target seem to represent the list of all available targets.
• GCC_INSTALL_PREFIX must point to the directory that contains the main bin directory of your MinGW installation. It tells Clang where to find libstdc++ so you don’t manually have to add the header locations every time you compile something with the new Clang.
• CMAKE_INSTALL_PREFIX can probably be different from GCC_INSTALL_PREFIX. But since Clang is tied to libstdc++ anyway I think it makes sense to install it as kind of an extension of the the MinGW/GCC distribution.
• The best number of parallel jobs obviously depends on how many CPUs/cores your machine has.

CMake will take some seconds to run. Make sure to check the output for anything fishy. Especially all your target architectures should be listed as well as LLD and Clang with their versions.

Configuring a Shared Build

The CMake command line looks very similar. You only need to change two things:

• Omit the complete -DCMAKE_EXE_LINKER_FLAGS option.
• Use -DBUILD_SHARED_LIBS=ON instead of OFF.

Compiling and Installing

Run:

cmake --build .

Even though we build in release mode the binaries still contain debug symbols. I like to save some space and strip the symbols from the .exe files. For the DLLs, especially libClang, the symbols might come in handy for debugging at some point, so I keep them.

strip bin\*.exe
cmake --build . --target install

Using Make instead of Ninja

Running jobs in parallel with Make is really unrealiable. You have to keep the number low or you’ll run into weird race condition errors that may or may not be solved by simply running Make again. In my experience two parallel jobs are the safe-ish maximum. Of course that makes Make a lot slower than Ninja.

When configuring a Make-based build, the CMake command line looks very similar to the Ninja one. Except:

• Use -G "MinGW Makefiles" instead of -G Ninja.
• Omit the two LLVM_PARALLEL options. They only work with Ninja.

To compile, run:

mingw32-make -j2 && echo Success!

• Don’t omit the success sentinel. When running in multi-job mode Make is extremely bad at indicating failure. The end of the output might look completely ok, but an error can be hidden several pages above.
• If you run into a Permission denied error during linking, don’t panic. That is such a race conditions between parallel jobs. Just run Make again. If the error doesn’t go away after 2–3 tries, lower your job count and try again. The worst thing that can happen is that you’ll have to finish building with a single job.