can't find crate for `std` on mingw-w64-32bit

[klutzy]

compile_and_link: i686-pc-mingw32/stage1/bin/rustc/i686-pc-mingw32/bin/std.dll
compile_and_link: i686-pc-mingw32/stage1/bin/rustc/i686-pc-mingw32/bin/extra.dll
C:\home\stone\rust-w32\src\libextra\lib.rs:1:0: 1:0 error: can't find crate for `std`
C:\home\stone\rust-w32\src\libextra\lib.rs:1 // Copyright 2012-2013 The Rust Project Developers. See the COPYRIGHT
                                             ^
task 'rustc' failed at 'explicit failure', C:\home\stone\rust-w32\src\libsyntax\diagnostic.rs:75
task '<main>' failed at 'explicit failure', C:\home\stone\rust-w32\src\librustc\lib.rs:397

Not sure what caused it. make clean didn't help.

[klutzy]

Found! It's mingw/libuv issue. libuv uses swprintf to listdir, but mingw-w64's swprintf is different from mingw's one.
mingw-w64 uses:

int swprintf(wchar_t *buffer, size_t count, const wchar_t *format, ...);

mingw uses:

int swprintf(wchar_t *buffer, const wchar_t *format, ...);

Yes, no count. It even differs from posix or current msvc.
It seems that mingw is following old msvc behaviour. msvc changed it from vc++2005.

[klutzy]

Quick fix (I'll make a pr for libuv soon):

- #if defined(_MSC_VER)
+ #if defined(_MSC_VER) || defined(__MINGW64_VERSION_MAJOR)
   swprintf(path2, len + 3, fmt, pathw);
 #else
   swprintf(path2, fmt, pathw);
 #endif

[klutzy]

This seems fixed in upstream.

[huonw]

cc @alexcrichton (for the libuv upgrade).

[lucab]

Closing #10246 will fix this one too, but it's currently waiting for joyent/libuv#979 to land.

[klutzy]

Oh, this goes more complicated than I expected. Upstream libuv will make rustc crash if not built carefully.

msvc and mingw-w64 provide posix-conforming swprintf as default, and provide old one if #ifdef _CRT_NON_CONFORMING_SWPRINTFS is defined. This is what libuv upstream uses.
However, mingw doesn't understand it and always provides old one.
(I'm not sure what "Newer versions" in commit message is, since mingw master still not provide new api. Maybe it is not "newer" but mingw-w64?)

This means we must define the macro on building libuv. If not, libuv crashes on uv_fs_readdir because libuv expected new api but mingw provided old api.

[klutzy]

Currently the easiest fix is to pass -D_CRT_NON_CONFORMING_SWPRINTFS flag when building uv. This forces libuv to use old api.

[klutzy]

#10321 will fix this (mingw-w64 issue).
For mingw issue, I've reported it at upstream.

[klutzy]

@alexcrichton libuv fixed it by avoiding swprintf. Upgrading libuv will fix both mingw- and mingw64-issues. (and you can also drop the CFLAGS hack).

[alexcrichton]

I have upgraded and this'll close when my uv-rewrite branch merges (hopefully soon!)