Clang only picks up config files implicitly using the normalized
triple form, so use file names with "-windows-gnu" instead of
"-mingw32".
In theory, we could also want to pick up the config file implicitly
by having "<triple>-<mode>" be a symlink directly to the clang
executable. That works for regular mingw32 targets, but for the
mingw32uwp target, there's no distinction in the normalized
triple, so both would end up using the same "-windows-gnu" config
files. So as long as we want to support the mingw32uwp prefixed
tools, we need to use a wrapper.
If we never set $TARGET, we'd previously miss including $CMD_EXE
in the nested command. (This doesn't happen in actual uses of
the wrapper though, but is included for completeness.)
This matches how the corresponding variable is handled in the C
version of the wrapper.
This is the latest version, minus one commit.
The very latest commit, 20331109d1c90c19a510408ab119a76004bc41ea,
causes issues with compiling VLC; that is a VLC issue (redefining
GUIDs that now are provided by the system headers), but holding
off of that change until VLC is updated to cope with it.
Since 0c391133c9201ef29273554a1505ef855ce17668 in llvm-project
(LLVM 17), the sanitizers can be built for aarch64, and since
5ea9dd8c7076270695a1d90b9c73718e7d95e0bf (backported to
LLVM 19.1.0 RC 4), they can be built for armv7 too.
While they can be built, address sanitizer doesn't work for the
non-x86 architecture, so omit those files from the install,
to make it clear that they aren't expected to work.
Thus, in practice, this builds the ubsan and profile runtimes for
aarch64 and armv7.
This allows using the build-llvm.sh script for doing a cross build
of LLVM, while the same directory may contain a native build
which can be out of sync with the actual source.
If nothing was built and installed, the installation merging command
fails with an error like this:
cp: cannot stat '/tmp/tmp.OAj9E7UBhI/install/.': No such file or directory
Therefore, skip this step if nothing really was built and installed.
The main changes for mingw targets since 18.x is primarily
minor bug fixes. llvm-dlltool has also been improved to handle
cases of renamed imports, where the target of the rename doesn't
exist as a normal import.
These days, it seems to be installed out of the box already on the
runner images, and installing it triggers very visible warnings
about it already being installed.
These modules were already manually stripped out from the install,
but we can also skip building them entirely - this gets rid of
30% of the number of lines of log output when building python
(reducing the number of lines from 21539 to 14653 lines, for the
whole of building python for both native and a cross target).
This avoids bloating the wrapper executables, when built for
msvcrt (where the default is to enable __USE_MINGW_ANSI_STDIO
when targeting C99 or newer).
This can happen if the input command line is barely under the limit,
but ends up exceeding it due to the extra arguments that the wrapper
adds.
One could hope that _tspawnvp would set errno to a helpful error code,
to identify the issue when printing the error with _tperror(), but in
practice, it doesn't.
This avoids inflating the total size of the command line too much.
If the input command line is near the max size of a command line
(32767 characters), it may grow past that limit when adding the
arguments injected by the wrapper. If we excessively quote all
arguments that don't need to be quoted, we can more easily run
into this situation.
Thus, by avoiding excessive quoting, we reduce the risk for this
issue to happen.
This avoids the issue reported at
https://github.com/mstorsjo/llvm-mingw/issues/296.
This version fixes some cases of duplicate time.h related symbols,
in some build configurations (an issue only present in the
previous snapshot). This version also uses the right format attributes
for printf/scanf functions for Clang, enabling format string warnings
when using e.g. the mingw ansi stdio routines.
When setting up wrappers for Windows, rename clang-scan-deps.exe to
clang-scan-deps-real.exe, make clang-scan-deps.exe a wrapper, and
configure the wrapper to target executing clang-scan-deps-real.exe.
This makes sure that we always pass in crucial options like
-stdlib=libc++.
By default, our Clang executables are built with that option
hardcoded, configured with CLANG_DEFAULT_CXX_STDLIB=libc++
when built for Windows. However, we generally don't rely on this;
we assume the tools could be plain default executables, so we
try to provide wrappers on all common access paths.
This picks the architecture by looking for a triple prefix in the
nested command, and passes it as an explicit flag, to let
clang-scan-deps find it.
We also pass -stdlib=libc++, to let it find the libc++ headers
as expected.
By default these files would be installed into
${CMAKE_INSTALL_PREFIX}/share/libc++/v1, where
${CMAKE_INSTALL_PREFIX} is equal to ${PREFIX}/${arch}-w64-mingw32.
However, to avoid duplicating these files for each architecture,
install them into ${PREFIX}/share/libc++/v1 instead.
While the files aren't very large (currently weighing in at around
612 KB), they're architecture independent files (and they're
more than a few; they're currently 135 files), so we should
share them if possible.
Currently, the "macos-latest" runners aren't really the latest
version - on the contrary, they're running the oldest HW/OS.
Currently, there are macos-12, macos-13 and macos-14, and macos-latest
are the macos-12 ones.
The macos-14 ones run on Apple Silicon.
Previously, the macos-12 runners have usually managed to run the build
job in less than 3 hours. However, lately, the jobs often end up
taking much longer, over 5 hours, and have ended up exceeding the
6 hour timeout occasionally, even if they still also some times run
in the expected time of less than 3 hours.
Switch to the faster macos-14 runners (which can complete the build
job in around 1 h 40 min), to avoid these timeouts.
This sets the variable CLEAN=1 after building the tools, which makes
all the builds of the runtime libraries remove old build dirs
before building.
This is similar to, but has a slight different purpose than
the existing --wipe-runtimes, which removes the installed runtime
files. Both are useful when testing various build configurations
and investigating issues, for different testing scenarios.
The DWARF debug info should work just as well.
Since 8c03f400a837dc9333e54ab371e7904aa2bec43c in llvm-project,
llvm-symbolizer prefers DWARF over PDB if there is a DWARF section
in the inspected executable. Thus, in order to use PDB, one would
have to strip out any remnants of DWARF debug info from the executable,
like in run-lldb-tests.sh (e.g. by -Wl,-s).
For the purposes of this test, simplifying the setup to use DWARF
works just as well.
When calling make_indirect_call with a parameter which is known,
Clang, since the 18.x release, can end up producing a specialized
version of the function which omits the cfguard check call (as the
target is known) and calls the known target directly.
The function is marked with a noinline attribute, to avoid
the compiler optimizing out the cfguard check call when the
target is known, but even with a noinline function, the compiler
apparently can make a separate specialized version of it.
To avoid the compiler doing such optimizations, reference the
target function via a global variable - the compiler can't assume
anything about the contents of them (they could be altered between
initialization and reading them later).
This fixes the cfguard invalid_icall test with Clang 18.x, when
compiled with optimizations enabled.
6b6b1240e2 tried to build a
multiplatform image, by building two images separately and pushing
them one at a time, with the same name (but with a different platform).
This doesn't work as expected; the last push for the image name
replaces earlier pushes. So depending on which push finishes
last, we'd end up with either an amd64 or arm64 image, but not
one that supports both.
Instead, push two separate images just with push-by-digest, and
then create the actual tag with "docker buildx imagetools create".
Alternatively, we could build all platform variants of the main
image with Dockerfile.toolchain, simplifying the setup significantly.
The contents of such a build is marginally different though, so
keep the amd64 image as it was, for now, compiled in that environment.
The total number of exported symbols in this build configuration has
now reached the limit for the number of exported symbols in a DLL,
with the latest version of llvm-project from git.
This isn't an issue when building with Clang, as it marks many
symbols as excluded from auto-export.
This adds the following:
- LLD now uses the SOURCE_DATE_EPOCH env variable for setting the
COFF header timestamp
- LLD now also supports --lto-emit-asm and -plugin-opt=emit-llvm
in the mingw linker interface
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.
Previously, when echoing the definition of BUILD_DATE to
$GITHUB_OUTPUT, that doesn't make it available as an environment
variable. (And if it would be echoed to $GITHUB_ENV, it still
wouldn't take effect until the next step within the same job either.)
Therefore, this previously set BUILD_DATE to $(date -d "" +%s),
which seems to produce a timestamp corresponding to the start of
the current day.
Since cpython-mingw v3.11 (see cpython-mingw commit
8aeb46d09c068a1228e83b29101c17bf1ff0612a), the versionless, stable
ABI libpython3.dll gets installed, along with libpython3.dll.a.
Ideally we would use this, which gets us better flexibility, but
in practice, LLDB fails to link against this, as it doesn't expose
enough of the symbols we use and need.
Previously, we ended up with PYTHON_LIB containing two path names,
which caused CMake to print warnings about ignoring extra paths
on the command line.
This fixes issue #396.
These were missed in ad30b74173.
The mismatch between upload-artifact and download-artifact in
ad30b74173 makes the later steps
fail to download the artifacts from previous steps.
Since 7dcd8ef135147de1576c2863b963ec929a15e8cb in llvm-project
(Dec 15th), LLD can strip out the bundled DWARF debug info directly
when linking, while creating a PDB file, simplifying this test case.
Relevant changes/fixes since the last version:
- Added the new Clang option -fno-auto-import, affecting both code
generation (avoiding generating .refptr stubs) and linking
(passing --disable-auto-import, to avoid subtle runtime errors,
which could happen if code built without .refptr stubs would
autoimport symbols anyway)
- Fix issues with running the toolchain, or building sources on,
network mounts. Previously, there were issues with VirtualBox
shared folders or Remote Desktop shared folders.
- Pass LTO options from the compiler driver to the linker
- Support more LTO options in the linker
- LLD now implements the --icf=safe option properly
- Support using the -S/-s flags in LLD, to strip out DWARF debug
info and symbol table, while producing a PDB file
- Fix LTO issues around __imp_ symbols, making it support building
the base mingw-w64-crt files with LTO
- LLD now doesn't try to detect/add MSVC library directories when
linking in MinGW mode
- Fix building compiler-rt sanitizers, when libcxx is available only
in static form
- Fix building a standalone libclang_rt.atomic_dynamic for MinGW
targets
- Support for the MENUEX resource type in llvm-windres
- llvm-windres now supports referencing filenames in .rc files,
constructed from multiple concatenated string literals
- Various fixes for the llvm-windres option --preprocessor, including
the breaking change to match the new GNU windres behaviour from
binutils 2.36
- Don't look for a GCC in path when Clang is installed next to
a suitable sysroot (mostly relevant for MSYS2)
- Avoid exposing unprefixed mmap symbols in the profiling runtime,
which could lead to misdetections in user code
- Support for reading Windows thread names in LLDB
These helpers are statically linked into each DLL/EXE that uses
them.
They are primarily used for atomic access to variables that are
larger than what the platform natively can support - i.e. primarily
for accessing atomic variables larger than 8 bytes.
The fallback implementations rely on explicit locks (spinlocks
in practice).
As the locks are statically linked into each module that uses the
atomic variable, any concurrent access to such an atomic variable
from two different DLLs/EXEs wouldn't actually end up being
properly atomic.
However cross-module atomic variables (larger than 8 bytes) is
very rare so this isn't deemed to be much of a practical issue.
In GCC based toolchains, the corresponding helpers reside in
a separate shared library, libatomic-1.dll (although it can also
be linked statically).
Don't assume that any host argument indicates cross compiling for
Windows.
Update build-all to pass --host arguments to strip-llvm as well,
for consistency.
Martin Storsjö