Dealing with MSVC-built DLLs is painful

[emberian]

One issue that has become incredibly painful to me in the past few days setting up a complex Rust application to ship on Windows, is that of the differing run-time DLL availability requirements at runtime between MinGW and MSVC, and how that combines at compiletime. With an MSVC-generated dynamic library, you have the dll (containing the code) and the export library (.lib) containing symbols and some junk. You are supposed to link against the .lib, and then make the .dll available at runtime in its PATH somehow. This conflicts with the Cargo and MinGW view of the world, where you can link against the .dll directly and also make it available at runtime. This conflict means that using an MSVC DLL in a Cargo project requires manually copying a lot of DLLs around to where they need to be, or forgoeing cargo run etc for a custom app setup.

Ideally, Cargo would know somehow about this split and be able to copy DLLs itself where necessary, or modify the PATH before running executables.

This is also tied in with the "How do I make a bundle that I can zip up and ship" problem.

[emberian]

(I suspect once rust-lang/rust#25350 lands this will be even more of an issue!)

[alexcrichton]

I think I'm pretty confused by this issue and I'm not quite sure what's actionable here. From what I've learned, trying to mix MSVC-generated and MinGW-generated object code works some of the time, but not most of the time, so I don't think that's going to be an intended use-case of Cargo. Otherwise it's not clear to me what Cargo needs to do here (apart from the compiler itself).

Could you elaborate a little more on what you would expect Cargo to do to make this use case easier? For example what DLLs are you copying, and why are you copying them? Why does Cargo need to know about .lib and .dll files? (e.g. the compiler definitely needs to know, but this doesn't seem like Cargo needs to)