Even if we don't patch cpython-mingw any longer, we still run
autoreconf on it (and libffi), which can cause changes to
committed files. If trying to check out a different version of
the source, this would fail unless the local changes have been
discarded.
LLVM's default host detection doesn't always work (cmake doesn't
detect and provide the target architecture, but it provides the
bitness, thus LLVM's GetHostTriple.cmake guesses on the same
architecture as running the build), thus pass it manually.
This didn't use to matter, as the tests for whether --target=<target>
works used to fail, as the toolchain isn't complete at that point.
But since 7af584ed87cc6eddb6adbc451c90fb8867469e06 in llvm-project
(November 5th 2021), the libunwind cmake tests for --target do
succeed (without noticing that linking actually will fail), and thus
can end up using the incorrectly guessed compiler target.
Thus, this fixes building the runtimes with current git main
versions of llvm-project.
Specifying -lunwind isn't needed if building a version of libcxx
after 5f9be2c3e37c0428ba56876dd84af04b8d9d8915 (Feb 2021); then
libcxx is built with -nostdlib++ which keeps automatically linking
in -lunwind if -unwindlib=libunwind is used.
In addition to the changes in 13.0.0 RC1 (listed in
9188cce153), the following changes
relevant to llvm-mingw were made:
- Allow specifying language to llvm-rc with an 0x prefix
- Let the last specified option of -mconsole/-mwindows take effect
- Support both "--opt value" and "--opt=value" for more options in lld
- Add support for the --disable-dynamicbase option spelling in lld,
in addition to the old existing --no-dynamicbase
- Fix linking with when enabling profiling
Since LLVM 13, llvm-dlltool can imply the target architecture from
a triple prefix on the tool name, so there's no more need for a
wrapper.
The *-dlltool tools are now symlinks to the main llvm-dlltool
executable. In the Windows distribution, the *-dlltool.exe used to be
copies of dlltool-wrapper.exe (which is small; 15 KB). Now they
will instead be copies of llvm-dlltool.exe. Luckily, thanks to
building with -DLLVM_LINK_LLVM_DYLIB=ON by default, llvm-dlltool.exe
is only a mere 65 KB, while it used to be much larger, e.g. around
11 MB in older releases.
The import libraries for libLLVM/libclang-cpp are rather large
(21 and 15 MB each), while it hasn't been too much of an issue
with liblldb.dll.a (which was 600 KB).
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.
Since 8368e4d54c459fe173d76277f17c632478e91add in llvm-project (pushed
on March 11 2021), the lib/builtins CMakeLists.txt sets
CMAKE_TRY_COMPILE_TARGET_TYPE to STATIC_LIBRARY, which makes the
compiler tests pass before the toolchain is fully functional, by not
doing linking tests.
This still requires manually moving the dll files to the arch specific
runtime directory.
This requires building a version of llvm past
8e11bede3a6ac11ebcc05c82fac39899feaf9534 (March 18th 2021)
Notable changes since 12.0.0 for llvm-mingw are:
llvm:
- Produce proper cross-section relative relocations on ARM and AArch64
- Fixed the calling convention for AArch64 for variadic functions involving
floats in the fixed arguments
- Added a windres compatible frontend in llvm-rc, avoiding the need for
external wrappers
- Build LLVM with -ffunction-sections and --gc-sections, shrinking
a full build of llvm-mingw without LLVM_BUILD_LLVM_DYLIB by 22%
(but llvm-mingw uses LLVM_BUILD_LLVM_DYLIB these days, which shrinks
the build even more)
- Avoid optimizing/changing function calls into stpcpy due to optimizations
- llvm-ml has improved to the point where it can build the OpenMP assembly
file without needing to use another assembler tool
lld:
- Support linking directly against DLLs without using import libraries
- Improved reliability when running on Windows, avoiding some hangs
when terminating
- Fixed linking with --export-all-symbols in combination with
-ffunction-sections
- Fixed --export-all-symbols when linking EXEs
- Fixed autoexport from LTO objects with comdat symbols
- Print warnings with a "ld.lld" prefix instead of "lld-link"
- Avoid thread exhaustion on 32 bit Windows
- Accepting more forms of options, like -static and --stack=
clang:
- Fixed reading long doubles with va_arg on x86_64
- Fixed calling std::once in a dynamically linked libstdc++
runtimes:
- Complete support for std::filesystem in libc++ (which was previously
backported to 12.0.0 in llvm-mingw too, but the previous release had
a bug in using e.g. the u8path() method when linking against the DLL
version of libc++)
- Implemented semaphores in libc++
- Provide the __gcc_personality_seh0 symbol, fixing building C code with
-fexceptions and __attribute__((cleanup))
- Simplified building/installing compiler-rt and libunwind
- Silenced lots of build warnings in OpenMP
These don't seem to be necessary in practice at the moment.
If building on top of a stripped llvm install, while there's an
older version of llvm (providing llvm-config) installed system
wide, we currently still manage to build things correctly.
(If llvm-config from LLVM 6.0 is available, build-compiler-rt.sh
fails though, but that's unaffected by this change. In current
git versions of compiler-rt, it first and foremost looks inside
the monorepo checkout instead of looking for a potentially
unrelated llvm-config binary.)
Instead set the cmake defines that indicate that libcxx is going
to be linked dynamically and going to link in libcxxabi statically,
so that libcxxabi is built statically but with dllexport attributes.
Since libcxx includes libcxxabi with
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS defined, the libcxxabi
declarations contain neither dllimport nor dllexport.
Earlier, we didn't use to include the libcxxabi headers with
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS defined, but defining
_LIBCXXABI_BUILDING_LIBRARY instead. This caused libcxxabi
declarations to be marked dllexport. If any such functions would
end up emitted as part of the libcxx object files, this would
have been necessary to get them properly exported.
In practice libcxxabi functions aren't generated while included
in libcxx (they aren't templates and/or header inline functions),
_LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS gets defined by the cmake
files, so we don't need to set this at all any longer.
Since before the LLVM 12.x branch, these aren't necessary any
longer.
(9c30bafd59bf1078bbe1c235c7c25bf7e278e2e9 and
8a73aa8c4c3ee82e7d650c6a957937713a4a9ab4 in llvm-project)
Since 9c30bafd59bf1078bbe1c235c7c25bf7e278e2e9 in llvm-project,
libcxxabi unconditionally defines _LIBCPP_BUILDING_LIBRARY while
building.
Since 8a73aa8c4c3ee82e7d650c6a957937713a4a9ab4 in llvm-project,
libcxx defines _LIBCXXABI_DISABLE_VISIBILITY_ANNOTATIONS if
LIBCXX_ENABLE_STATIC_ABI_LIBRARY is set.
This fixes linking against a DLL of libc++ while using the common headers
(generated from the static version of the library, but which work for
both shared and static versions) when calling e.g. std::filesystem::u8path.
This allows easier testing of continuing from manually set
breakpoints.
Also fix compilation for non-windows platforms where __debugbreak()
isn't defined.
This matches how it is set by default in current master versions.
This requires building a version that includes
https://reviews.llvm.org/D89863, otherwise the new/delete operators
aren't properly weak.
For x86_64 and aarch64, this requires https://reviews.llvm.org/D89231.
The C++ destructors aren't executed while doing the longjmp (contrary
to how it works MSVC's C++ exceptions), but it no longer crashes.
Notable changes in this release:
- Implicitly add the .exe suffix, even when cross compiling (matching
a behaviour change in GCC since GCC 8)
- Enable the dynamicbase flag by default in LLD
- Implemented the -wrap option in LLD
- Optimized the generated unwind data for aarch64, reducing the size
of the unwind data by around 60%
- Error out of LLD if trying to create a DLL with too many exports
This is needed since 8bd2722f65cfd7883ed9769f7bad3ff50e4c6905
(and 8e11bede3a6ac11ebcc05c82fac39899feaf9534) in llvm-project
(past the 12.x release branch), which will allow us to get rid of the
whole arch renaming part (once we can assume we're building a version
newer than that).
The dockerfiles install both tools, and the scripts that use them
(build-make.sh and build-libssp.sh) can make do with either curl
or wget, but e.g. macOS ships with curl but not wget.
Printing '<triple>' causes the shell to try to read a file named
triple. One could either quote it, or just remove the angle brackets;
removing the brackets for simplicity.
Having less available should make debugging in the docker images a bit
more accessible.
Curl is a nice-to-have at the moment, while we also have wget available
from before.
This used to be the default before, but has changed in the
latest master version of libcxx.
Previously, both libcxx and libcxxabi enabled it by default, but
we used to explicitly disable it on the libcxxabi side (and rely
on the default for libcxx). Instead explicitly set the intended
configuration state for both parts.
LLVM's OpenMP implementation only supports Windows on x86, and it
requires a MASM-compatible assembler to build it. Build UASM
for this purpose, for now. (UASM isn't available packaged in
debian/ubuntu repos.) In the future, llvm-ml should be able
to handle it instead, but it's not currently mature enough.
Not including it in the regular build-all.sh for now, as UASM
isn't generally available.
Also flush after each printout, since not all configurations (in
particular, wine) flush stderr implicitly.
This is often useful when debugging unwinding.
Martin Storsjö