MaskRay added a comment. In D101194#2721597 <https://reviews.llvm.org/D101194#2721597>, @phosek wrote:
> 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. multiarch is not consistent within GCC, either (also note that not all GCC installations are configured with multiarch.). I have tried some examples, see https://maskray.me/blog/2021-03-28-compiler-driver-and-cross-compilation : even if the multiarch triple for x86_64 Linux is `x86_64-linux-gnu`, there are a few `x86_64-pc-linux-gnu` paths. (You can configure and get `x86_64-pc-linux-gnu-gcc` or `x86_64-unknown-linux-gnu-gcc`) For musl systems (`*-linux-musl`), multiarch doesn't make sense. If we use multiarch, we'll need to invent `*-linux-musl` for them. For some GCC related paths, we have no choice but to detect their paths. For entirely clang internal stuff (runtime library paths), I actually appreciate that we have a useful, un-normalized 'vendor' part. It gives users a choice if they want to have `x86_64-pc[12345]-linux-gnu`. This argument is weak, but the other arguments are probably stronger. --- I haven't figured out how to do a proper runtime build... `-DLLVM_ENABLE_PER_TARGET_RUNTIME_DIR=on -DLLVM_RUNTIME_TARGETS=default -DLLVM_ENABLE_RUNTIMES='compiler-rt;libcxx;libunwind' ` gives me CMake Error at /usr/share/cmake-3.18/Modules/ExternalProject.cmake:3152 (add_custom_target): add_custom_target cannot create target "builtins" because another target with the same name already exists. The existing target is a custom target created in source directory "/home/maskray/llvm/compiler-rt/lib/builtins". See documentation for policy CMP0002 for more details. Call Stack (most recent call first): cmake/modules/LLVMExternalProjectUtils.cmake:283 (ExternalProject_Add) runtimes/CMakeLists.txt:81 (llvm_ExternalProject_Add) runtimes/CMakeLists.txt:134 (builtin_default_target) 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
