-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Can't statically link MSVC runtime #290
Comments
Interesting! Linking to msvcrt historically has no real reason for existing beyond "it was the first thing that worked", but I agree that statically linking all of these dependencies is much more "rustic" than not. I fear, though, that this may require changes beyond just this library. I would guess that a change here is enough for "pure Rust" code, but C code I think has to be compiled differently to account for linking to the CRT differently (e.g. the gcc crate would need to update). Do you know if there's a compatibility story we could have there? It may also be worth just giving this a spin by building Rust and seeing what happens when you try to run the test suite. |
Since |
In order for the environment variable option to work though, |
I wouldn't be opposed to making statically linking msvcrt the default. But if we wanted to make it configurable, I wonder if #[link(alias)] RFC would help here? Granted, it was not intended for replacing lib names in already compiled crates, but hey...
Well, as we know, MSVC linker will patch over these differences most of the time (except for data exports, but I don't think msvcrt has any of those). I guess we'll need to do some crater runs to know for sure. |
@vadimcn While in many cases the linker can resolve those differences, the object files will still have that version of the CRT specified as a default object to link in, leading to situations where both the static and dynamic CRT are being passed to the linker which is bad. We'd have to specify
We'd also need crater to actually support Windows first. |
For now I'd be fine with just developing a transition story from dynamically linked to a statically linked CRT. I suspect that the practical impact of switching would be next-to-none as it'd be pretty rare to require dynamic linkage, right? Along those lines I'd want to leave open some vector to request dynamic linkage, but we perhaps don't have to do it just yet. If we can selectively tell link.exe to ignore msvcrt.lib and libcmt.lib dependencies in object files (via those flags) then we may be able to just change it have everything work. |
Dynamic linkage is basically essential if you want to pass CRT objects between binaries. If you allocate something (memory, files, any CRT thing) in a dll/exe that links to one CRT and try to free it (or even use it, files in particular) in a different dll/exe that links to a different CRT then bad things can happen. So keeping an option to dynamically link the CRT is probably important. You don't always need it, but when you do need it you can't really go without it. I'd personally be happy with just some sort of flag or environment variable to tell rustc which CRT to link, and then it passes |
Solved by https://github.com/rust-lang/rfcs/blob/master/text/1721-crt-static.md and #446, implemented in rust-lang/rust#37545 |
Rename flags to conform to conventions. Resolves rust-lang#290.
I understand this has been fixed. Could you please let me know what flag should I use with cargo to enable static linkage (i.e. to get rid of runtime dependency to vcruntime140.dll)? |
@avkonst |
Thanks! I use |
I have found it here: https://users.rust-lang.org/t/statically-linking-to-crt-on-msvc/9755 |
They need to be structured *somehow* to be the right bit width but ideally we wouldn't have the intrinsics rely on the particulars about how they're represented.
Looks like it's hardcoded to dynamically link to the runtime. If someone points me in the right direction, I can send a PR to make a configurable, but I'm not sure where to start. I can confirm that changing it from msvcrt to libcmt makes a statically linked binary.
Here's the output of dumpbin for libcmt:
and for msvcrt:
Relevant thread: https://users.rust-lang.org/t/standalone-32bit-windows-app-using-msvc/3103
The text was updated successfully, but these errors were encountered: