[PATCH] D89013: [libcxx] Support per-target __config_site in per-target runtime build

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

In D89013#2662167 <https://reviews.llvm.org/D89013#2662167>, @phosek wrote:

> In D89013#2660407 <https://reviews.llvm.org/D89013#2660407>, @MaskRay wrote:
>
>> Regarding
>>
>>   /usr/include/x86_64-unknown-linux-gnu/c++/v1
>>   /usr/include/c++/v1
>>
>> With GCC multiarch, some `include` search paths are preceded by machine-os-env specific suffix directories.
>> Note: 'vendor' is not there. So you may see `.../include/x86_64-linux-gnu` but there is no `.../include/x86_64-{pc,unknown}-linux-gnu`
>>
>>   /usr/local/include/x86_64-linux-gnu         # affected by sysroot, multiarch, usually nonexistent
>>   /usr/local/include                          # affected by sysroot
>>   /tmp/opt/gcc-debug/include
>>   /tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/include-fixed
>>   /tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../x86_64-pc-linux-gnu/include
>>   /usr/include/x86_64-linux-gnu               # affected by sysroot, multiarch
>>   /usr/include                                # affected by sysroot
>>
>> On Debian x86_64, `/usr/include/x86_64-linux-gnu/` exists. Adding `x86_64-pc-linux-gnu` (an possible value of `LLVM_DEFAULT_TARGET_TRIPLE`) may add more confusion.
>
> This was already discussed pretty extensively in the past, but I'll try to give a summary.
>
> In the case of GCC, compiler can only compile binaries for a single target that's set at configuration time. For example if you configured GCC with `--target=x86_64-acme-linux-gnu`,  the build links the binary as `x86_64-acme-linux-gnu-gcc` and that binary would look for headers in `/usr/include/x86_64-acme-linux-gnu` and libraries in `/usr/lib/x86_64-acme-linux-gnu` (among other paths) so there's little ambiguity.

I'd love if vendor is in the multiarch string, i.e. `/usr/include/x86_64-acme-linux-gnu` and `/usr/lib/x86_64-acme-linux-gnu`, but unfortunately that is not the case.  See my previous dump with a GCC configured with `x86_64-pc-linux-gnu`. Note that some paths are derived from the GCC installation, which has vendor part, while others are derived from `$multiarch`, which has no vendor part.

> In the case of Clang, the situation is a bit more difficult because a single compiler supports multiple targets via `--target=` option and there are different ways to spell the same target triple. For example, `x86_64-linux-gnu` and `x86_64-unknown-linux-gnu` are considered equivalent, the latter is a normalized version of the former (since you can omit emit components). The question then is where to look for headers and libraries. Currently, we always look in two locations: (1) we use `--target=<triple` as specified by the user and (2) normalized version of that target. For example if the user passes `--target=x86_64-linux-gnu`, we would first check `<prefix>/lib/x86_64-linux-gnu` and then `<prefix>/lib/x86_64-unknown-linux-gnu`.

`x86_64-linux-gnu` and `x86_64-unknown-linux-gnu` are mostly equivalent, but they matter for the driver constructed paths from GCC installation (see the `../../..` path components in `/tmp/opt/gcc-debug/lib/gcc/x86_64-pc-linux-gnu/11.0.1/../../../../lib64`).

I think it makes sense to use un-normalized paths for both `lib/gcc/x86_64-pc-linux-gnu/11.0.1` derived paths and `/usr/include/$triple` and `/usr/lib/$triple` and likely make our rules more reasonable.
We can then drop `clang/lib/Driver/ToolChains/Linux.cpp Linux::getMultiarchTriple`.
But as it stands, `Linux::getMultiarchTriple` constructed triples have no vendor part, so this patch `/usr/include/c++/$triple/c++/v1` will introduce some inconsistency.

The change will look like breaking but it actually works on Debian/Ubuntu and their derivatives. Because their GCC installation paths have no vendor: `lib/gcc/x86_64-linux-gnu`.

> In Fuchsia, we always prefer using normalized triples because that's less error prone. For example, in the past we would install libraries in `<prefix>/lib/x86_64-fuchsia` which works fine if you invoke the compiler with `--target=x86_64-fuchsia`, but if you instead use `--target=x86_64-unknown-fuchsia` (which some build systems would do), compiler would fail to find libraries because it doesn't know how to denormalize the triple. Using normalized triples addresses the issue because we can always normalize the triple to get a canonical spelling.




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

https://reviews.llvm.org/D89013