[libc++] Don't build against libcxxrt by default on FreeBSD

[ldionne]

The libc++ CMake build aims to provide a general-purpose configuration that matches the canonical LLVM setup (libc++ / libc++abi / libunwind), not the configuration used for compatibility on any given system. For these "compatibility" configurations, we use CMake caches like Apple.cmake and FreeBSD.cmake.

Defaulting to libcxxrt on FreeBSD makes it look as though we're trying to build the system compatible configuration on FreeBSD, which isn't really correct and causes confusion more than anything else.

Fixes #84476

[llvmbot]

@llvm/pr-subscribers-libcxx

Author: Louis Dionne (ldionne)

Changes

The libc++ CMake build aims to provide a general-purpose configuration that matches the canonical LLVM setup (libc++ / libc++abi / libunwind), not the configuration used for compatibility on any given system. For these "compatibility" configurations, we use CMake caches like Apple.cmake and FreeBSD.cmake.

Defaulting to libcxxrt on FreeBSD makes it look as though we're trying to build the system compatible configuration on FreeBSD, which isn't really correct and causes confusion more than anything else.

Fixes #84476

---

Full diff: https://github.com/llvm/llvm-project/pull/84484.diff

1 Files Affected:

• (modified) libcxx/CMakeLists.txt (-2)

diff --git a/libcxx/CMakeLists.txt b/libcxx/CMakeLists.txt
index d392e95077ac57..e565c47c76687a 100644
--- a/libcxx/CMakeLists.txt
+++ b/libcxx/CMakeLists.txt
@@ -229,8 +229,6 @@ option(LIBCXX_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 # ABI Library options ---------------------------------------------------------
 if (MSVC)
   set(LIBCXX_DEFAULT_ABI_LIBRARY "vcruntime")
-elseif (${CMAKE_SYSTEM_NAME} MATCHES "FreeBSD")
-  set(LIBCXX_DEFAULT_ABI_LIBRARY "libcxxrt")
 else()
   set(LIBCXX_DEFAULT_ABI_LIBRARY "libcxxabi")
 endif()

[ldionne]

@DimitryAndric Are you OK with this?

[DimitryAndric]

Yes, this is fine. As long as you can still override LIBCXX_DEFAULT_ABI_LIBRARY from the CMake command line, and it keeps working. :)

[ldionne]

Merging since this passed the FreeBSD CI, which is what matters. We're having CI issues in the rest of our Actions builders.

[rorth]

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 RPATHs 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.

[ldionne]

That problem is vastly different though, this has to do with how the build of LLVM / Clang is set up (apparently incorrectly). I believe we are now doing the right thing on FreeBSD from the point of view of libc++. I believe the best course of action here would be to open a bug report against LLVM so this can be investigated without confusing the two issues together.

[DimitryAndric]

Yes, I have seen this problem before when doing a multi-stage build. The intermediate tblgen binaries are linked against the freshly produced libc++.so.1, and in turn this libc++.so.1 has a NEEDED entry for libc++abi.so.1, but no RPATH or RUNPATH entry. It really should have one, since it is not supposed to go look for libc++abi.so.1 in any system directory, only its own runtime library directory.

[rorth]

I'll leave this to others then: it doesn't concern me on my primary platform (Solaris, which has no libc++, bundled or otherwise). My foray into FreeBSD has already taken way too much time and energy.