Is it possible to disable the triple that LLVM 15 added to the libc++{abi} library path?

Runtimes C++
1

In LLVM 14 (and earlier) libc++.so, libc++abi.so, and friends all land in /installation-path/lib/.

In LLVM 15+ they land in /installation-path/lib/x86_64-unknown-linux-gnu/ (for example).

But clang’s only RUNPATH entry is for $ORIGIN/../lib. So when building a libcxx-dependent clang (-DLLVM_ENABLE_LIBCXX=ON) on a system where libcxx is not already installed, the resulting clang binary fails to find libc++.so.

  1. Is there an option to disable the triple in the path? I found LIBCXX_INSTALL_LIBRARY_DIR but in the code it appears to always have LLVM_DEFAULT_TARGET_TRIPLE appended.
  2. Is it expected that clang should not depend on the libc++.so in its install directory and only use the newly built libc++.so if it’s installed as a system default?

Thank you for any help understanding this.

2

LLVM builds will, by default, use the system libraries unless you force it not to. If you do force it to use a non-system shared library, it’s your responsibility to ensure LLVM binaries can find it. This applies to all libraries, not just libc++. If you managed to rig a configuration where installed LLVM binaries somehow depend on a just-built libc++, that’s basically getting lucky.

My team does actually do builds with a non-system libc++, but we just use a pre-built binary, and copy it to the install directory.

3

Thank you for the clarification.

If you managed to rig a configuration where installed LLVM binaries somehow depend on a just-built libc++, that’s basically getting lucky.

I understand your overall point, but in LLVM 14 and earlier I believe the only “rigging” required is:

  • A machine where libc++ is not already installed
  • -DCMAKE_INSTALL_PREFIX=<somewhere>

That’s it. As I mentioned, clang’s RUNPATH defaults to [$ORIGIN/../lib], and libc++ was placed directly in <somewhere>/lib for releases < 15. So while it may have been lucky, the luck appeared intentional to me (“prefer the libraries in the installation directory”). :slight_smile:

Anyway, I appreciate you clearing that up. It’s good to learn that behavior was not intentional.

I will either symlink/move the libraries around or adjust RUNPATH as needed for my case.

4

Ran into similar issues, though I have configured to use $ORIGIN/…/$LIB in mine so lib and lib64 are also in play, my install system I just added symbolic links.

I run something effectively like this as part of my source install system before building llvm, libc++, clang etc

mkdir -p       /installation-path/lib  /installation-path/lib64
ln -s ../lib   /installation-path/lib/i686-unknown-linux-gnu
ln -s ../lib   /installation-path/lib64/i686-unknown-linux-gnu
ln -s ../lib64 /installation-path/lib/x86_64-unknown-linux-gnu
ln -s ../lib64 /installation-path/lib64/x86_64-unknown-linux-gnu