[libcxx-commits] [libcxx] [libc++] Don't build against libcxxrt by default on FreeBSD (PR #84484)
Rainer Orth via libcxx-commits
libcxx-commits at lists.llvm.org
Mon Mar 11 06:28:35 PDT 2024
rorth wrote:
Unfortunately, this patch only traded one failure mode for another: I've done a 2-stage build on x86_64-pc-freebsd14.4 and (as expected) that failed in stage 2:
```
452/3829] Building Attributes.inc...
FAILED: include/llvm/IR/Attributes.inc /var/llvm/local-amd64-release-libcxx/tool
s/clang/stage2-bins/include/llvm/IR/Attributes.inc
cd /var/llvm/local-amd64-release-libcxx/tools/clang/stage2-bins && /var/llvm/loc
al-amd64-release-libcxx/tools/clang/stage2-bins/bin/llvm-min-tblgen -gen-attrs -
I /vol/llvm/src/llvm-project/local/llvm/include/llvm/IR -I/var/llvm/local-amd64-
release-libcxx/tools/clang/stage2-bins/include -I/vol/llvm/src/llvm-project/loca
l/llvm/include /vol/llvm/src/llvm-project/local/llvm/include/llvm/IR/Attributes.
td --write-if-changed -o include/llvm/IR/Attributes.inc -d include/llvm/IR/Attri
butes.inc.d
ld-elf.so.1: Shared object "libc++abi.so.1" not found, required by "llvm-min-tbl
gen"
```
This is no wonder given that FreeBSD doesn't deliver `libc++abi.so.1` at all. That's why I had the cache file snippet in Issue #84476 which builds both `libcxxabi` and `libunwind` statically and folds the resulting objects into `libc++.so.1`. While this results (for lack of proviso to use the freshly built `libc++.so.1` instead of the system one) in linking the latter, it does seem to work.
GCC is way more diligent in this regard:
- It links the likes of `g++` and `cc1plus` with `-static-libstdc++` to avoid any dependencies on `RPATH`s or `LD_LIBRARY_PATH`.
- For other parts of the build and the testsuite run in particular, it goes to great lengths to set `LD_LIBRARY_PATH`, it's multilib and O/S variants so the freshly build runtime libs are found.
https://github.com/llvm/llvm-project/pull/84484
More information about the libcxx-commits
mailing list