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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
