Windows CRT linking behavior in no_std build

[CarePackage17]

Relevant users forum thread: https://users.rust-lang.org/t/linker-error-when-building-no-std-windows-dll-that-uses-libc/23976

My goal is to enable Rust to run on Windows UWP, which requires linking to a different version of the CRT. Since there's no support in the standard library yet, I tried to go the no_std route to get familiar with the linking behavior on win32 before trying to adapt to UWP. However, as was pointed out by winapis maintainer, libc doesn't link properly for no_std executables/DLLs.

Is there a reason for this behavior or is this a bug?

[alexcrichton]

I think we've just never gotten around to implementing this, would be good to fix!

[CarePackage17]

I've commented out the //#[cfg(all(target_env = "msvc", feature = "rustc-dep-of-std"))], but the compiler doesn't like cfg(target_feature = "..."). It was nice enough to point me to this issue though: rust-lang/rust#37406

I've read through it and if I understood right, cfg(target_feature = "...") is unstable and should only be used when building as part of std.

Do you have any suggestion what could be done to fix this?

[alexcrichton]

The target_feature shouldn't be necessary in theory as the build script can detect what's the best attribute to emit, but it's likely not trivial to figure out the right incantation there.

[CarePackage17]

Do you mean the top-level one or is there another build script that I'm not aware of?

A quick search turned up that the only two usages of target_feature are in src/windows/mod.rs and and src/unix/mod.rs, so it's mainly about statically linking the CRT if specified.

[alexcrichton]

Yes in that build script it should be possible to detect whether we're using a static crt or not, and then emit a cfg directive indicating which linking directive should be used.

[CarePackage17]

Is the cfg! macro the right way to handle this?

[alexcrichton]

I'd recommend testing it out locally! I suspect whatever works is good to go

[JohnTitor]

Closing in favor of #1227 (comment).