-
Notifications
You must be signed in to change notification settings - Fork 12.7k
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
Tracking issue for musl host toolchain #59302
Comments
It seems |
@wangbj I don't think Rust supports |
hmm, the problem seems caused by details: https://gist.github.com/wangbj/ead5fa8c96418de7c9050bc354fbf353
|
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?). |
I knew about Alpine and Void. IMO Alpine approach is better because I had looked at that PR and |
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. |
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 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 Alpine also ships custom targets that use the C toolchain's |
Thanks for the explanation. |
#53968 also seems to be related but it's not included in the OP's checklist. |
Updated |
#61328 also seems important. |
I don't see how #61328 relates to this, there is no issue when using |
In rust-lang/libc#1327, a How do other run-times deal with this ? Is it possible to statically link glibc and others into Rust binaries ? Maybe we need a |
AFAIK musl is the only target which you can link statically and dynamically at same time. Duplicating target_env is easy but for me it sounds like a bad workaround because user would have to install 2 toolchains that have exactly the same libs and the only difference comes to Ideally they should use single shared sysroot because all that is required can be handled at runtime. |
The two relevant target attributes are For glibc (and all other non-musl unix-like platforms), For MSVC, musl is in the unique situation of
I had a patch (#55566) that "fixed" this by changing the semantics of
We already have that: The problem in rust-lang/libc#1327 is that we try to support cross-compilation to musl without having the proper sysroot installed. The whole |
Fwiw Alpine Linux ships a similar patch (although we don't use crt-static for pur distro packages). Good to know what's the status on that, thanks.
Void Linux and Alpine Linux carry a similiar patch: https://github.com/alpinelinux/aports/blob/master/community/rust/link-musl-dynamically.patch |
Many production users rely on this feature, so we are kind of constrained on not breaking this. If the only way to achieve that is have a second set of targets, then that's the way it is. |
What about shipping |
I think I would prefer something that also works great for distro packages. While they could tune things when packaging, a distro that uses musl as its stdlib, will have users that might install rust via rustup, and they will want their "default" rust target to dynamically link the system musl, instead of doing something else, right? |
Another problem I noticed trying to compile/run the rust compiler on a musl host like Alpine Linux is that using the jemallocator for the compiler itself does not seem to work. Given that rust is known to run slower with musl's default allocator than with jemalloc, I tried enabling |
FWIW Rust recently got a new allocator with musl 1.2 (mallocng), so it might be worth to benchmark that again :) |
I don't know much about jemalloc, I was just playing around to see if it improved stuff and had to realize that the compiler didn't seem to use it. So I don't know if the performance issues I'm seeing are caused by the allocator, but other rust projects like ripgrep have seen the allocator change to cause performance regressions on musl targets (and that one is also not patched on alpine). Unfortunately, |
Opened a new issue against the musl version used in building #91178 |
is it possible to have dylib/cdylib with |
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. |
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 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. |
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. |
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 |
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. |
TODO:
1.2
version? #91178For people looking how to use as it dynamic target:
RUSTFLAGS="-C target-feature=-crt-static" cargo build
The text was updated successfully, but these errors were encountered: