When building LLVM baremetal targets with LLVM libcxx and LLVM libc,
certain FILE related C functions do not exist and this causes build
failures. This patch updates the workaround for this to mitigate a build
failure after d750c6de8a75cbe2bc16c136764195471be8f0b7 got landed.
Fixes the changes introduced in
https://github.com/llvm/llvm-project/pull/126675 and subsequently
reverted by https://github.com/llvm/llvm-project/pull/126934 .
Originally, I mistakenly put the `install` in the wrong location (should
have been in the `add_clang_tool` macro) which slipped through testing.
I've verified locally using the same CMake configure options.
For reference:
* **CMake Configure**
```
cmake -B build -S llvm -GNinja -DLLVM_ENABLE_PROJECTS="llvm;clang;lld;compiler-rt" -DCMAKE_BUILD_TYPE=Release -DLLVM_ENABLE_PDB=ON -DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_C_COMPILER=cl -DCMAKE_CXX_COMPILER=cl
```
* **Error**
```
TARGET_PDB_FILE is allowed only for targets with linker created artifacts.
```
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.
