[PATCH] D63637: Do not set an RPATH on statically-linked LLVM executables.

Richard Smith - zygoloid via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 21 10:05:55 PDT 2019


rsmith added a comment.

In D63637#1553781 <https://reviews.llvm.org/D63637#1553781>, @rnk wrote:

> I think maybe we shouldn't build libc++, and any other shared libraries that might conflict with system shared libraries, into ${builddir}/lib.


Yeah, that'd be my preference, but Chandler pointed out that that would be surprising for people who build libc++ in order to use it with GCC. Maybe we can solve that problem with better build logic, though.

> Don't we install libcxx into lib/clang/9.0.0/lib/... in the end anyway, or is libcxx not treated as a compiler runtime library?

We don't appear to. I think that would be reasonable for Clang's uses, but I don't think we have any meaningful idea of whether we're building libc++ standalone or as a Clang runtime.

Perhaps (for a monorepo checkout):

- Default to building runtime libraries into the clang runtimes directory
- Provide a flag to build standalone runtimes
- If the flag is specified, then runtimes instead go into <build area>/lib, and we implicitly disable the build of llvm, clang, lldb, lld, and so on in that checkout (eg, llvm_add_executable and llvm_add_library could add build rules that fail with a suitable error).

If we run cmake directly on (eg) the libc++ directory (not as part of a llvm + clang build), it could still default to building standalone runtimes.

Would that make sense?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63637/new/

https://reviews.llvm.org/D63637





More information about the llvm-commits mailing list