Title
LLVM-MinGW
Author
Martin Storsjö, martin@martin.st, No affiliation
Distribution
A packaging of LLVM together with MinGW headers/libraries, usable both as native and cross compiler for targeting Windows on X86 and ARM. Available at https://github.com/mstorsjo/llvm-mingw.
Abstract (optional)
LLVM-MinGW is a freely redistributable toolchain consisting of Clang, LLD and the other binutils replacements, together with MinGW headers and libraries.
MinGW, short for Minimalistic GNU for Windows, consists of a set of freely redistributable (reimplemented from scratch) GCC compatible platform headers, link libraries and a small set of (statically linked) extra compatibility functions. It's traditionally used with GCC and binutils and libstdc++, and it uses the Itanium C++ ABI contrary to MSVC. It produces native Windows executables, not reliant on any extra runtime (contrary to Cygwin).
Clang and the LLVM tools can impersonate both GCC/MinGW and MSVC.
Clang, LLD and the other LLVM provided tools work fine as drop-ins in an existing MinGW environment, but LLVM-MinGW is a toolchain bootstrapped from scratch using only LLVM tools, and using compiler-rt/libc++/libc++abi/libunwind instead of libgcc and libstdc++.
The toolchain originated from a desire to target Windows on ARM; GCC and binutils don't support Windows on ARM (nor ARM64), thus none of those tools could be used. It serves as something of a reference example of a fully LLVM based MinGW configuration, while the MSYS2 project now also provides such environments (with a different setup).
The toolchain tries to provide tools in the same way as a GCC/binutils based MinGW toolchain, to allow building e.g. most autotools based projects with a simple ./configure --host=aarch64-w64-mingw32.
What's unique about the environment you package LLVM for? (optional)
Windows, as a target environment, is a bit different from most other targets, by there being two fairly different environments (MSVC vs MinGW) with bigger or smaller differences along pretty much every single level of the stack.
Fun fact: The toolchain was developed while actually implementing the support in LLVM/LLD for targeting Windows on ARM64, and the toolchain was used for building a demo app (VLC) that was showcased when Microsoft presented Windows on ARM64 for developers.
What makes your distribution of LLVM unique? (optional)
What might others learn from your experience? (optional)
The ups and downs of cross compilation and cross testing, how one can get fairly decent testing and QA on commodity hardware without a budget. Staying at top-of-tree without out of tree patches has been a good strategy.
What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)
Scheduling
Due to timezones (I'm based in Europe), I'm practically only able to present between 09.00 and 14.00 PDT (with 11.30 to 14.00 PDT being more ideal).
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.
Title
LLVM-MinGW
Author
Martin Storsjö, martin@martin.st, No affiliation
Distribution
A packaging of LLVM together with MinGW headers/libraries, usable both as native and cross compiler for targeting Windows on X86 and ARM. Available at https://github.com/mstorsjo/llvm-mingw.
Abstract (optional)
LLVM-MinGW is a freely redistributable toolchain consisting of Clang, LLD and the other binutils replacements, together with MinGW headers and libraries.
MinGW, short for Minimalistic GNU for Windows, consists of a set of freely redistributable (reimplemented from scratch) GCC compatible platform headers, link libraries and a small set of (statically linked) extra compatibility functions. It's traditionally used with GCC and binutils and libstdc++, and it uses the Itanium C++ ABI contrary to MSVC. It produces native Windows executables, not reliant on any extra runtime (contrary to Cygwin).
Clang and the LLVM tools can impersonate both GCC/MinGW and MSVC.
Clang, LLD and the other LLVM provided tools work fine as drop-ins in an existing MinGW environment, but LLVM-MinGW is a toolchain bootstrapped from scratch using only LLVM tools, and using compiler-rt/libc++/libc++abi/libunwind instead of libgcc and libstdc++.
The toolchain originated from a desire to target Windows on ARM; GCC and binutils don't support Windows on ARM (nor ARM64), thus none of those tools could be used. It serves as something of a reference example of a fully LLVM based MinGW configuration, while the MSYS2 project now also provides such environments (with a different setup).
The toolchain tries to provide tools in the same way as a GCC/binutils based MinGW toolchain, to allow building e.g. most autotools based projects with a simple
./configure --host=aarch64-w64-mingw32.What's unique about the environment you package LLVM for? (optional)
Windows, as a target environment, is a bit different from most other targets, by there being two fairly different environments (MSVC vs MinGW) with bigger or smaller differences along pretty much every single level of the stack.
Fun fact: The toolchain was developed while actually implementing the support in LLVM/LLD for targeting Windows on ARM64, and the toolchain was used for building a demo app (VLC) that was showcased when Microsoft presented Windows on ARM64 for developers.
What makes your distribution of LLVM unique? (optional)
What might others learn from your experience? (optional)
The ups and downs of cross compilation and cross testing, how one can get fairly decent testing and QA on commodity hardware without a budget. Staying at top-of-tree without out of tree patches has been a good strategy.
What could be improved in upstream LLVM to make working with it easier as a downstream packager? (optional)
Scheduling
Due to timezones (I'm based in Europe), I'm practically only able to present between 09.00 and 14.00 PDT (with 11.30 to 14.00 PDT being more ideal).
Reminder that this is meant to be a 15 minute lightning talk; enough to pique
interests but follow up should be done after. Slides can always include links
to more info; we will ask that you send a PR to this repo with your slides when
they are ready.