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

John Paul Adrian Glaubitz via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Thu Apr 1 01:38:01 PDT 2021


glaubitz added a comment.

In D52050#2662656 <https://reviews.llvm.org/D52050#2662656>, @hvdijk wrote:

> I have also updated the summary to provide a more complete explanation of the changes, and hope the revised summary will answer @MaskRay's questions.



In D52050#2662648 <https://reviews.llvm.org/D52050#2662648>, @hvdijk wrote:

> In D52050#2662570 <https://reviews.llvm.org/D52050#2662570>, @glaubitz wrote:
>
>> Since I am a big fan of consistency, I would rather leave it as is (4.6) and then bump to 10.2.0 in a follow-up commit.
>
> You are right that including the bump in this commit would either force an inconsistency with basic_linux_tree, multilib_32bit_linux_tree, and multilib_64bit_linux_tree, or include more changes in here that are not related to x32. However, since we have been testing for x32 support against a pretend installation of GCC 4.6, and GCC 4.6 actually never supported x32 (initial support was added in GCC 4.7), leaving it at 4.6.0 means we are testing an impossible scenario. I am aware that we already were doing that before as well, but I do not think that changes much. Personally, I am not very happy with any of the options here.

I was actually wondering which version of GCC introduced x32 support after I posted that comment. You're right then, 4.6.0 makes no sense.

I think, however, we should bump the rest of the paths to 10.2.0 if possible.

> I am also a fan of consistency, so to me the least bad option seems to be to update all four at the same time, provided this does not result in an excessively large diff. It looks large-ish but not too bad to me; I will include it in the next update so that we know what sort of size we are dealing with. If you and @MaskRay think it is too large I can easily take it out again.
>
>> Debian actually has a /libx32 folder, but it contains the dynamic loader only which makes sense because the path to the dynamic loader is baked into the executable if I remember correctly.
>
> Right, it has a /libx32 directory for exactly that reason. /libx32/ld-linux-x32.so.2 only exists as a compatibility symlink though, the dynamic loader is really stored in /lib/x86_64-linux-gnux32.

Yep, it's just a link - as for the other architectures in Debian as well.

Either way, I'm glad this has finally been approved.


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