Windows linker errors in `cargo-dist` workflow: `warning LNK4098: defaultlib 'MSVCRT' conflicts with use of other libs; use /NODEFAULTLIB:library`

[CramBL]

Summary

It seems that my build is statically linking HDF5 but not MSV CRT and that causes a problem?

I get a ton of errors like this:

libhdf5_metno_sys-afead0c756f87c12.rlib(H5EAstat.obj) : error LNK2001: unresolved external symbol __imp__wassert
libhdf5_metno_sys-afead0c756f87c12.rlib(H5FAstat.obj) : error LNK2001: unresolved external symbol __imp__wassert
libhdf5_metno_sys-afead0c756f87c12.rlib(H5HFdtable.obj) : error LNK2001: unresolved external symbol __imp__wassert

I want to

Statically link HDF5 because I absolutely don't want my users to have to find the right headers and I don't want to bundle them either, I need to not deal with that headache at all.

Works with how I normally build, see this CI run:

https://github.com/luftkode/logviewer-rs/actions/runs/11369355310/job/31626596049

NOTE: No HDF headers are manually installed, it is handled by the HDF5 crates builds.rs that fetches and statically links dependencies with cmake.

But with my release (cargo-dist) workflow

... the windows build fails: https://github.com/luftkode/logviewer-rs/actions/runs/11369355557/job/31626621637

I tried

Adding this .cargo/config.toml:

[build]
rustflags = ["-Ctarget-feature=+crt-static"]

does not change anything.

[mistydemeo]

Hmm, interesting. I'll review and get back to you.

[CramBL]

I don't fully understand the issue but after reproducing it on a windows machine I ended up disabling static linking of the VS CRT.

EDIT: That did not fix the issue still... I don't know why I thought it would.

So it seems that dist is attempting to statically link the CRT even though I don't specify that?

[CramBL]

This issue could be resolved by https://github.com/axodotdev/cargo-dist/issues/1782