Repository navigation
Tracking issue for musl host toolchain #59302
Description
TODO:
- Installable host toolchain (Musl host toolchain #58575)
- Rustup support (Add x86_64-unknown-linux-musl build rustup#1882)
- Tests passing as the host ( Make tests compatible with musl host #60474)
- Transition musl targets to dynamically link libc by default
- MCP approving this: Update the existing musl targets to be dynamically linked. compiler-team#422
- static-pie support static-pie for musl target (remove crt1.o) #53968 (done in Enabling static-pie for musl #70740)
- Update to musl 1.2 x86_64-unknown-linux-musl: backport musl bug fixes or use new
1.2version? #91178
For people looking how to use as it dynamic target:
RUSTFLAGS="-C target-feature=-crt-static" cargo buildReacted by Wesley Moore, Alessandro Tagliapietra, Andrey T, kpcyrd, Nui Narongwet, Caio Raposo, Chris Jones, Squirrel, Artur Sinila, Ed Morley and 10 more
Reacted by eaglgenes101, Sander Maijers, Baojun Wang, Fletcher Nichol, J0WI, Omer Katz, Masahiro Saito, Jason Williams, Alessandro Tagliapietra, kpcyrd and 4 more
Reacted by Garrett Squire, Oisín, Omer Katz, Masahiro Saito, Jason Williams, Alessandro Tagliapietra, kpcyrd, Maria Dubyaga and Hans Ott
Reacted by Jason Williams and kpcyrd
Activity
wangbj commentedon Mar 20, 2019
It seems
x86_64-unknown-linux-musltarget doesn't honor--enable-default-pie, a different behavior compare tox86_64-unknown-linux-gnu. Is this a known issue?mati865 commentedon Mar 20, 2019
@wangbj I don't think Rust supports
--enable-default-piefor any target. Could you provide more details?wangbj commentedon Mar 20, 2019
hmm, the problem seems caused by
musl-gccwrapper instead ofrustc:details: https://gist.github.com/wangbj/ead5fa8c96418de7c9050bc354fbf353
--enable-default-pieis a gcc configure flag. sorry for the noise. (shortened the text to a gist).Cogitri commentedon May 3, 2019
FWIW, Void has been hacking around this for some time: https://github.com/void-linux/void-packages/blob/742a7d53eb0b373bf8dad3b51db3380c5cdf8dc1/srcpkgs/rust/patches/musl-dont-use-crt-static.patch and https://github.com/void-linux/void-packages/blob/742a7d53eb0b373bf8dad3b51db3380c5cdf8dc1/srcpkgs/rust/patches/link-musl-dynamically.patch
I'm currently working on this for Alpine too (BTW, maybe I can ping you on the PR for this @mati865 so you can take a look at it?).
mati865 commentedon May 5, 2019
I knew about Alpine and Void. IMO Alpine approach is better because
<arch>-unknown-linux-muslremain static by default (it behaves like upstream) and new target<arch>-alpine-linux-musllinks dynamically by default.I had looked at that PR and
libcchanges will be incompatible with upstream rust behaviour. Official Rust packages when statically linking to musl create executables that all fully static (run basically everywhere), that patch will create static executables that depend on musl runtime (use have to install musl to be able to run them).Cogitri commentedon May 5, 2019
Yup, but at least on Void we've come to terms that the Rust in the repos is only really meant for packages in the repos, while users interested in rust development should use upstream Rust via rustip.
smaeul commentedon May 5, 2019
That doesn't make sense. Static executables by definition don't depend on having musl installed. Are you referring to rust-lang/libc#1327? That change would require having a musl-targeting toolchain installed for rustc to link (static) musl-targeting binaries. But any static binaries compiled by rustc would still be totally independent and require no musl installation.
mati865 commentedon May 5, 2019
@smaeul I'm referring to https://github.com/alpinelinux/aports/blob/21c1983ce828ead1afc9e80aa77ede330c662182/community/rust/link-musl-dynamically.patch
smaeul commentedon May 5, 2019
@mati865 Okay, so that patch is misnamed. It doesn't have anything to do with static versus dynamic linking. It makes the same change as rust-lang/libc#1327 -- using the C toolchain's copy of
libc.ainstead of bundling it insideliblibc.rlib. And my comment above applies to it as well.Alpine also ships custom targets that use the C toolchain's
crt*.oinstead ofrustcshipping a second copy. Since on Alpine targetsrustc's copy ofcrt*.oare not used, this patch stopsrustcfrom making the copy. (This change is unrelated to theliblibcchange.)mati865 commentedon May 6, 2019
Thanks for the explanation.
thedrow commentedon Jun 17, 2019
#53968 also seems to be related but it's not included in the OP's checklist.
Am I correct?
mati865 commentedon Jun 17, 2019
Updated
thedrow commentedon Jun 27, 2019
#61328 also seems important.
15 remaining items
🐛 fix: add env vars to docker cargo build because of problem in rust …
yshui commentedon Sep 25, 2024
is it possible to have dylib/cdylib with
+crt-static?bjorn3 commentedon Sep 26, 2024
Musl doesn't support that as the dynamic linker is part of libc and it doesn't support multiple copies of libc in a single process like on basically every Unix. The only mainstream system where that is possible is Windows as there the dynamic linker is part of the kernel and libc is not the system abi and multiple libc copies can co-exist in a single process.
yshui commentedon Sep 27, 2024
i believe it would be possible to create "statically linked" shared library. i.e. all libc symbols are resolved at link time and the shared library is completely self-contained that it neither exposes nor references any libc symbols. we would also need the equivalent of
-fno-semantic-interpositionetc., and other things i might have missed, but i think it is doable at least in theory.it might cause some confusion since two symbols ostensibly have the same name can actually be completely unrelated to each other, (which, btw, already happens in rust today if my project happens to use different versions of the same crate), but the shared library should otherwise work.
bjorn3 commentedon Sep 27, 2024
There are various pieces of global state in libc as well as some process state like the tls register for which each libc instance assumes exclusive access.
yshui commentedon Sep 27, 2024
Ah right, yeah I forgot about that. That definitely makes this unsupportable from Rust's perspective. There goes my dreams :'(
OTOH it's probably not that bad? I'd imagine process state and tls register setup generally happen before
mainand probably isn't going to be touched again when a shared library is loaded. I can probably still make it work as a hack.bjorn3 commentedon Sep 28, 2024
TLS registering also happens on every dlopen and pthread_create, so don't use either from within your statically linked dylib. And you better make sure that the host program uses musl as libc as errno is stored at a fixed offset from the TLS register, which other libc's may use for other purposes.
Add musl support with -crt-static flag
Cicd fixes (#8)
Add cargo config for musl cdylib support
WhyNotHugo commentedon Apr 18, 2026
Would a patch implementing the suggestion above be acceptable?
I believe this yields a sane/expected behaviour when compiling x86_64-unknown-linux-musl on x86_64-unknown-linux-musl distributions, but also won't break the workflow of users who cross-compile without a musl sysroot.
Fix cdylib build failure on musl targets
try fix alpine.Containerfile
build OCI images