I am trying to compile a library with cmake from a build.rs file. The only response I get from cargo build is build script output was not valid utf-8. I run Rust on a Windows 10, 64bit, msvc version.
I am new to Rust so hopefully there is an obvious solution that I haven't found yet. I have searched the web for some time and was only able to find a discussion where people had strange names in their path. Mine, however, should only include "normal" characters (path is C:\Users\My-Name\Documents\dev\mycrate\mycrate-sys\target\debug\build\mycrate-sys-000682e067ebf920\out).
I'd be very happy if someone could tell me how to resolve the problem.
I might have found something. I took a close look at the build directory and found that I can see everything that the build script outputs in a file called output. It seems like the cmake output is not suppressed but forwarded. There are symbols that can't be resolved, as cmake outputs explanations in my language (german).
I will see what can be done there. Right now, I am installing a different language for my windows and hopefully, cmake will follow.
Thank you for your help. You helped me look in the right place and understand the build process a bit better.
I'm glad I helped you! I think this is a bug in cargo, which should not try to convert the captured output of build tools to str, but keep OsStr. You should fill a bug about it
OsStr is not quite appropriate, as on Windows OsStr is UTF-16 but standard output is still a stream of bytes, so Cargo has a [u8] in the system code page. The quick and dirty fix would be to use String::from_utf8_lossy in custom_build.rs; I'm sure there's a way to do the ISO-8859-1 -> UTF-8 conversion correctly, but it's been too long to remember what that was.
[quote="sorear, post:9, topic:5333"]
on Windows OsStr is UTF-16
[/quote]It isn't. You can convert from str with zero cost (there is impl AsRef<OsStr> for str) on any platform.
After a reinstall of ms visual studio, this time the english version, I am now able to compile everything as expected.
So for everyone with similar problems: Don't use a localized version of msvc.
I opened a new issue for this.
The lossy conversion would work but the build process might break if there are non-utf-8 characters in lines starting with cargo:, I suppose. In the best case, the build script output is split into lines first and only those lines starting with cargo: are checked for their utf-8 correctness.