Building for older versions of linux

[hmaarrfk]

I was asked to open an issue to discuss my successes in building wgpu-native for older GLIBC standards.

I'm mostly here to report the success i've had at conda-forge building wgpu-native for libc 2.17 at [conda-forge](https://github.com/conda-forge/wgpu-native-feedstock/tree/main/recipe]

I was told that the reason that 2.28 is the minimum supported version is due to struggles with CIs and configurations that seemed to give trouble otherwise.

At conda-forge, the situation is a little special:

1. Very modern compilers are used (latest or second latest)
2. Very old (in this case 2.17) is targetted.

Some of this information is immortalized in our ci configuration files: https://github.com/conda-forge/wgpu-native-feedstock/blob/main/.ci_support/linux_64_.yaml You can see the gcc version and the stdlib version.

honestly, I struggle with opening these kinds of issues since I don't even know what platforms you want to target. If you are happy with the existing situation feel free to close without any comments.

I gave it a go: hmaarrfk#1 and noticed that it is the libclang that is just too old on the manylinux2014 image. At conda-forge, i notice through our azure logs that we are pulling in clang 19 so pretty modern.

I'm not sure if the rust community has a vendorered libclang that you can pull in your builds instead of that of the manylinux image you pull in

wgpu-native/.github/workflows/cd.yml

Line 226 in a3d1589

dnf install clang-devel zip -y && \

cc: @Korijn

Maybe this "existance proof" is good enough to give you ideas.

[Korijn]

Providing some historical context:

• manylinux_2_28: current
• manylinux_2_24: cd: update docker image to manylinux_2_28_x86_64 #256
• manylinux2010: Update CI to publish binary releases on git version tag #27 (this is such a long time ago already wow)
• Before then it wasn't a standardized build environment (the binaries also weren't compliant with any standard)

I hope you can get some insight into why the image was changed by examining these threads.

[hmaarrfk]

Those threads mostly hint that you guys are moving forward with the latest recommendations.

That is fine

Here is a user that requests for manylinux2014 binary.
#256 (comment)

Ultimately, it is up to you all (not me) to decide on what you want to support.

Is centos7 your intended support? You should decide if and why it is important for you instead of asking users to simply update their hosts to install software built in 2025. Once that is decided, we can work to find a solution.

[hmaarrfk]

https://github.com/rust-cross/manylinux-cross/tree/main

These might help

[Korijn]

We can just add another build to the matrix, it doesn't have to be a choice. :) wgpu-native is just providing binaries that wgpu-py reuses. I don't know that there is any specification for platform support. Also I don't maintain anything over here, just giving you some info.

Let me clarify: my intention was to be helpful :)

[hmaarrfk]

Ok well if one uses Ubuntu based images you can apparently get it to work hmaarrfk#1

Not sure if this is an acceptable solution, I mostly adapted the existing CD pipeline.

I don't know how to use the cross compilation features of https://github.com/rust-cross/manylinux-cross/ but one should be able to use it to speed up the aarch builds.

LMK if you would consider a PR for what I have now.

[almarklein]

I gave it a quick shot to see what happens in #453. It fails with:

bash: dnf: command not found

I think it would be cool if we could use manylinux2014 so that the prebuild binaries can run on older Linux versions, as long as it does not complicate the build system too much. Personally I think I think there are more important things to spent my time on, but I'm happy to review pr's on this.

[hmaarrfk]

Re: dnf: command not found
I hard a hard time getting it to work with rust-cross and the standard one at the same time.

Notice I created a system variable.

Personally I think I think there are more important things to spent my time on

I 100% agree.

I'll make the 5 line PR.

[hmaarrfk]

I'll let a maintainer "reopen" this issue if they are interested, but I am not interested in advocating for it since I believe this adds complexity and better dealt with at the PyPa level.

I've spent enough time on this at the conda(-forge) level. Users are free to try those packages that target glibc 2.17
https://github.com/conda-forge/wgpu-native-feedstock

I believe that users of wgpu are likely also interested in ML workflows which are starting to require newer glibc versions as well. so there is little incentive in helping such old machines.

#441 and #445 are much more interesting PRs for me and I would prefer focusing energy there.