[PATCH] D52050: [Driver] Fix architecture triplets and search paths for Linux x32

Harald van Dijk via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Mar 31 14:18:01 PDT 2021


hvdijk added a comment.

In D52050#2662372 <https://reviews.llvm.org/D52050#2662372>, @MaskRay wrote:

> Mostly looks good.
>
>> `clang/test/Driver/Inputs/basic_cross_linux_tree/usr/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/x32/crtbegin.o`
>
> Worth bumping the version. 4.6 is quite old and as a host compiler llvm-project has stopped supporting it. The distributions having 4.6 are all end-of-life.
> Using a new version (matching your reality) can give impression that the user who contributed the original code may still need it for a while (say 5 years).

Sure, there should be no harm in renaming 4.6.0 to the current version, 10.2.0, will do that and re-test.

> I still don't quite understand this. Shouldn't a native x32 port use `x86_64-unknown-linux-gnux32`? Why does it use the multilib style `/x32` suffix?

Apologies for the confusion, that is my fault. @glaubitz opened this change to make things work for Debian, which uses `lib/x86_64-linux-gnux32`, but I am testing both Debian and non-Debian. Non-Debian uses `libx32`, similarly to how x86_64-linux-gnu uses `lib64` regardless of whether any 32-bit libraries are installed.



================
Comment at: clang/lib/Driver/ToolChains/Gnu.cpp:2110
+  static const char *const X32Triples[] = {"x86_64-linux-gnux32",
+                                           "x86_64-unknown-linux-gnux32",
+                                           "x86_64-pc-linux-gnux32"};
----------------
MaskRay wrote:
> Personally I'd defer adding a triplet until it is proven to be used on a system.
> 
> This is not free, for every x86-64 user (even if they don't use multilib or x32), their clang driver runs need to stat the directory under lib/gcc or lib/gcc-cross.
For the first and last I know for a fact they are used as the GCC triple; /usr/lib/gcc/x86_64-linux-gnux32 and /usr/lib/gcc/x86_64-pc-linux-gnux32 definitely both exist in the wild. For the middle, x86_64-unknown-linux-gnux32, I do know for a fact this is used as a triple (it is the only valid x32 triple for Rust), but it is possible it is not used as the GCC triple anywhere, so unless someone speaks up that this is already in use somewhere, I will take that one out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D52050



More information about the cfe-commits mailing list