MaskRay added a comment. In D110663#3029146 <https://reviews.llvm.org/D110663#3029146>, @phosek wrote:
> In D110663#3029124 <https://reviews.llvm.org/D110663#3029124>, @MaskRay wrote: > >> In D110663#3029088 <https://reviews.llvm.org/D110663#3029088>, @phosek wrote: >> >>> The reason I removed this behavior in D101194 >>> <https://reviews.llvm.org/D101194>, aside from extra overhead introduced by >>> the extra checks, is that we've seen cases where people would have both >>> paths on their system which lead to difficult to diagnose issues where >>> Clang would pick up a library different from the one they expected. I'd >>> therefore prefer supporting only a single spelling of the triple that could >>> be configured, and making sure that Clang build on Debian uses the right >>> configuration. >> >> The problem is that when LLVM_DEFAULT_TARGET_TRIPLE is "x86_64-linux-gnu" >> (no vendor part), CMake respects it (instead of adding `unknown`) and >> installs files to `lib/clang/14.0.0/x86_64-linux-gnu/`. >> Currently clang driver only inspects the normalized >> `lib/clang/14.0.0/x86_64-unknown-linux-gnu/` and cannot find it. > > I ran into this issue the past and the solution I considered would be to > modify the CMake build of runtimes to query Clang for the triple (using > `-dumpmachine`) and use that instead of `LLVM_DEFAULT_TARGET_TRIPLE`. I still > think that change would be desirable for consistency and would be happy to > implement it. If the host compiler is GCC (`gcc -dumpmachine` => `x86_64-linux-gnu` on Debian amd64), how to query Clang for the triple? My previous comment has been edited. I believe by making Debian derivatives stick with `*-linux-gnu`, we can actually remove more code from the driver. Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D110663/new/ https://reviews.llvm.org/D110663 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
