[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

Fangrui Song via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Oct 6 09:27:54 PDT 2021


MaskRay added a comment.

In D110663#3041672 <https://reviews.llvm.org/D110663#3041672>, @phosek wrote:

> In D110663#3041379 <https://reviews.llvm.org/D110663#3041379>, @MaskRay wrote:
>
>> In D110663#3029577 <https://reviews.llvm.org/D110663#3029577>, @phosek wrote:
>>
>>> This is going to break Fuchsia as implemented. We assume that `{x86_64,aarch64}-unknown-fuchsia` and `{x86_64,aarch64}-fuchsia` behave identically and developers are allowed to use whichever spelling they prefer. With this change that's no longer true. This may break other platforms that make similar assumptions.
>>
>> Are Fuchsia developers specifying `--target=` explicitly? I think that's the direction we don't want to support.
>
> Within Fuchsia source tree, we're trying use normalized triple (that is `${arch}-unknown-fuchsia`) but I'm aware of other projects that target Fuchsia and use different spellings. For example, Rust uses `${arch}-fuchsia`, but they also use `${arch}-unknown-linux-gnu` (rather than `${arch}-linux-gnu`).
>
>> I can special case Fuchsia to use the normalized triple, but that's code that I want to avoid.
>
> I don't think this issue is specific to just Fuchsia. Rather it seems to me like the problem is the inconsistent handling of triples on Linux and I'd like to avoid introducing workarounds for other platforms.
>
>> From my understanding of D110900 <https://reviews.llvm.org/D110900>, if a Linux distro prefers `*-linux` to `*-linux-gnu`, we should drop `--target=` normalization to make this available.
>>
>> ---
>>
>> I think clang driver does normalization so that OS and environment checks can work , otherwise the constructor `Triple::Triple` can be fooled to use `unknown`.
>> This does not mean that we should use normalized paths for include and library paths that users don't explicitly specify.
>>
>> Some ideas that normalization may not be great. Different platforms may prefer different normalization styles. For example, llvm-project's old `config.guess` may prefer the `unknown` vendor while newer `config.guess` prefers the `pc` vendor. redhat may prefer `*-linux` instead of `*-linux-gnu`. If we need to do normalization for include and library paths, we need to encode many rules. If we avoid normalization we can save much code and be less surprising.
>
> That's why I'd prefer the idea I implemented in D101194 <https://reviews.llvm.org/D101194> where we let each driver handle the normalization rather than trying to come with a single universal way that apparently doesn't exist.
>
> We would also provide a default that would be `llvm::Triple::normalize` so only the platforms that want to deviate from that would need to implement a custom logic.

Now I re-read D101194 <https://reviews.llvm.org/D101194>, it did make simplification to code like `ToolChain::getRuntimePath`, but I may not call it moving into the desired state.

I think the best approach is to avoid normalization for include/library path purpose, then we don't even need `getMultiarchTriple` overloads at all and avoid all the platform customization.
This is necessary to prevent that platforms add more conversion like (D111207 <https://reviews.llvm.org/D111207>, which I think is moving toward the wrong direction).
The correct `LLVM_DEFAULT_TARGET_TRIPLE` compensates for dropping the customization.

> For example, Rust uses `${arch}-fuchsia`, but they also use `${arch}-unknown-linux-gnu` (rather than `${arch}-linux-gnu`).

Such loosen usage is partly due to the traditional fuzzy behavior of clang driver `Generic_GCC::GCCInstallationDetector::init` but I am not sure we want to encourage it / support it in the future.
People keep adding more customization to override the previous (IMHO wrong) behavior.
Asking them to be strict and sticking with one triple is the right direction, can greatly simplify the code in clang driver, and make porting to new platforms (since they don't even need to add customization to clang driver at all!) easier.
For Rust's case, `${arch}-unknown-linux-gnu` does not look good since newer config.guess prefers `${arch}-pc-linux-gnu` now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110663



More information about the cfe-commits mailing list