64363c14db
build-busybox: Disable make, copy mingw32-make.exe as make.exe
...
The built-in make is a POSIX make tool, which doesn't support
GNU make features.
As we do have GNU make, insert that as "make.exe" in the busybox
directory. Don't do that in the main llvm-mingw bin directory,
which can be used with other environments (e.g. msys2), where the
native make is to be preferred.
2026-01-08 11:34:00 +02:00
1c87f45543
dockerfile: Add an option for building busybox
2026-01-08 11:32:12 +02:00
cb92de78e7
Include arm64ec in the lists of all architectures
...
Since LLVM 21.x, the upstream support for ARM64EC in LLD and
compiler-rt is complete enough for us to be able to build it.
2025-07-17 22:48:39 +03:00
e2e9216853
wrappers: Use clang config files for defaults
...
This makes these defaults more easy to get picked up in various
use cases, when not directly executing a compiler.
2024-11-06 11:40:30 +02:00
e0964ce24c
Revert use of Clang config files
...
This reverts commit 49db4a3a159f1f0104f14f95c14adfc34dc64028570fdcd2514bff0298c56939aee0c0https://github.com/llvm/llvm-project/blob/llvmorg-19.1.1/compiler-rt/test/lit.common.cfg.py#L983
- Wine fails to build using llvm-mingw as cross compiler, because
Wine adds the --no-default-config flag to Clang while compiling,
if supported:
https://gitlab.winehq.org/wine/wine/-/blob/wine-9.19/configure.ac?ref_type=tags#L866-868
This causes llvm-mingw to omit the -rtlib=compiler-rt option
(specified in a config file), making the compiler look for libgcc
instead. Doing a check to see that linking succeeds doesn't necessarily
help here - such a check already exists, but it tests linking with
-nostdlib -nodefaultlibs:
https://gitlab.winehq.org/wine/wine/-/blob/wine-9.19/aclocal.m4?ref_type=tags#L193-L206
2024-10-14 16:35:17 +03:00
6939aee0c0
wrappers: Use clang config files for defaults
...
This makes these defaults more easy to get picked up in various
use cases, when not directly executing a compiler.
2024-10-02 15:58:00 +03:00
373c32f91a
docker: Bump the base images to Ubuntu 22.04
...
This raises the versions of bundled software, providing e.g.
autoconf 2.71, which is needed for Python 3.12.
As the releases are built (without a surrounding extra container)
on GitHub Actions these days, we don't need to hold the docker
images back to an old version for the sake of compatibility;
instead, updating to a newer version provides more modern tools
for users of the docker image.
2024-02-20 14:33:13 +02:00
a711bb4ed0
build-python: Bump libffi to version 3.4.4
...
This is the latest release version.
This requires a newer version of Autoconf than what is available
out of the box in Ubuntu 20.04.
2023-10-06 16:33:59 +03:00
fefa34fd04
build-python: Update to v3.9.7, remove patches
...
Also add gitignores/dockerignores for directories created during
the python build.
2021-11-15 21:47:55 +02:00
6769ecda7b
Dockerfile.cross: Add an option for building python
2021-08-16 12:29:52 +03:00
eaf5ac08e5
Build lldb-mi
...
Building this tool requires having a full LLVM build available;
either by installing without LLVM_INSTALL_TOOLCHAIN_ONLY (and not
stripping the llvm installation yet) or by pointing it at the
LLVM build directory instead. The latter works better for our
normal build flows.
2021-08-16 11:26:37 +03:00
133c93aee4
Dockerfile.cross: Include the tag and architecture in the directory name within the zip
2021-04-23 10:58:42 +03:00
547927e1d3
dockerfile: Install the zip tool in the base image
...
This is needed when packaging the cross built toolchains anyway.
2021-04-14 09:37:18 +03:00
82a540877d
dockerfile: Install a newer version of CMake
...
This is required if building the master version of LLVM, past the
11 release branch.
2021-04-14 09:37:18 +03:00
3fd3e58979
build-mingw-w64: Split out building tools to a separate script
...
This simplifies build-mingw-w64.sh. When building on native
windows (where we also provide unprefixed tools, we can't have
the yet incomplete compiler toolchain in $PATH when building
the mingw-w64 tools. (Logically, build-mingw-w64-tools belong
with build-llvm and install-wrappers; using the original system
compiler to build tools that are supposed to run on the current
machine, as opposed to the cross target, like when building the
runtimes.)
2020-09-16 00:03:57 +03:00
ca303864ba
Dockerfile.cross: Download a newer version of cmake than what the base distribution has
...
When building lldb for windows with the llvm 10.0.0 version,
cmake 3.13 is required. (Ubuntu 18.04 comes with cmake 3.10.2.)
2020-03-25 00:24:26 +02:00
c8d181fa90
Build a mingw32-make.exe when cross building toolchains
...
This can be used e.g. for building Qt without any MSYS installation,
and should also work for cmake, if using the mingw makefiles
generator.
2019-12-23 19:47:11 +02:00
f1168d3016
Don't rely on EXEEXT as an env variable, infer it from --host instead
2019-11-13 12:59:53 +02:00
577400a5f7
Pass $HOST to individual script with a --host parameter
...
This avoids ambiguity on distributions (such as openSUSE) where the
HOST environment variable already is set, to the hostname.
2019-11-13 12:55:39 +02:00
97ca0681bc
wrappers: Split out shared helpers for native wrapper executables to a header
2019-05-06 11:04:53 +03:00
005b8efd91
Allow building a full llvm install
2019-03-15 23:56:18 +02:00
5f56f7694b
Display the output filename after packaging the cross built toolchain
2019-01-24 13:25:16 +02:00
62b208aee2
Use llvm-objcopy/llvm-strip instead of a shell script wrapper and binutils
2019-01-24 10:58:20 +02:00
99e2fefc9d
Use nproc and sysctl -n hw.cpu for default initializing CORES
...
This avoids having to pass --build-arg CORES=n when building the
docker images.
2018-11-09 22:20:34 +02:00
f47a4009ac
Add a separate dockerfile for crosscompiling the toolchain itself
2018-10-17 22:45:54 +03:00
Martin Storsjö