[rust] Consider dynamically linkage to system libs.

[Berrysoft]

Description

Rust choose to statically link to libgcc_eh and libpthread when no -C prefer-dynamic is specified:
https://github.com/rust-lang/rust/blob/1ddd4e6d7ed446934abd428a08e18535faef5e03/compiler/rustc_target/src/spec/windows_gnu_base.rs#L50-L58

It is because that some software end users may not have msys2 or other MinGW64 runtimes installed, and it may be complicated for developers to bundle the MinGW64 runtime. However, when we are using msys2 for building and distribution, we may strongly assume that the users have msys2 installed, otherwise they couldn't use pacman. If the developer would like to distribute without MinGW64 runtime, he/she should use -C target-feature=+crt-static.

Pros

Smaller binary size: We could simply link with the installed MinGW64 runtime, and it will help reduce some of the binary size. The distributed binary will also benifit from newer MinGW64 runtime without recompiling.

No sidebacks when using crt-static: MinGW64 doesn't statically link to msvcrt due to license restrictions. Therefore the modification here won't make difference when using crt-static. It should perform as usual, and simply bundle the MinGW64 runtime.

Future exception safety: Rust doesn't guarantee cross-language exception safety. However, it is in design. Then it needs the rust binary to dynamically link to the MinGW64 runtime.

Behavior consistence: Most other targets only link to the unwind runtime statically when feature crt-static is on.

Cons

Different from upstream: The behavior should be properly documented, as it is different from the upstream one.

MISC breaking: Some crates may assume the offical behavior, although I haven't found one.

Other notes

Not only the windows_gnu_base.rs should be modified, library/unwind/src/lib.rs should also be modified to properly deal with crt-static feature. Also, it should be investigated that where to link libpthread statically.

[lazka]

No clue.

@mati865 any thoughts on this?

[Berrysoft]

Seems that the same person maintaining the windows-gnu target of rust?:)

Some talking: rust-lang/rust#90020

[lazka]

ok, thanks for the reference

[mati865]

Seems that the same person maintaining the windows-gnu target of rust?:)

Not maintaining, only a contributor.

@mati865 any thoughts on this?

The same as in mentioned thread, if upstream goes for it then should definitely follow.

On the other hand this change might be beneficial to MSYS2 packages depending on Rust since they will become a little smaller (~100KiB) but no longer portable by the default. I think most of Rust users would rather use toolchain from Rustup rather than MSYS2 (it's typical way of using it even on Linux) so it might be acceptable to diverge from Rust here.