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

_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
  • [PATCH] D52050: ... John Paul Adrian Glaubitz via Phabricator via cfe-commits
    • [PATCH] D52... Fangrui Song via Phabricator via cfe-commits
    • [PATCH] D52... John Paul Adrian Glaubitz via Phabricator via cfe-commits
    • [PATCH] D52... Harald van Dijk via Phabricator via cfe-commits
    • [PATCH] D52... Fangrui Song via Phabricator via cfe-commits
    • [PATCH] D52... Harald van Dijk via Phabricator via cfe-commits
    • [PATCH] D52... John Paul Adrian Glaubitz via Phabricator via cfe-commits
    • [PATCH] D52... John Paul Adrian Glaubitz via Phabricator via cfe-commits
    • [PATCH] D52... Harald van Dijk via Phabricator via cfe-commits
    • [PATCH] D52... Harald van Dijk via Phabricator via cfe-commits
    • [PATCH] D52... John Paul Adrian Glaubitz via Phabricator via cfe-commits
    • [PATCH] D52... Harald van Dijk via Phabricator via cfe-commits
    • [PATCH] D52... Harald van Dijk via Phabricator via cfe-commits
    • [PATCH] D52... John Paul Adrian Glaubitz via Phabricator via cfe-commits

Reply via email to