-
Notifications
You must be signed in to change notification settings - Fork 303
Create Updating-musl-1.2.5.md #1641
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
base: master
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would it be worth to talk about dynamic linking? i.e. to say that this doesn't affect people who link dynamically. But does it also increase the minimum musl version we support dynamic linking to? That's a tougher question. IDK whether we have to answer it, but if we know the answer, we should maybe write it down here.
The maintainers of musl themselves think that dynamic linking is an important way to use their libc, and it should be used for the musl based distros.
|
||
target | notes | ||
-------|------- | ||
`aarch64-unknown-linux-musl` | ARM64 Linux with musl 1.2.3 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is it intended to put the old musl versions here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It was but I can change it or omit the version entirely.
|
||
For the Rust ecosystem, the primary motivation for this update is to receive major improvements to musl's DNS resolver which shipped in 1.2.4 and received bug fixes in 1.2.5. When using `musl` targets for static linking, this should make portable linux binaries that do networking more reliable, particularly in the face of large DNS records and recursive nameservers. | ||
|
||
However, 1.2.4 also comes with a breaking change: [the removal of several legacy compatibility symbols that the Rust libc crate was using](https://github.com/rust-lang/libc/issues/2934). A fix for this [was shipped in libc 0.2.146 in June 2023 (2 years ago)](https://github.com/rust-lang/libc/pull/2935), and we have been waiting for newer versions of the libc crate to propagate throughout the ecosystem before shipping the musl update. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It might be worth to quote an example error one might encounter, as the error message is not 100% obvious (it's a linker error). You can look around the crater run's logs to extract it.
I think clarifying dynamical linking would be extremely valuable. My interest here is as someone who ships Python packages with Rust code that needs to adhere to the ABI for musl package (https://peps.python.org/pep-0656/). Host tools requiring a newer musl is fine, but crates compiled for these targets requiring a newer musl would have unclear impacts. |
Hm. Notably, stdlib maintainers will need to know if we can use APIs that were only exposed by musl 1.2.4 and musl 1.2.5 for these targets, so we have a similar question as @alex. |
Tentative blogpost for:
*-linux-musl
targets to musl 1.2.5 compiler-team#887Info about when this will release is of course placeholder, and I'm happy to update the wording or add whatever details are desires.
Rendered