Skip to content
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

Publishing musl aarch64 build products #9875

Open
whitequark opened this issue Dec 19, 2024 · 6 comments · May be fixed by #9885
Open

Publishing musl aarch64 build products #9875

whitequark opened this issue Dec 19, 2024 · 6 comments · May be fixed by #9885

Comments

@whitequark
Copy link
Contributor

Feature

I would like wasmtime releases to be built for musllinux on aarch64 platform.

Benefit

Improved portability of wasmtime-py when installed from PyPI (bytecodealliance/wasmtime-py#263).

Implementation

As far as I know this target should build fine, so only CI scripts need to be updated.

@alexcrichton
Copy link
Member

I think it's definitely fine to add this, but it will require someone to figure out how to write a build container for it. For x64 I was able to be "just dangerous enough" to cobble something together, but I've never personally successfully cross-compiled from an x64 system to aarch64-musl. Something like cross may work though perhaps? (we notably want dynamically linked artifacts which is distinct from the default I believe for the Rust target)

@whitequark
Copy link
Contributor Author

Ah, that is a little cursed. I'm supposed to be on vacation right now so I think I'll avoid doing a CI modification this complex 🙈

alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Dec 20, 2024
This commit refactors the way release builds are done in CI in terms of
configuration and then additionally adds aarch64-musl release artifacts
as requested in bytecodealliance#9875. The refactoring here is done to reduce the number
of locations to understand release builds. Notably the
`binary-compatible-builds` action was removed in favor of direct
environment configuration in conjunction with docker images used to
build. The `aarch64-musl` build itself happens in a container provided
by the `cross` project to ensure that the right toolchain is configured.

Closes bytecodealliance#9875
alexcrichton added a commit to alexcrichton/wasmtime that referenced this issue Dec 20, 2024
This commit refactors the way release builds are done in CI in terms of
configuration and then additionally adds aarch64-musl release artifacts
as requested in bytecodealliance#9875. The refactoring here is done to reduce the number
of locations to understand release builds. Notably the
`binary-compatible-builds` action was removed in favor of direct
environment configuration in conjunction with docker images used to
build. The `aarch64-musl` build itself happens in a container provided
by the `cross` project to ensure that the right toolchain is configured.

Closes bytecodealliance#9875

prtest:full
@alexcrichton alexcrichton linked a pull request Dec 20, 2024 that will close this issue
@alexcrichton
Copy link
Member

Looks like cross does support aarch64 musl, so I'm attempting to integrate using that image in #9885.

Would you happen to have an aarch64-musl system you can test on? I don't have one myself outside of possibly setting up QEMU.

@whitequark
Copy link
Contributor Author

Would you happen to have an aarch64-musl system you can test on?

I do!

I don't have one myself outside of possibly setting up QEMU.

Do you have an Android phone? If you set up Termux, it will give you such a system (unless it's really ancient). You get a normal musllinux system.

@bjorn3
Copy link
Contributor

bjorn3 commented Dec 20, 2024

Doesn't Termux use Bionic like the rest of Android?

@whitequark
Copy link
Contributor Author

whitequark commented Dec 20, 2024

Doesn't Termux use Bionic like the rest of Android?

It does. Turns out I completely misunderstood how it works! But fortunately it also has proot which still lets you do whichever distro (and libc) you like on native aarch64.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants