New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Build linux libextism on manylinux/musllinux containers #591
Comments
Ooh, yes – we already have to do this for the Python |
(Notably, we have to be on manylinux |
That would be nice if the Python build could share the regular native build. Maybe just the aarch64 builds need to be on |
It just clicked for me that this would help with extism/ruby-sdk#6 as well – we could probably bundle all of the manylinux builds with the ruby gem to create that fat gem release. |
I just peeked at the the
So we may just need to rejigger the release.yml to remove our direct cargo build, unpack the wheels, and add those Footnotes
|
Unpacking the wheels could work. Something I haven't considered yet is how to handle the static builds. I see three possible ways forward with wheel unpacking:
I'd lean to |
Hm, so in option B, would we have two releases per tag? (Like, Re option A, are you thinking that the number of artifacts attached to the release might be chaotic, or that the workflow file might become overcomplicated? I tend to lean towards keeping all release artifacts unified under the tag that produced them, to match user expectations on where to find things (& because github requires that tags and releases are 1:1), but I can definitely see where the number of artifacts attached to the release is becoming unwieldy. (Maybe we could solve this through some explanatory text in the release notes, readme, and/or website?) |
Yes, exactly. The number of assets in a release would increase as many targets would also have a manylinux version.
In
I definitely want to keep all releases artifacts under the same tag. The artifacts attached to the release ballooning is my main concern with Instead of taking the shared object from the wheel, is it viable to build the wheels from prebuilt shared objects? If we could do the normal |
We can ensure our libraries are compatible with a broader set of linux systems by linking against old libcs/compiler libs. The manylinux/musllinux containers may be used to do so.
It looks like only a few lines may need to change:
https://kobzol.github.io/rust/ci/2021/05/07/building-rust-binaries-in-ci-that-work-with-older-glibc.html
I was thinking following Rust's compatibility https://doc.rust-lang.org/nightly/rustc/platform-support.html https://blog.rust-lang.org/2023/05/09/Updating-musl-targets.html
to use the
manylinux2014
/manylinux_2_17
andmusllinux_1_2
containers.manylinux2014
is an alias formanylinux_2_17
.Related reading on manylinux/musllinux:
https://peps.python.org/pep-0513/
https://peps.python.org/pep-0600/
https://peps.python.org/pep-0656/
The text was updated successfully, but these errors were encountered: