llvm-mingw

An LLVM/Clang/LLD based mingw-w64 toolchain

1,843

179

1,843

View on GitHub

Top Related Projects

nanobench

1,406

Simple, fast, accurate single-header microbenchmarking functionality for C++11/14/17/20

osxcross

2,851

Mac OS X cross toolchain for Linux, FreeBSD, OpenBSD and Android (Termux)

w64devkit

2,953

Portable C and C++ Development Kit for x64 (and x86) Windows

llvm-project

28,494

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.

Quick Overview

LLVM-MinGW is a project that provides a toolchain for building Windows executables using LLVM and MinGW. It aims to create a modern, LLVM-based alternative to the traditional GCC-based MinGW toolchain, offering cross-compilation capabilities for Windows targets from various host systems.

Pros

Utilizes LLVM's modern compiler infrastructure, potentially offering better optimization and faster compile times
Supports cross-compilation for Windows from Linux, macOS, and other Unix-like systems
Provides both 32-bit and 64-bit Windows targets
Includes support for various programming languages, including C, C++, and Fortran

Cons

May have compatibility issues with some existing MinGW-specific code or libraries
Smaller community and ecosystem compared to traditional MinGW
Potentially less mature and tested in production environments
Limited documentation compared to more established toolchains

Getting Started

To get started with LLVM-MinGW:

Clone the repository:

git clone https://github.com/mstorsjo/llvm-mingw.git

Build the toolchain:
```
cd llvm-mingw
./build-llvm.sh
```

Add the toolchain to your PATH:

export PATH=/path/to/llvm-mingw/bin:$PATH

Use the toolchain to compile Windows executables:

x86_64-w64-mingw32-clang++ your_source.cpp -o your_program.exe

Note: The exact steps may vary depending on your host system and specific requirements. Refer to the project's README for more detailed instructions and options.

Competitor Comparisons

mxe

1,192

MXE (M cross environment)

Pros of MXE

Supports a wider range of libraries and tools
More comprehensive cross-compilation environment
Longer development history and larger community

Cons of MXE

Larger footprint and longer build times
Less focused on LLVM-based toolchains
May include outdated package versions

Code Comparison

MXE (Makefile-based build system):

include src/mingw-w64.mk

define $(PKG)_BUILD
    cd '$(BUILD_DIR)' && $(SOURCE_DIR)/configure \
        $(MXE_CONFIGURE_OPTS)
    $(MAKE) -C '$(BUILD_DIR)' -j '$(JOBS)'
    $(MAKE) -C '$(BUILD_DIR)' -j 1 install
endef

LLVM-MinGW (CMake-based build system):

cmake_minimum_required(VERSION 3.4)
project(llvm-mingw)

set(CMAKE_C_COMPILER_WORKS 1)
set(CMAKE_CXX_COMPILER_WORKS 1)

include(ExternalProject)
ExternalProject_Add(llvm
    GIT_REPOSITORY https://github.com/llvm/llvm-project.git
    GIT_TAG main
    CMAKE_ARGS ${LLVM_CMAKE_ARGS}
)

Both projects aim to provide cross-compilation toolchains for Windows, but they differ in their approach and focus. MXE offers a broader range of packages and tools, while LLVM-MinGW specifically targets LLVM-based toolchains for MinGW-w64.

nanobench

1,406

Simple, fast, accurate single-header microbenchmarking functionality for C++11/14/17/20

Pros of nanobench

Focused on microbenchmarking, providing precise performance measurements for C++ code
Lightweight and header-only library, easy to integrate into existing projects
Supports various output formats, including CSV and JSON

Cons of nanobench

Limited scope compared to llvm-mingw, which is a full toolchain
May require additional setup for comprehensive benchmarking across different platforms
Less suitable for cross-compilation scenarios

Code Comparison

nanobench:

#include <nanobench.h>

int main() {
    ankerl::nanobench::Bench().run("my_benchmark", [&] {
        // Code to benchmark
    });
}

llvm-mingw:

# Building with llvm-mingw
x86_64-w64-mingw32-clang++ -O2 main.cpp -o output.exe

Summary

nanobench is a specialized microbenchmarking library for C++, offering precise performance measurements with minimal overhead. It's easy to integrate but has a narrower focus compared to llvm-mingw.

llvm-mingw, on the other hand, is a complete toolchain for cross-compiling Windows binaries using LLVM and MinGW-w64. It provides a broader set of tools for development and compilation but doesn't include built-in benchmarking capabilities.

Choose nanobench for specific C++ performance testing needs, and llvm-mingw for cross-platform Windows development and compilation tasks.

osxcross

2,851

Mac OS X cross toolchain for Linux, FreeBSD, OpenBSD and Android (Termux)

Pros of osxcross

Specifically designed for cross-compiling macOS binaries from Linux or other Unix-like systems
Supports a wide range of macOS SDK versions
Includes tools for packaging macOS applications and creating disk images

Cons of osxcross

Limited to macOS target platforms
Requires obtaining macOS SDK files, which may have licensing restrictions
Less frequently updated compared to llvm-mingw

Code Comparison

osxcross:

./build.sh
export PATH="$PWD/target/bin:$PATH"
x86_64-apple-darwin19-clang++ myapp.cpp -o myapp

llvm-mingw:

./build-mingw-w64.sh
export PATH="$PWD/install/bin:$PATH"
x86_64-w64-mingw32-clang++ myapp.cpp -o myapp.exe

The code examples show the basic setup and usage of both toolchains. osxcross focuses on macOS targets, while llvm-mingw is designed for Windows targets. The main difference lies in the target triple and output file extension.

llvm-mingw provides a more versatile toolchain for cross-compiling to Windows from various host systems, supporting multiple architectures. It's based on LLVM and MinGW-w64, offering better compatibility with modern C++ features. osxcross, on the other hand, specializes in macOS cross-compilation, making it the preferred choice for developers targeting Apple platforms from non-macOS systems.

w64devkit

2,953

Portable C and C++ Development Kit for x64 (and x86) Windows

Pros of w64devkit

More lightweight and portable, with a smaller download size
Includes additional tools like Vim, Git, and make
Easier to set up and use out of the box for Windows development

Cons of w64devkit

Uses older GCC compiler instead of LLVM/Clang
Less frequent updates compared to llvm-mingw
Limited cross-compilation support

Code Comparison

w64devkit (GCC):

#include <stdio.h>

int main() {
    printf("Hello from w64devkit!\n");
    return 0;
}

llvm-mingw (Clang):

#include <stdio.h>

int main() {
    printf("Hello from llvm-mingw!\n");
    return 0;
}

The code examples are identical in this case, as both toolchains support standard C. However, when using more advanced features or compiler-specific optimizations, there may be differences in how the code is written or compiled.

llvm-project

28,494

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.

Pros of llvm-project

Comprehensive LLVM ecosystem with all subprojects
Official repository maintained by LLVM developers
Broader scope and more frequent updates

Cons of llvm-project

Larger codebase, potentially more complex to navigate
Not specifically tailored for MinGW toolchain
May require additional configuration for Windows cross-compilation

Code Comparison

llvm-project:

// Example from clang/lib/Driver/ToolChains/MinGW.cpp
void MinGW::AddClangSystemIncludeArgs(const ArgList &DriverArgs,
                                      ArgStringList &CC1Args) const {
  if (!DriverArgs.hasArg(options::OPT_nobuiltininc)) {
    SmallString<128> ResourceDir(getDriver().ResourceDir);
    llvm::sys::path::append(ResourceDir, "include");
    addSystemInclude(DriverArgs, CC1Args, ResourceDir);
  }
  // ...
}

llvm-mingw:

// Example from wrappers/clang-target-wrapper.c
int main(int argc, char *argv[]) {
    const char *arch = TARGET;
    const char *target = TARGET "-w64-mingw32";
    const char *exe = argv[0];
    char *new_argv[1000];
    int i, j;
    new_argv[0] = argv[0];
    new_argv[1] = "-target";
    new_argv[2] = target;
    // ...
}

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot

README

LLVM MinGW

This is a recipe for reproducibly building a LLVM/Clang/LLD based mingw-w64 toolchain.

Benefits of a LLVM based MinGW toolchain are:

Support for targeting ARM/ARM64 (while GCC obviously does support these architectures, it doesn't support Windows on ARM)
A single toolchain targeting all four architectures (i686, x86_64, armv7 and arm64) instead of separate compiler binaries for each architecture
Support for generating debug info in PDB format
Support for Address Sanitizer and Undefined Behaviour Sanitizer
Since LLVM 16: Support for Control Flow Guard (-mguard=cf compile and link flags)

Clang on its own can also be used as compiler in the normal GNU binutils based environments though, so the main difference lies in replacing binutils with LLVM based tools.

Releases

The GitHub Releases page contains prebuilt toolchains that can be downloaded and installed by just unpacking them.

They come primarily in two different forms; packages named llvm-mingw-<version>-<crt>-ubuntu-<distro_version>-<arch>.tar.xz are cross compilers, that can be run on Linux, compiling binaries for any of the 4 target Windows architectures. Packages named llvm-mingw-<version>-<crt>-<arch>.zip are native toolchains that run on Windows (with binaries in the specified architecture), but which all can compile binaries for any of the 4 architectures.

The cross compilers come in versions running on either x86_64 or aarch64. (They're built on Ubuntu, but hopefully do run on other contempory distributions as well.)

There are packages with two different choices of CRT (C runtime) - the primary target is UCRT (the Universal C Runtime). The UCRT is available preinstalled since Windows 10, but can be installed on top of Vista or newer. The other legacy alternative is msvcrt, which produces binaries for (and uses) msvcrt.dll, which is a built-in component in all versions of Windows. This allows running directly out of the box on older versions of Windows too, without ensuring that the UCRT is installed, but msvcrt.dll is generally less featureful. Address Sanitizer only works properly with UCRT.

In addition to the downloadable toolchain packges, there are also prebuilt docker linux images containing the llvm-mingw toolchain, available from Docker Hub.

There are also nightly builds with the very latest versions of LLVM and mingw-w64 from git.

Building from source

The toolchain can be compiled for installation in the current Unix environment, fetching sources as needed:

./build-all.sh <target-dir>

It can also be built, reproducibly, into a Docker image:

docker build .

Individual components of the toolchain can be (re)built by running the standalone shellscripts listed within build-all.sh. However, if the source already is checked out, no effort is made to check out a different version (if the build scripts have been updated to prefer a different version) - and likewise, if configure flags in the build-*.sh scripts have changed, you might need to wipe the build directory under each project for the new configure options to be taken into use.

Building in MSYS2

To build in MSYS2, install the following set of packages with pacman -S --needed:

git wget mingw-w64-x86_64-gcc mingw-w64-x86_64-ninja mingw-w64-x86_64-cmake make mingw-w64-x86_64-python3 autoconf libtool

Status

The toolchain currently does support both C and C++, including support for exception handling.

It is in practice new and hasn't been tested with quite as many projects as the regular GCC/binutils based toolchains yet. You might run into issues building non-trivial projects.

Known issues

LLD, the LLVM linker, is what causes most of the major differences to the normal GCC/binutils based MinGW.

As this toolchain uses a different CRT and C++ standard library than most mingw toolchains, it is incompatible with object files and static libraries built with other toolchains. Mixing DLLs from other toolchains is supported, but only as long as CRT resources aren't shared across DLL boundaries (no sharing of file handles etc, and memory should be freed by the same DLL that allocated it).
The windres replacement, llvm-rc, isn't very mature and doesn't support everything that GNU windres does.
The toolchain defaults to using the Universal CRT (which is only available out of the box since Windows 10, but can be installed on Vista or newer) and defaults to targeting Windows 7. These defaults can be changed in build-mingw-w64.sh though.
The toolchain uses Windows native TLS support, which doesn't work properly until Windows Vista. This has no effect on code not using thread local variables.
The runtime libraries libunwind, libcxxabi and libcxx also assume that the target is Windows 7 or newer.
Address sanitizer is only supported on x86.
LLD doesn't support linker script (in the COFF part of LLD). Linker script can be used for reprogramming how the linker lays out the output, but is in most cases in MinGW setups only used for passing lists of object files to link. Passing lists of files can also be done with response files, which LLD does support. (This was fixed in qmake in v5.12.0, to use response files instead of linker script.)
Libtool based projects fail to link with llvm-mingw if the project contains C++. (This often manifests with undefined symbols like ___chkstk_ms, __alloca or ___divdi3.) For such targets, libtool tries to detect which libraries to link by invoking the compiler with $CC -v and picking up the libraries that are linked by default, and then invoking the linker driver with -nostdlib and specifying the default libraries manually. In doing so, libtool fails to detect when clang is using compiler_rt instead of libgcc, because clang refers to it as an absolute path to a static library, instead of specifying a library path with -L and linking the library with -l. Clang is reluctant to changing this behaviour. A bug has been filed with libtool, but no fix has been committed, and as libtool files are shipped with the projects that use them (bundled within the configure script), one has to update the configure script in each project to avoid the issue. This can either be done by installing libtool, patching it and running autoreconf -fi in the project, or by manually applying the fix on the shipped configure script. A patched version of libtool is shipped in MSYS2 at least.
Libtool, when running on Windows, prefers using linker script over response files, to pass long lists of object files to the linker driver, but LLD doesn't support linker script (as described above). This issue produces errors like lld-link: error: .libs\libfoobar.la.lnkscript: unknown file type. To fix this, the bundled libtool scripts has to be fixed like explained above, but this fix requires changes both to configure and a separate file named ltmain.{in,sh}. A fix for this is also shipped in MSYS2.

Additionally, one may run into other minor differences between GCC and clang.

PDB support

LLVM does support generating debug info in the PDB format. Since GNU binutils based mingw environments don't support this, there's no predecent for what command line parameters to use for this, and llvm-mingw produces debug info in DWARF format by default.

To produce debug info in PDB format, you currently need to do the following changes:

Add -gcodeview to the compilation commands (e.g. in wrappers/clang-target-wrapper.sh), together with using -g as usual to enable debug info in general.
Add -Wl,--pdb= to linking commands. This creates a PDB file at the same location as the output EXE/DLL, but with a PDB extension. (By passing -Wl,--pdb=module.pdb one can explicitly specify the name of the output PDB file.)

Even though LLVM supports this, there are some caveats with using it when building in MinGW mode; Microsoft debuggers might have assumptions about the C++ ABI used, which doesn't hold up with the Itanium ABI used in MinGW.

Top Related Projects

Convert designs to code with AI

Introducing Visual Copilot: A new AI model to turn Figma designs to high quality code using your components.

Try Visual Copilot