[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