What locations should libc++ and compiler-rt be built/installed to?

clang is, by default, a cross compiler so I welcome the use of the target triple as a part of its library locations (LLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON) but…

Should the compiler-rt static libraries be installed to:

<parent directory>/lib/clang/<clang version>/lib/<target triple>

or the same place as the standard C++ library

<parent directory>/lib/<target triple>

Where:

  • <parent directory> is the parent directory of the clang executable
  • <clang version> is the version of the clang compiler
  • <target triple> describes the target environment

Currently, their location depends whether theyare built using the ‘bootstrapping build’ or the ‘default build’ as defined in:

https://libcxx.llvm.org//BuildingLibcxx.html

However, clang only looks for the compiler-rt libraries in:

<parent directory>/lib/clang/<clang version>/lib/<target triple>

This is really a policy decision I suppose. Do the compiler-rt libraries need to be separated by compiler version and if so, why doesn’t libc++?
Also, should its location be hard coded or overridable with the ‘-L’ compiler flag

My opinion, which is only from the perspective of <aarch>-<vendor>-linux-gnu, is:
Given the cyclic dependencies of clang<-> libc++ and libc++ <-> compiler-rt, I think this means separating the build into:

  1. A ‘Projects build’ (with no runtimes) for clang and lld using gcc tools and libraries
  2. A ‘Default build’ for compiler-rt’s libclang_rt.builtins.a with clang but not libstdc++, libgcc or libatomic
  3. A ‘Default build’ for libcxx, libcxxabi, libunwind using clang and libclang_rt.builtins.a
  4. A ‘Default build’ for all compiler-rt static libraries
  5. A ‘Projects build’ for all projects.
    Finally, a native build, phew! But then we start optimising…
  6. A ‘Projects build’ for an instrumented clang
  7. A ‘Projects build’ for a training clang, lld etc.
  8. A ‘Default build’ for a training libclang_rt.builtins.a
  9. A ‘Default build’ for a training libcxx, libcxxabi, libunwind
  10. A ‘Default build’ for a training compiler-rt
  11. A ‘Projects build’ for training all projects.
    Nice, now with all that optimisation data we can build
  12. A ‘Project build’ for an optimised clang and lld
  13. A ‘Default build’ for optimised libclang_rt.builtins.a
  14. A ‘Default build’ for optimised libcxx, libcxxabi, libunwind
  15. A ‘Default build’ for optimised compiler-rt
  16. A ‘Project build’ for optimised projects using optimised libraries
    No wait…
  17. A ‘Project build’ for bolt OMG!! …

It would seem reasonable to be able to separately specify the locations of:

stddef.h - currently a hardcoded, but overridable location relative to clang
libc++.a/libc++.so - currently a hard coded but overridable location relative to clang
libclang_rt.builtins.a - a hardcoded, non overidable location relative to clang’s resource directory

This would allow each build to be inspected and debugged separately rather than installing them over each other in a chaotic manner. It would save time and space.

(OK, I do know that if I spell clang correctlly then set the resource-dir weirdly while respecifying the other two and squint a little, I can override the location - but, really!)

Installing the libc++ and compiler-rt libraries in the same place but also allowing where we look for them them to be overidden in an understandable way seems logical to me. It seems reasonably easy to do. So the question is where do they both go? :slightly_smiling_face: