jaxlib wheel hardcoded to manylinux2014 platform about jax

[hawkinsp]

In general our build script produces the tags that our release builds should produce; it doesn't try to adapt the tags to the environment.

I'm a little reluctant to run auditwheel repair because I don't want auditwheel changing the wheel.

One option would be for us to default to a relaxed tag like linux_x86_64, and change our release builds to override the tag to a manylinux tag.

[hawkinsp]

As to ongoing support: we're not sure yet. One likely possibility is at least 2_28, but we may go newer. (The thing pushing us to newer is that we would like to build with C++20).

[mrodden]

One option would be for us to default to a relaxed tag like linux_x86_64, and change our release builds to override the tag to a manylinux tag.

I think this might be easiest, because then it pushes the "generalization" step to the release process that comes after build.

I am also a bit worried about auditwheel repair changing the wheel as well, since it tries to embed any third party SO files into the zip and changes the RPATHs to use them instead of any external ones. This can be worked around with its --exclude options, but it seems too easy to miss something. My current plan is to probably write something that uses auditwheel's functionality to modify the wheel but do it in a more controlled manner. Basically, just doing the lddtree scan for all versioned symbols, collecting the max versions of libs, and then outputting the manylinux_x_y wheel, without any RPATH or SO file changes.

One likely possibility is at least 2_28, but we may go newer. (The thing pushing us to newer is that we would like to build with C++20).

I am positive this would make a lot of folks that use JAX on older systems very upset... all the users I am supporting right now seem to be on ubuntu 20 or EL8 derivatives which require glibc 2.28 or less. I haven't looked at the glibcpp versions on those distros but I am almost certain they are not C++20 level universally.