bzip2-rs

bzip2-rs copied to clipboard

Using up-to-date master of bzip2-rs with i686 MSVC nightly Rust. When bzip2-rs directory is in C:\Users\Александр\:

Александр@VAIO-FZ13 MINGW64 ~/bzip2-rs (master)
$ pwd
/c/Users/Александр/bzip2-rs

Александр@VAIO-FZ13 MINGW64 ~/bzip2-rs (master)
$ rustc -vV
rustc 1.5.0-nightly (168a23ebe 2015-10-01)
binary: rustc
commit-hash: 168a23ebe1729386138fa71643382fdd64fac205
commit-date: 2015-10-01
host: i686-pc-windows-msvc
release: 1.5.0-nightly

Александр@VAIO-FZ13 MINGW64 ~/bzip2-rs (master)
$ cargo build
   Compiling winapi v0.2.4
   Compiling libc v0.1.10
   Compiling winapi-build v0.1.1
   Compiling advapi32-sys v0.1.2
   Compiling gcc v0.3.17
   Compiling bzip2-sys v0.1.3 (file:///C:/Users/%D0%90%D0%BB%D0%B5%D0%BA%D1%81%D0%B0%D0%BD%D0%B4%D1%80/bzip2-rs)

build script output was not valid utf-8

When I place bzip2-rs in C:\, the build works.

This is quite odd... The bug is probably with gcc-rs of some form rather than this crate itself, but regardless it shouldn't be happening! I haven't been able to reproduce locally yet, unfortunately, however. Do you know of a way I could do so?

Did I understand you right, you tried non-latin characters in path and it didn't reproduce? Anyway, this is not that critical, because I know a workaround and have already applied it. The most unpleasant thing is that I don't have an idea how to debug this sort of bugs. AFAIK cargo runs the executable compiled from build.rs with tons of environment variables, and I have to know them all to catch it.

Hm yeah I'm not 100% sure if I did the right thing or not, but I ctrl-c + ctrl-v'd the directory name from above (Александр) into a terminal and then ran cargo build inside of that with a checkout of this repo.

Perhaps you could provide a program which when run exhibits this behavior? (e.g. programatically creates a directory with an offending character)

Seems you're doing right things. I tried the following: I patched gcc-rs so it dumps everything from the build script into a file and reproduced the bug. Here is the result: https://www.dropbox.com/s/9y6rmt7mqj1sbtk/build.txt?dl=1

Hm it looks like that file is valid UTF-8, so it may not be precisely what Cargo is choking on. Is there a script that I could run to reproduce this?

I'm working on it and I'll provide it as soon as it's ready and reproducing consistently.