[Openmp-commits] [PATCH] D55725: [OpenMP] Add libs to clang-dedicated directories

Joel E. Denny via Phabricator via Openmp-commits openmp-commits at lists.llvm.org
Fri Jan 25 08:02:58 PST 2019

jdenny added a comment.

In D55725#1370622 <https://reviews.llvm.org/D55725#1370622>, @hfinkel wrote:

> > lib/clang/9.0.0/lib/linux/x86_64 is what this patch currently chooses as it's another place Clang looks. But is that any better or worse than the next option?
> So Clang always searches this directory

`ToolChain::ToolChain` in `lib/Driver/ToolChain.cpp` always looks for it (it's the last of three directories), so I think that means yes.

> but we never put anything there?

Not that I've found in the configurations I've tried.

> I vaguely recall that this is where the compiler-rt libs used to be.

I don't know.

>> Move libc++* and libunwind* from lib to the Clang-dedicated directory.
> So we have the same problem with libc++ and friends as well?

Theoretically, I think so, but I haven't experienced it, perhaps because I'm just looking much more closely at openmp in my work.

> I'd prefer that whatever solution we come up with here can be uniformly applied across subprojects.

Agreed, but it might be worthwhile to choose a guinea pig (openmp) first.  I find it difficult to think of all the possible consequences of changes like this.

> Any reason of which you can think for why libc++ and libomp should have different behaviors in this regard?

No, but I don't know why they didn't already choose the behavior I'm proposing for openmp.  A few guesses:

1. For some reason, it was decided to //move// libcxx and libunwind libraries into the Clang-dedicated directories.  My guess has been that move could potentially break backward compatibility or maybe even some permanent and reasonable use case, so, for libcxx and libunwind, moving them is opt-in using `-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=True`.  This patch addresses that issue for openmp by, instead, duplicating the libraries (probably should instead use a symlink as Jonas suggested) rather than moving them.

2. Still, my proposal is that placement of Clang's libraries early in the search path should be the default.  I've shown why that's good.  Is it ever bad?  Is there ever a case where the user expects system libraries to have precedence over Clang's own libraries by default?  I would guess a user should specify `-L` for that, but maybe some user installs alternative libraries ahead in the current path and expects that to be sufficient.

  rOMP OpenMP



More information about the Openmp-commits mailing list