This change will cause clang and the other tools to statically link
against the runtimes built in stage1. This will make the built binaries
more portable by eliminating dependencies on system libraries like
libgcc and libstdc++.
In the discussion around #116792, @rjmccall mentioned that ARCMigrate
has been obsoleted and that we could go ahead and remove it from Clang,
so this patch does just that.
Since this cache value overrides the defaults, we end up with `clang`
linked to `clang-20`, and some `${triple}-clang*` links, but we're
missing `clang++`. This makes for a toolchain with inconsistent behavior
when used in someone's `$PATH`.
We'll add the default symlinks to our list so that C and C++ programs
are both built as expected when `clang` and `clang++` are invoked.
I’m seeing a series of errors when trying to run the cmake configure
step on macOS when the cmake generator is set to Xcode. All is well if I
use the Ninja or Unix Makefile generators. Messages are all of the form:
~~~
CMake Error at …llvm-project/clang/cmake/modules/AddClang.cmake:120
(target_compile_definitions):
Cannot specify compile definitions for target "obj.clangBasic" which
is not built by this project.
Call Stack (most recent call first):
…llvm-project/clang/lib/Basic/CMakeLists.txt:57 (add_clang_library)
~~~
The remaining errors are similar but mention targets obj.clangAPINotes,
obj.clangLex, obj.clangParse, and so on.
The regression appears to have been introduced by commit 09fa2f012fcc
(Oct 14 2024) which added the code in this area.
My proposed solution is simply to add a test to ensure that the obj.x
target exists before setting its compile definitions. There is precedent
doing just this in both clang/cmake/modules/AddClang.cmake and
clang/lib/support/CMakeLists.txt as well as in the “MSVC AND NOT
CLANG_LINK_CLANG_DYLIB” path immediately above the offending line.
I’ve also made a couple of grammatical tweaks in the comments
surrounding this code.
In case it's relevant, the cmake settings and definitions I've used to
trigger these errors is:
~~~bash
GENERATOR="Xcode"
OUTDIR=build_macos
cmake \
-S "$SCRIPT_DIR/llvm" \
-B "$SCRIPT_DIR/$OUTDIR" \
-G "$GENERATOR" \
-D CMAKE_BUILD_TYPE=Release \
-D CMAKE_OSX_ARCHITECTURES=arm64 \
-D LLVM_PARALLEL_LINK_JOBS=1 \
-D LLVM_ENABLE_PROJECTS="clang;lld" \
-D LLVM_TARGETS_TO_BUILD=RISCV \
-D LLVM_DEFAULT_TARGET_TRIPLE=riscv32-unknown-elf \
-D LLVM_OPTIMIZED_TABLEGEN=Yes
~~~
(cmake v3.31.1, Xcode 16.1. I know that not all of these variables are
useful for the Xcode generator!)
Co-authored-by: Paul Bowen-Huggett <phuggett@keysom.io>
clock_gettime is a POSIX API that may not be available on platforms like
baremetal; timespec_get is the C11 equivalent. This change adds support
for using timespec_get instead of clock_gettime to improve compatibility
with non-POSIX platforms. For now, this is only enabled with LLVM libc
which implemented timespec_get in #116102, but in the future this can be
expanded to other platforms.
Related to #84879.
We'd like to build runtimes using FatLTO (see
https://llvm.org/docs/FatLTO.html for details). This gives us more
control over how libc++ can be consumed by users of our toolchain, like
the Fuchsia SDK.
Forcely disable the libc++ benchmarks on Windows build hosts. The
benchmark configuration currently does not support the cross builds on
Windows hosts.
Also removed unnecessary `CMAKE_CROSSCOMPILING` CMake option.
This is part of the effort to support for enabling plugins on windows by
adding better support for building llvm and clang as a DLL. These macros
are similar to the ones i added in #96630, but are for clang.
Added explicit symbol visibility macros definitions that are defined in
a new header and will be used to for shared library builds of clang to
export
symbols.
Updated clang cmake to define a macro to enable the symbol visibility
macros and explicitly disable them for clang tools that always use
static linking.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
# Problem
Before this patch you could not build the `stage2-LLVM` for example
because you first had to manually add it to `CLANG_BOOTSTRAP_TARGETS` in
the `Release.cmake` and also add it to
`LLVM_RELEASE_FINAL_STAGE_TARGETS` in the cmake configure run. Now you
can just use `-DLLVM_RELEASE_FINAL_STAGE_TARGETS="LLVM;clang"` on the
cmake CLI and be able to build the targets `stage2-LLVM` and
`stage2-clang` without further changes to the cache file.
# Solution
Take all `LLVM_RELEASE_FINAL_STAGE_TARGETS` elements and append them
prefixed with `stage2-` to `CLANG_BOOTSTRAP_TARGETS`. Afterwards all
duplicates are removed.
Flang for Windows depends on compiler-rt, so we need to enable it for
the stage1 builds. This also fixes failures building the flang tests on
macOS.
Fixes#100202.
In order to build LLDB project added the following changes:
* enable LIBCXX_ENABLE_STATIC_ABI_LIBRARY option to link the ABI library statically.
* set LIBCXX_ABI_VERSION to 1 by default.
Fix the builds with LLVM_TOOL_LLVM_DRIVER_BUILD enabled.
LLVM_ENABLE_EXPORTED_SYMBOLS_IN_EXECUTABLES is not completely
compatible with export_executable_symbols as the later will be ignored
if the previous is set to NO.
Fix the issue by passing if symbols need to be exported to
llvm_add_exectuable so the link flag can be determined directly
without calling export_executable_symbols_* later.
CMake -GXcode would otherwise offer to create one scheme for each
target, which ends up being a lot. For now, limit the default to the
`check-*` LIT targets, plus `ALL_BUILD` and `install`.
For targets that aren't in the default list, we now have a configuration
variable to promote an extra list of targets into schemes, for example
`-DLLVM_XCODE_EXTRA_TARGET_SCHEMES="TargetParserTests;SupportTests"` to
add schemes for `TargetParserTests` and `SupportTests` respectively.
This adds release binary builds for the 4 platforms currently supported
by the free GitHub Action runners:
* Linux x86_64
* Windows x86_64
* Mac x86_64
* Mac AArch64
The test stages for these are known to fail, but the creating and
upoading of the release binaries should pass.
These are needed for cortex-m33. Ideally in the future we'd have
separate multilibs for different ABI configs and we wouldn't need to
explicitly set cortex-m33 manually. The driver should handle it.
We are seeing a PyYaml issue after the new libc_hdrgen was enabled by
default. This patch disables it in Fuchsia toolchain build so we restore
the builder while we are investigating.
