Warn users that the default manylinux of `auto` may cause build failures
Opened this issue · 6 comments
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.
Any solution for this ?
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.
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?
For me this seems to work by specifying manylinux: "2_28" for the aarch64 build. kylebarron/arro3#277
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.)
Thanks, it looks like it does compile with 2_24, just not with 2_17.