Bug: https://bugs.openjdk.java.net/browse/JDK-8001912 Bug: https://bugs.openjdk.java.net/browse/JDK-8001913
To build on Windows, we need a redistribution copy of the Visual Studio runtime library msvcr100.dll. There is unfortunately no well-defined place to find this. Our current code searches for this slowly and inefficiently, and does not look in all reasonable places. Also, it does not check if the found DLL matches the architecture of the target cpu we're building for.
These issues were discussed in two bugs, but it turned out that they needed to be solved both at a single time, since we need to check the architecture at each potential DLL we find, instead of once at the end. (Otherwise we can't continue looking for a better match.) This is similar to how we locate Visual Studio or the Boot JDK.
I moved the msvcr setup logic to a new function, TOOLCHAIN_SETUP_MSVCR_DLL. WebRev does not display this gracefully, unfortunately.
When testing with --with-msvcr-dll, it turned out that we do not handle relative paths like ./myspeciallibs/msvcr100.dll correctly. This fix also addresses this, by adding -a (rewrite as absolute path) to all cygpath -u calls.
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8001912-improve-msvcr100-dll-detection/webrev.01
/Magnus
