[PATCH] D59168: [runtimes] Move libunwind, libc++abi and libc++ to lib/clang/ and include/
Petr Hosek via Phabricator via cfe-commits
cfe-commits at lists.llvm.org
Fri Apr 19 14:46:41 PDT 2019
phosek added a comment.
In D59168#1472152 <https://reviews.llvm.org/D59168#1472152>, @jdenny wrote:
> In D59168#1470578 <https://reviews.llvm.org/D59168#1470578>, @phosek wrote:
> > In D59168#1469186 <https://reviews.llvm.org/D59168#1469186>, @jdenny wrote:
> > >
> > I was also thinking about alternative names for the library path, specifically for headers we use `include/c++` but for libraries we'll now use `lib/clang/<target>` which is not very consistent.
> Does that inconsistency cause a practical problem?
Not at the moment as far as I'm aware, but I'd like to make sure we consider all aspects to avoid more transitions in the future.
>> I was considering `lib/c++/<target>` instead
> A practical benefit might be the ability to use `-L` to expose clang's c++ libs without exposing other clang libs as well, but I'm not sure whether that's a real use case.
This may be also beneficial for other compilers that would like to support Clang's C++ library.
>> but that wouldn't work for libomp
> If we decide libomp shouldn't be version-locked, then I guess `lib/openmp/<target>` would work.
> Is it safe to assume that `lib/c++` and `lib/openmp` would manage to be as clang-dedicated as `lib/clang`? If other packages don't install to `include/c++`, then I suppose they don't install to `lib/c++`.
AFAIK no other libraries currently use `lib/c++`.
CHANGES SINCE LAST ACTION
More information about the cfe-commits