It's enough to check for the _UCRT define these days, as long
as we are including a header that pulls in the base mingw headers.
Since 8b2ece59fccf0a65257b1ba2fe8d67d7e8a2e8c1 in mingw-w64 (May 6th
2019), the mingw-w64 headers define _UCRT. Since
94a28397eec79e54ce5a8354512f43da88f815d2 (committed on the same date),
the mingw-w64 headers use 0xE00 instead of 0x1400 for UCRT.
This reverts commit 490dfffb32.
This is no longer necessary, as we now can build runtimes using
the latest LLVM 19 versions, that support building sanitizers
for all architectures.
Update to using clang-18 from the host system; version 16 or
newer is required for the implicitly selected config files
(which are used since 866d47cced);
that version changed whether the target triples are normalized
before locating config files.
This allows building runtimes with the current versions of LLVM
19.x, rather than needing to select an older version.
This is one of the packages which aren't needed by the toolchain
build itself, but is provided as a convenience to useres of the image.
Many projects that build standalone x86 assembly can use either
nasm or yasm, but lately most projects prefer nasm (which has
support for newer x86 simd extensions).
In Ubuntu 24.04, this package is no longer available.
However, this package probably never actually was needed anyway,
and was probably only provided as a convenience for users of the
docker image.
This is required for building libffi. With ubuntu-22.04 images,
the libltdl-dev package was available out of the box.
Also explicitly install swig, which we rely on - this also seems
to have been available implicitly.
This fixes building on Ubuntu 24.04 (the one currently used by
the github actions ubuntu-latest tag), by including a fix for texinfo
7.0.
Not bumping to ffmpeg 7.x, as some tests there can be flaky at times.
At this point, it is reasonably mature.
There still obviously are projects that won't build with llvm-mingw,
both due to unimplemented features that GCC/binutils have, or for
other reasons, but the toolchain has seen quite a lot of usage
since this paragraph originally was written.
The wrapper script no longer has any purpose on Unix.
Just do a plain symlink to the clang-scan-deps tool.
On Windows, the wrapper executable still is used to inject a
default -target option, if the executable name doesn't contain
a triple.
clang-scan-deps can pick it up automatically from the first argument
now.
For the windows wrapper, keep passing -target, to allow running with
a potentially foreign clang-scan-deps.exe.
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.
The wrapper script no longer has any purpose on Unix.
Just do a plain symlink to the clang-scan-deps tool.
On Windows, the wrapper executable still is used to inject a
default -target option, if the executable name doesn't contain
a triple.
clang-scan-deps can pick it up automatically from the first argument
now.
For the windows wrapper, keep passing -target, to allow running with
a potentially foreign clang-scan-deps.exe.
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.
Martin Storsjö