[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++`.



More information about the cfe-commits mailing list