Nightly `-pc-windows-gnu` missing DLL crash

[retep998]

First found on appveyor:
https://ci.appveyor.com/project/retep998/winapi-rs/build/1.0.724/job/qiwg0jsw19fyb0b4
It appears that the libstdc++-6.dll which rustc_llvm-fd663c41.dll depends on has picked up a dependency on libwinpthread-1.dll.
Issue does not affect -msvc targets.
Last known good version was rustc 1.8.0-nightly (c894ff6b1 2016-02-20).
First version where issue was observed rustc 1.8.0-nightly (c92e910c1 2016-02-21).
Offending diff range is c894ff6...c92e910

cc @alexcrichton @vadimcn

[retep998]

Welp, it's just a missing DLL.

I'm also tempted to blame rust-lang-deprecated/rust-buildbot@8faa011

[retep998]

It is specifically libstdc++-6.dll which is to blame.

[vadimcn]

Did the mingw toolchain get changed from "win32" to "pthreads" flavor?

[alexcrichton]

Yes it looks like the wrong libstdc++-6.dll is getting slurped up by make-win-dist.py. On the bots there are two copies installed:

c:\mingw-w64\i686-4.9.1-win32-dwarf-rt_v3-rev1\mingw32\bin\libstdc++-6.dll
c:\msys64\mingw32\bin\libstdc++-6.dll

The former is the one we want to ship, where the latter is what we're accidentally shipping (verified by just checking the md5sum of what's on the bots and what's installed locally). I don't understand why we're slurping up this copy, however. When the dist step is run, the PATH on the bots looks like:

  PATH=c:\mingw-w64\i686-4.9.1-win32-dwarf-rt_v3-rev1\mingw32\bin;c:\msys64\mingw32\bin;c:\msys64\usr\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;C:\msys64\usr\bin;c:\python27;c:\python27\scripts;c:\program files (x86)\inno setup 5;c:\program files (x86)\CMake\bin;C:\Program Files (x86)\Windows Kits\8.1\Windows Performance Toolkit\;C:\Program Files\Microsoft SQL Server\110\Tools\Binn\;C:\Program Files (x86)\Microsoft SDKs\TypeScript\1.0\

When we try to find the libstdc++-6.dll file we look it up in bin_path which should just be a copy of PATH.

@vadimcn do you have any ideas for what might be going on here? I recently changed buildbot to move the c:\msys64\mingw32\bin\ path farther forward in PATH. That was done to ensure that rustbuild could use a non-broken python (the one in c:\msys64\usr\bin), but the gcc path is still up front, so I have no idea why it's picking up the wrong one.

Do you know if this normpath call somehow doesn't like non-msys-rooted paths or something like that?

[alexcrichton]

Whelp, yet another reason to burn mingw with fire:

$ PATH=a /mingw32/bin/python -c 'import os; print os.environ["PATH"]'
C:\msys64\mingw32\bin;a

Looks like mingw is doing us a favor and prepending to path for us! The other python installed on the system is:

$ PATH=a /c/Python27/python -c 'import os; print os.environ["PATH"]'
a

Which must also explain why we didn't run into this before. Good lord the pain with mingw never ends...

[alexcrichton]

Should be fixed by rust-lang-deprecated/rust-buildbot@77185c8