jroelofs added a comment. In https://reviews.llvm.org/D30733#697313, @Hahnfeld wrote:
> In https://reviews.llvm.org/D30733#697108, @jroelofs wrote: > > > As I said on https://reviews.llvm.org/D30214, it is inappropriate to be > > installing libc++ in the resource directory... please **do not** do that. > > > Can you give reason for that? libc++ is not version-locked to the compiler, however that directory is. I understand you want to solve your problem, but I think we (as a community) need to take a step back and look at the implications of decisions like this... and having thought through this, I think this is not a wise choice if we value long term support. Yes, this plan /could/ work for a given individual release, but I think it does not scale to use cases where the libs have been chosen by some external constraint. For example, user code built against an old version of libc++: sometimes it's ok to upgrade the compiler, but often you're stuck with a particular version of the libraries because some other software was built against them. > I can understand that header files are independent of the target architecture > but how do you handle multiple binary libraries for let's say 32 and 64 bit? Arch + multilib suffixed directories solves this problem. > This was the main motivation for the OpenMP runtime in > http://lists.llvm.org/pipermail/openmp-dev/2016-December/001612.html, please > also see My objection isn't to putting the libs in a directory that contains the arch name / multilib name, but rather it is to having that directory be a child of lib/clang/$version/{lib, include}. > https://bugs.llvm.org//show_bug.cgi?id=31300. I don't think `libc++` would be > any different here. > > Additionally, my main motiviation was for `libunwind` as explained here: > http://lists.llvm.org/pipermail/cfe-dev/2017-January/052512.html > On that thread multiple people suggested to use an extra directory for > runtime libraries, @rnk and @mgorny listed as reviewers for this patch. And I disagree. The only things that belong in clang's resource directory are the builtins, sanitizer libs, and maybe the OpenMP libs (assuming they're tied to a particular compiler version, and don't have a stable API/ABI). > If `libunwind` goes there and is added together with `libc++`, we need to add > the rpath here. And what's the reason against installing `libc++` in the same > path then? IMNSHO, libunwind does not belong in the resource directory either. Concrete suggestion (and maybe we ought to discus this more widely on cfe-dev in RFC form): create a new directory not tied to the compiler version, and place non version locked libraries there. One way that could look is something like: lib/clang/SDKs/$vendor/$platform/$abi/$arch/{lib/$multilib, include} with, for example: lib └── clang └── SDKs ├── apple │ └── darwin15 │ ├── fat │ ├── powerpc │ └── x86_64 └── ubuntu10 └── linux └── gnueabi ├── arm └── x86_64 ├── lib └── lib64 (I don't want to get in the weeds bike-shedding the specific details of this layout just yet, so take this as a general idea with room for flexibility, and a small amount of hand-waving) representing the layout for a cross compiler with SDKs for: - ppc darwin - x86_64 darwin - fat library containing several darwin targets - arm linux - x86_64 linux, with both -m32 and -m64 multilibs With this strategy, now you can have say clang-4.0 installed on your system, along with some libraries that came with it. Now if you've built things against those libs, and upgrade your clang version, you are not tied to the new libc++ that comes with it, as you would be with libc++ placed in the resource dir. https://reviews.llvm.org/D30733 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
