Use libstdc++ from system toolchain for AlmaLinux

[neildhar]

The AlmaLinux build currently builds against libstdc++ from GCC 14,
because installing clang also pulls in GCC 14, and clang automatically
picks the newest libstdc++ on the system.

Instead, pointing clang to the system GCC installation should link
against the corresponding libstdc++. This improves the portability of
the generated binaries. The AlmaLinux binaries should now be compatible
with a superset of the systems that the Ubuntu binaries are compatible
with.

We can then separately evaluate removing the Ubuntu build if this works
for all users.
(I assume these have to be separate changes anyway for CI)

New contributor declaration

• I am not making a trivial change, such as fixing a typo in a comment.

• I have written a PR description following these
  rules.

• I have run pre-commit run --from-ref origin/main --to-ref HEAD.

• Select one of the following.

  • I have added tests.
    • /test for lit tests
    • /unittest for C++ tests
    • /python/test for end-to-end tests
  • This PR does not need a test because it is a CI change.

• Select one of the following.

  • I have not added any lit tests.
  • The lit tests I have added follow these best practices,
    including the "tests should be minimal" section. (Usually running Python code
    and using the instructions it generates is not minimal.)

[ThomasRaoux]

mixing clang and gcc used to have catastrophic problems as they have different lambda ABI.
There is a risk that changing the toolschain for one of the distribution would cause significant problems

[neildhar]

@ThomasRaoux The lambda ABI is a good point, I don't know how common it is to create such a dependency in practice. I had assumed the Triton build is already counting on gcc/clang ABI compatibility since we do not require TRITON_BUILD_WITH_CLANG_LLD when consuming the prebuilt binaries, so by default we would likely use GCC for building the rest of Triton on linux.

I can think of a few paths forward, but I'll defer to you on:

1. Whether you believe this problem (of improving the binary compatibility of the distribution) is worth investing in solving
2. Whether you're okay with the risk of temporarily disrupting developers who currently rely on the AlmaLinux LLVM distribution if something doesn't work

[ThomasRaoux]

@ThomasRaoux The lambda ABI is a good point, I don't know how common it is to create such a dependency in practice. I had assumed the Triton build is already counting on gcc/clang ABI compatibility since we do not require TRITON_BUILD_WITH_CLANG_LLD when consuming the prebuilt binaries, so by default we would likely use GCC for building the rest of Triton on linux.

Well we fixed some of those problems in LLVM in the past (by removing lambda from headers) but of course it could happen again, we don't really have any protection for that.

I can think of a few paths forward, but I'll defer to you on:

1. Whether you believe this problem (of improving the binary compatibility of the distribution) is worth investing in solving

I don't

2. Whether you're okay with the risk of temporarily disrupting developers who currently rely on the AlmaLinux LLVM distribution if something doesn't work

doesn't affect me directly as we don't use this build but it does feel like it could be a bad experience for some community members and overall increase the surface area where we'll get bugs. This is my main concern.

Is there no way to use a different clang to solve the libc problem?

[neildhar]

Is there no way to use a different clang to solve the libc problem?

The initial approach I had taken was to try and point clang to the older libstdc++. That didn't quite work but I don't remember why. That would be a more incremental and palatable solution, I will take another crack at it and see if I can get it to work without adding complexity.

[ThomasRaoux]

Is there no way to use a different clang to solve the libc problem?

The initial approach I had taken was to try and point clang to the older libstdc++. That didn't quite work but I don't remember why. That would be a more incremental and palatable solution, I will take another crack at it and see if I can get it to work without adding complexity.

Thanks, that would be much better if it can work.

[neildhar]

@ThomasRaoux It turned out to work quite straightforwardly (at least in a docker container locally). However, I recognise there are still potential risks (e.g. if LLVM headers depend on the STL version in some way). So I understand if you'd still prefer to keep things as is.

[neildhar]

@ThomasRaoux do you still have reservations about this change?

If so, I will close it.