Windows MSVC release binaries require vcruntime140.dll

[shalupov]

Windows MSVC builds of coreutils depend on vcruntime140.dll at runtime because Rust defaults to dynamic CRT linking for target_env = "msvc". This means the release .exe files are not self-contained — users without the Visual C++ Redistributable installed will get a missing-DLL error.

I see this when running some Bazel targets on a clean Windows 11 ARM machine (on Parallels Desktop).
(bazel-lib downloads uutils/coreutils now at https://github.com/bazel-contrib/bazel-lib/blob/main/lib/private/coreutils_toolchain.bzl)

The fix is to link CRT statically, which is quite easy to do.
For standalone utilities there are no downsides besides several hundred KBs bigger binaries.

How to test:
run https://github.com/lucasg/Dependencies or just dumpbin on coreutils.exe binary,
see VCRUNTIME140.dll dependency

I will provide a pull request

[oech3]

Well, I was planning to replace MSVC *.exe release with individual binaries to close #10368 . So

For standalone utilities there are no downsides besides several hundred KBs bigger binaries.

is problem. Would you use MinGW binary instead? No?

[oech3]

Or bundle *.dll?

[ArchangelX360]

Why would you choose MinGw target for these binaires instead of statically link MSVC?
I'm not sure you'll end up with smaller binaires that way.

[oech3]

There are static musl binary and dynamic glibc binary for Linux and musl binary can be used for portability. You can do same things by using MinGW *.exe which is already provided.

[oech3]

Woduld you benchmark with(out) crt-static and gcc/MSVC and share the result? I have no access for Windows now.

[shalupov]

Let's get to numbers first (current master, cdb3470, Windows arm target, --release)

902,144 cat.exe
998,400 cat.exe

1,205,760 cp.exe
1,312,768 cp.exe

1,895,936 ls.exe
1,992,704 ls.exe

10,238,976 coreutils.exe
10,386,944 coreutils.exe

I think that hermeticity worth more than 100K difference even for each binary.

There are static musl binary and dynamic glibc binary for Linux and musl binary can be used for portability.

glibc is usually present on Linux system so you may say that if user uses Ubuntu, then coreutils will run.
With Windows, this is not true, MSVC runtime is not a part of base system, but usually installed with various vc redist packages. e.g., Visual Studio itself installs them.

Regardless of mingw/msvc I belive that system-like utilities should not require additional dependencies.

bundle *.dll?

you can, but also it complicates things:

1. you have 2 binaries instead of 1 (even more if you count api-*.dll)
2. when you bundle coreutils with some other software, it may conflict on exact runtime dll version

Would you use MinGW binary instead?

IMHO for coreutils it makes sense to be always free of additional dependencies to be useful in more situations.
also, it's much less surprising

[shalupov]

with https://github.com/lucasg/Dependencies, on machine with Visual Studio:

Dynamic runtime:

Static runtime:

[oech3]

Are those binaries stripped? Also interested in boot time of true.exe and perf of some heavy utils.

[ChrisDenton]

Note that there are three possible solutions here for msvc:

1. ship vcruntime140.dll with the executable(s)
2. use target-feature=+crt-static to statically link the whole C/C++ runtime
3. statically link only vcruntime140.dll and dynamically link the ucrt (see static_vcruntime or edit.exe)

The difference between 2 and 3 depends only how much the C standard library is used.

[oech3]

@ChrisDenton can we cover #7162 keeping Rust version by fully static linking?

[shalupov]

For release-small profile:

  721,408 cat.exe
  818,176 cat.exe

  913,920 cp.exe
1,020,416 cp.exe

1,458,176 ls.exe
1,554,944 ls.exe

  621,056 true.exe
  716,800 true.exe

I was not able to find meaningful difference in startup time of true.exe between static and dynamic linking. On my machine, they're all around 12-20 ms without a clear pattern.

[ChrisDenton]

@ChrisDenton can we cover #7162 keeping Rust version by fully static linking?

It should be fine for now. It may be a problem in the future once targetting Windows 7 is dropped by MSVC. But that could be a problem for dynamically linking too.

[oech3]

Let's try it