phosek added a comment.

In D101194#2721390 <https://reviews.llvm.org/D101194#2721390>, @MaskRay wrote:

> I thought this was NFC:(
>
> Yeah, personally I think the previous behavior 
> (`lib/clang/13.0.0/lib/x86_64-unknown-linux-gnu/libclang_rt.asan.a`) is 
> slightly better than the new 
> `lib/clang/13.0.0/lib/x86_64-linux-gnu/libclang_rt.asan.a`.
> multiarch paths are suitable for GCC specific directories (`lib/$triple`, 
> libstdc++ `aarch64-linux-gnu/include/c++/10`, etc) but llvm specific 
> libraries don't necessarily use that.

I should have been clear, sorry about that. I think there are three separate 
issues:

1. Rather than trying various triple versions, we should use one canonical 
spelling when searching for Clang's standard and runtime libraries. That means 
less system calls and better error messages, this is what this change was 
primarily intended to do.
2. Following from the previous point, we need to decide which canonical 
spelling to use. Since we're trying to use the multiarch layout, I was 
following the Debian documentation <https://wiki.debian.org/Multiarch/Tuples> 
which is closest thing to a spec I'm aware of. The alternative would be to use 
the normalized target, the main disadvantage being that we would be diverging 
from existing quasi standard.
3. `-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=ON` gives you a different result 
depending on how you spell the targets in `-DLLVM_BUILTIN_TARGETS=` and 
`-DLLVM_RUNTIME_TARGETS=`, this is what @bjope ran into and I'd consider that a 
bug since the directory layout is an implementation detail and we should be 
able to change it without users having to change their build.

I'm working on a solution for #3 and I should have a patch ready soon. I'm 
curious about your thoughts on #2.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D101194/new/

https://reviews.llvm.org/D101194

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Reply via email to