RFR(S): 8022177: Windows/MSYS builds broken

Erik Joelsson erik.joelsson at oracle.com
Wed Aug 6 09:36:25 UTC 2014

I gave msys another shot and managed to get it running on my laptop, 
even with mintty so it's not driving me nuts trying to interact with it. 
With your patch I managed to get through configure. When building, it 
seems make just stops after a bit in langtools however, hogging one full 
cpu core, at least at default concurrency setting (which is 4 on my 
machine). Running with JOBS=1 seems to work better.

Are you having the same problems, only being able to build without 


On 2014-08-06 11:01, Erik Joelsson wrote:
> Hello Volker,
> The changes seem reasonable to me, consider them reviewed. I can make 
> the push if you like.
> On msys, I would really like to be able to test this myself, but I 
> find it hard to get a proper environment setup. Can you point me to a 
> good guide on what I need to do?
> /Erik
> On 2014-08-05 20:26, Volker Simonis wrote:
>> Hi,
>> could somebody please review these straightforward changes which fix
>> the MinGW7MSYS build on Windows:
>> http://cr.openjdk.java.net/~simonis/webrevs/8022177/
>> https://bugs.openjdk.java.net/browse/JDK-8022177
>> The details of the change can be found below and in the webrev. I
>> think I need a sponsor for this change because it requires the
>> re-generation of generated-configure files (closed and open).
>> I also want to mention that we at SAP are using the MinGW/MSYS build
>> on Windows since more than a year for all our Java builds (from 4 to
>> 8) on Windows and we're highly committed in keeping this build
>> environment alive.
>> Independently from this change I also have a general question related
>> to the MSYS build:
>> During an MSYS build the Windows command shell is usually called like 
>> this:
>> `cmd //c echo $unix_path`
>> As far as I understand, the double slash is needed to prevent MSYS
>> from rewriting '/c' to 'c:/' when calling a non-MSYS executable. But
>> sometimes (notably in BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS in
>> basic_windows.m4) we call the Windows command shell without a quoted
>> forward slash like this:
>> new_path=`cmd /c "for %A in (\"$input_path\") do @echo %~sA"
>> and I don't understand why this works.
>> To complicate things, the MSYS environment contains its own 'cmd'
>> shell script in '/usr/bin/cmd' which only redirects to the
>> corresponding Windows command shell like so:
>> #!/bin/sh
>> "$COMSPEC" "$@"
>> Unfortunately I didn't succeed in unifying all the calls to 'cmd' to a
>> single pattern (i.e. either `cmd //c ...`, or `/usr/bin/cmd /c ...`)
>> which would be desirable, because depending on the actual PATH
>> settings, `cmd` may either call "/usr/bin/cmd" or
>> "C:\Windows\System32\cmd.exe".
>> Can anybody shed some light on this topic (i.e. which "cmd" we want to
>> call and why we have to quote "/c" differently)?
>> Thank you and best regards,
>> Volker
>> 1. common/autoconf/basics.m4
>> - Check for bsdcpio if cpio is not found. Also make the check for cpio
>> optional, as suggested in the bug report.
>> - Only do the BASIC_CHECK_SRC_PERMS check on Cygwin as it only seems
>> to be relavant there and because the stat utility isn't availabel in
>> MSYS anyway.
>> 2. common/autoconf/basics_windows.m4
>> - Same story like on Cygwin: '.bat' and '.cmd' files are not always
>> considered executable in MSYS causing which to not find them.
>> 3. common/autoconf/flags.m4
>> - Use "-WX" option syntax for cl options (instead of "/WX") to prevent
>> option rewriting by MSYS.
>> 4. toolchain_windows.m4
>> - Account for the fact that the MSYS file utility reports different
>> file types for Windows DLLs than its Cygwin counterpart.

More information about the build-dev mailing list