[Build] Fix llvm package to use correct glibc version checks

[HollowMan6]

Resolves #7088, #6747

Currently, we will get the following error when we try to build on a system with glic version 2.31:

: /lib64/libc.so.6: version `GLIBC_2.34' not found (required by ./lld)
: /lib64/libc.so.6: version `GLIBC_2.32' not found (required by ./lld)
: /lib64/libc.so.6: version `GLIBC_2.33' not found (required by ./lld)

The reason is that llvm-f6ded0be-ubuntu-x64 requires at least glibc 2.34 now, but the glibc version checks still thinks the minimum glibc version it requires is 2.29. So this PR fixes glibc version checks according to binary inspection:

• llvm-f6ded0be-ubuntu-x64 requires at least glibc 2.34
• llvm-f6ded0be-almalinux-x64 requires at least glibc 2.27
• llvm-f6ded0be-centos-x64 requires at least glibc 2.16

Also, we should fall back to user-configured LLVM from source build if all the glib version doesn't satisfy the needs here.

Command used to check glibc required version: objdump -T ./bin/lld | grep GLIBC_ | sed 's/.*GLIBC_\([.0-9]*\).*/\1/g' | sort -Vu

llvm-f6ded0be-ubuntu-x64/bin> objdump -T ./lld  | grep GLIBC_ | sed 's/.*GLIBC_\([.0-9]*\).*/\1/g' | sort -Vu
2.2.5
2.3
2.3.4
2.6
2.14
2.15
2.16
2.27
2.29
2.32
2.33
2.34

llvm-f6ded0be-almalinux-x64/bin> objdump -T ./lld  | grep GLIBC_ | sed 's/.*GLIBC_\([.0-9]*\).*/\1/g' | sort -Vu
2.2.5
2.3
2.3.4
2.6
2.12
2.14
2.15
2.16
2.27

llvm-f6ded0be-centos-x64/bin> objdump -T ./lld  | grep GLIBC_ | sed 's/.*GLIBC_\([.0-9]*\).*/\1/g' | sort -Vu
2.2.5
2.3
2.3.4
2.4
2.6
2.12
2.14
2.15
2.16

New contributor declaration

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

• [X] I have written a PR description following these rules.

• [X] 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
  • [X] This PR does not need a test because This is a fix related to build.

• Select one of the following.

  • [X] 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.)

[HollowMan6]

Updated the cmake/llvm-vglibc/update.sh script, it now only extracts bin/lld from the tarball to inspect glib version, so that both time and space for running the script are saved.

$ cmake/llvm-vglibc/update.sh 
LLVM revision: f6ded0be
Downloading and analyzing LLVM builds...
=========================================

Processing: ubuntu-x64
-------------------
Downloading from: https://oaitriton.blob.core.windows.net/public/llvm-builds/llvm-f6ded0be-ubuntu-x64.tar.gz
Download complete. Extracting bin/lld...
Extraction complete. Analyzing binary...
Checking binary: lld
Detected minimum GLIBC version: 2.34
Updated: triton/cmake/llvm-vglibc/ubuntu-x64.txt

Processing: almalinux-x64
-------------------
Downloading from: https://oaitriton.blob.core.windows.net/public/llvm-builds/llvm-f6ded0be-almalinux-x64.tar.gz
Download complete. Extracting bin/lld...
Extraction complete. Analyzing binary...
Checking binary: lld
Detected minimum GLIBC version: 2.27
Updated: triton/cmake/llvm-vglibc/almalinux-x64.txt

Processing: centos-x64
-------------------
Downloading from: https://oaitriton.blob.core.windows.net/public/llvm-builds/llvm-f6ded0be-centos-x64.tar.gz
Download complete. Extracting bin/lld...
Extraction complete. Analyzing binary...
Checking binary: lld
Detected minimum GLIBC version: 2.16
Updated: triton/cmake/llvm-vglibc/centos-x64.txt

=========================================
Update complete!

Current LLVM glibc version requirements:
  ubuntu-x64          : 2.34
  almalinux-x64       : 2.27
  centos-x64          : 2.16
Cleaning up temporary files...

[Jokeren]

Let me run the CI and see if anything wrong

[Jokeren]

@codex review

[ThomasRaoux]

can't we know the glibc version based on the linux distribution version? We could add that to the package name. I'm concerned about auto detecting the glibc and doing llvm local build based on build machine libc as it may not be the right thing to do when cross compiling

[neildhar]

I've given some thought to this problem, so I'll share my thoughts here. (but feel free to disregard them)

To summarise the builds:

1. The Ubuntu build uses a relatively new libc, and libstdc++ from GCC 12
2. The AlmaLinux build uses a relatively old libc, but libstdc++ from GCC 14 (ignoring the quirks of the mixed static/dynamic libstdc++ on AlmaLinux/CentOS/RHEL)
3. The CentOS build uses an old libc, and old libstdc++, but uses the pre-C++ 11 std::string ABI. (I believe it should just be deleted because this is very uncommon now https://github.com/triton-lang/triton/pull/8191)

Both libc and libstdc++ on the system need to be newer in order to build. But it's slightly awkward because the Ubuntu build has a new libc and an old libstdc++, while the AlmaLinux build has the opposite.

My thinking on a solution would be to downgrade the libstdc++ used for the AlmaLinux build (which is a simple change https://github.com/triton-lang/triton/pull/8405), so it is compatible with a superset of the systems that the Ubuntu build is compatible with. And then make the AlmaLinux LLVM binaries the only version Triton distributes. Those binaries should work on almost every system, eliminating the need for checks.

[HollowMan6]

can't we know the glibc version based on the linux distribution version?

I don't think we already have such of list available somewhere, and maintaining it can also be time-consuming, as the list won't be exhaustive and can be outdated after a while at any time.

I'm concerned about auto detecting the glibc and doing llvm local build based on build machine libc as it may not be the right thing to do when cross compiling

I think the original code already has support for setting TRITON_LLVM_SYSTEM_SUFFIX env var, which will skip the auto detecting glibc logic and should be suitable for such kind of use case.

My thinking on a solution would be to downgrade the libstdc++ used for the AlmaLinux build, so it is compatible with a superset of the systems that the Ubuntu build is compatible with. And then make the AlmaLinux LLVM binaries the only version Triton distributes. Those binaries should work on almost every system, eliminating the need for checks.

That could be another solution, but it will introduce breaking (building environments) changes for Linux distributions that use newer glibc versions, so I guess we will need to be careful if we decide to go this way, so that nothing is broken.

I'm using SUSE Linux Enterprise Server 15 SP5, and AlmaLinux LLVM binaries work for me.

[neildhar]

it will introduce breaking (building environments) changes for Linux distributions that use newer glibc versions

Both glibc and libstdc++ maintain backward ABI compatibility. We already rely on that since we don't enforce exact matches, so it makes sense to me to target the oldest possible version of both. Fortunately LLVM coding standards require maintaining compatibility with even older compilers than we are considering here.

Are you referring to something else?

[HollowMan6]

I just addressed the previously identified issue.

@codex review

[chatgpt-codex-connector[bot]]

To use Codex here, create a Codex account and connect to github.

[HollowMan6]

It makes sense to me to target the oldest possible version of both. Fortunately LLVM coding standards require maintaining compatibility with even older compilers than we are considering here.

I'm not sure about that for 100%, also if similar things, just like you mentioned in #8191, happen for AlmaLinux in the future, we will still need to revert back to using Ubuntu builds. (The CentOS-based LLVM build doesn't work on my side with SUSE Linux Enterprise Server 15 SP5). So it might still be a good idea to also have the option to base the builds on something new so that we have some kind of backup. But anyway, this is up to the maintainer's decision, and I'm OK with any possible solution.

[HollowMan6]

Conflict is now resolved after merged #8191

cc: @Jokeren

[HollowMan6]

ping @Jokeren