alexcrichton opened PR #8668 from alexcrichton:musl-binaries
to bytecodealliance:main
:
This was requested in bytecodealliance/wasmtime-py#237 and shouldn't cost us too much in terms of CI resources and maintenance overhead.
<!--
Please make sure you include the following information:
If this work has been discussed elsewhere, please include a link to that
conversation. If it was discussed in an issue, just mention "issue #...".Explain why this change is needed. If the details are in an issue already,
this can be brief.Our development process is documented in the Wasmtime book:
https://docs.wasmtime.dev/contributing-development-process.htmlPlease ensure all communication follows the code of conduct:
https://github.com/bytecodealliance/wasmtime/blob/main/CODE_OF_CONDUCT.md
-->
alexcrichton requested elliottt for a review on PR #8668.
alexcrichton requested wasmtime-core-reviewers for a review on PR #8668.
alexcrichton requested wasmtime-default-reviewers for a review on PR #8668.
elliottt submitted PR review.
alexcrichton updated PR #8668.
alexcrichton has enabled auto merge for PR #8668.
whitequark commented on PR #8668:
Thanks again =^__^=
This will improve the compatibility story for YoWASP and the Glasgow Interface Explorer to even more Linux distributions.
alexcrichton merged PR #8668.
aambrose-sonatus commented on PR #8668:
Hi @alexcrichton, I'm curious about a couple things here regarding musl support:
- What is the wasmtime dependency on libgcc? Is this something core, or just how the toolchain is structured right now?
- What is the limitation that is preventing wasmtime from being fully static with musl libraries? Is it the above libgcc dep?
Thank you
For usage in C we compile a wasmtime.so. Producing a dynamic library is incompatible with statically linking libc. The musl based binaries also seem to be meant for usage on musl based distros where statically linking libc only has disadvantages. (bigger binaries, not getting security updates to libc)
bjorn3 edited a comment on PR #8668:
For usage in C we compile a wasmtime.so dynamic library. Producing a dynamic library is incompatible with statically linking libc. The musl based binaries also seem to be meant for usage on musl based distros where statically linking libc only has disadvantages. (bigger binaries, not getting security updates to libc)
aambrose-sonatus commented on PR #8668:
Is there anything that precludes compiling the static library version of the embedding (IE
libwasmtime.a
) as fully static? Perhaps not as an official release artifact, but e.g. when compiling from source oneself or when using wasmtime as a crate dependency for some other binary?
If you compile it yourself, I don't see why it shouldn't work.
alexcrichton commented on PR #8668:
I think that the
libwasmtime.a
artifact for x86_64-musl should be usable to build a static binary, but I haven't tested that myself. Otherwise though our distribution doesn't have any static binaries for Linux mostly just because no one's asked for it and it's otherwise easier to keep everything built similarly (and all other platforms use dynamic linking)@bjorn3 is right though in that when building yourself you should have any option you need available to you for target/static linking/etc.
aambrose-sonatus commented on PR #8668:
Yeah it seemed to be working on my end; I used zig as the C toolchain so I get full static outputs by default. My questions were more regarding the statement
they are not suitable for "run on any linux distribution" style use cases
and whether this applied to all source builds, or only the publicly released artifacts. It sounds like it's the latter.Thank you both!
Last updated: Nov 22 2024 at 16:03 UTC