Warn users that the default manylinux of `auto` may cause build failures

[sxlijin]

Hi - we just found out that because the default manylinux selected is 2014, this has a strong likelihood of causing a build failure if your library has rustls as a dependency.

Specifically, the ring crate does not compile with gcc-4.8.0 on arm64-linux: briansmith/ring#1728

Our dependency on ring is implicit/transitive via rustls:

❯ cargo tree -i -p ring
ring v0.17.8
├── aws-config v1.5.3
│   └── baml-runtime v0.46.0 (/Users/sam/baml/engine/baml-runtime)
│       ├── baml v0.46.0 (/Users/sam/baml/engine/baml-cli)
│       ├── baml-python-ffi v0.1.0 (/Users/sam/baml/engine/language_client_python)
│       ├── baml-schema-build v0.46.0 (/Users/sam/baml/engine/baml-schema-wasm)
│       ├── baml-typescript-ffi v0.0.1 (/Users/sam/baml/engine/language_client_typescript)
│       └── ruby_ffi v0.1.0 (/Users/sam/baml/engine/language_client_ruby/ext/ruby_ffi)
├── rustls v0.21.12
│   ├── aws-smithy-runtime v1.6.0
│   │   ├── aws-config v1.5.3 (*)
│   │   ├── aws-sdk-bedrockruntime v1.37.0
│   │   │   └── baml-runtime v0.46.0 (/Users/sam/baml/engine/baml-runtime) (*)
│   │   ├── aws-sdk-sso v1.33.0
│   │   │   └── aws-config v1.5.3 (*)
│   │   ├── aws-sdk-ssooidc v1.34.0
│   │   │   └── aws-config v1.5.3 (*)
│   │   ├── aws-sdk-sts v1.33.0
│   │   │   └── aws-config v1.5.3 (*)
│   │   └── baml-runtime v0.46.0 (/Users/sam/baml/engine/baml-runtime) (*)
│   ├── hyper-rustls v0.24.2
│   │   ├── aws-smithy-runtime v1.6.0 (*)
│   │   └── reqwest v0.11.27
│   │       ├── baml v0.46.0 (/Users/sam/baml/engine/baml-cli)
│   │       └── check-latest v1.0.2
│   │           └── baml v0.46.0 (/Users/sam/baml/engine/baml-cli)
│   ├── reqwest v0.11.27 (*)
│   └── tokio-rustls v0.24.1
│       ├── hyper-rustls v0.24.2 (*)
│       └── reqwest v0.11.27 (*)
├── rustls-webpki v0.101.7
│   └── rustls v0.21.12 (*)
└── sct v0.7.1
    └── rustls v0.21.12 (*)

Took a solid hour+ of detective work to understand all the error messages we were getting and to track down the root cause correctly, so I wanted to flag this for your attention. It's clear that you've put a lot of work into making maturin cross-compilation Just Work out of the box, and this appears to stick a very frustrating wrench in that seamless experience.

[samagra14]

Any solution for this ?

[sxlijin]

We target 2_24 for our arm64-linux builds now (link).

My reasoning was that arm64-linux is, all things considered, a pretty new platform to build for: it only really started becoming a thing when the major cloud vendors started pushing it, as a cheaper and more power-efficient compute platform, in the late 2010s. glibc 2.24 was announced in 2016, so I'm pretty comfortable using that as our lower backwards compatibility bound for arm64-linux.

[flexatone]

I had an auto-generated ci.yml from maturin v1.5.0
https://github.com/fetter-io/fetter-py/actions/runs/11577938386/workflow

After trying some fresh builds this week I got the same ring errors:
https://github.com/fetter-io/fetter-py/actions/runs/11564744378/job/32191083539

I was able to get this to proceed by removing aarch64 from my Linux matrix, but I assume that is not the ideal solution.

What is the proper solution: not to use manylinux: auto?

[kylebarron]

For me this seems to work by specifying manylinux: "2_28" for the aarch64 build. kylebarron/arro3#277

[sxlijin]

Using manylinux: 2_24 for aarch64 will be most similar to manylinux: auto if you have ring in your dependencies.

manylinux: 2_28 will also work, but isn't as backwards-compatible.

The deeper explanation: the version specifier fed to manylinux is the PyPI image spec, which for newer versions is just the glibc version it uses. 2_24 is the oldest that works with ring, so if you're building a library for 3rd party users, you want 2_24. (IIRC there's also some aws linux distros that won't work with 2_28, but don't quote me on that.)

[kylebarron]

Thanks, it looks like it does compile with 2_24, just not with 2_17.