[PATCH] D110663: [Driver] Support Debian multiarch style lib/clang/14.0.0/x86_64-linux-gnu runtime path and include/x86_64-linux-gnu/c++/v1 libc++ path

[Petr Hosek via Phabricator via cfe-commits]

phosek added a comment.

In D110663#3029147 <https://reviews.llvm.org/D110663#3029147>, @MaskRay wrote:

> 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?

You mean when you build runtimes with the host compiler and then use them with Clang (i.e. by using `-DLLVM_ENABLE_PROJECTS="clang;lld;libcx"`)? This has been discussed several times on llvm-dev in the past, ideally nobody should be using this mode because there's no guarantee that the host compiler is ABI compatible with Clang. Unfortunately, I believe that some projects still build that way and it might take a while to migrate them to another approach.

> 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.

Can you elaborate on it? What solution do you have in mind?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663