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

[Volker Simonis]

Hi Erik,

thanks for reviewing my change.

Regarding your msys problems: I've seen such reports before.
Unfortunately I don't know how they can be reliably fixed.

First of all, I use MSYS 1.0.17:

MINGW32_NT-6.1 WDFN00299915A 1.0.17(0.48/3/2) 2011-04-24 23:39 i686 Msys

There a various reports that 1.0.18 introduced a regression in "make
-j" - see for example:

http://sourceforge.net/p/mingw/bugs/1950/
http://sourceforge.net/p/mingw/mailman/mingw-users/thread/k2tm88%24f4s%241%40ger.gmane.org/#msg29807709
http://comments.gmane.org/gmane.emacs.devel/159973

So you can try to downgrade to 1.0.17 like so (taken from one of the
mail-threads above):

mingw-get install --reinstall --recursive msys-core=1.0.17-1
(must be executed on a DOS prompt, with no MSYS stuff (shells, etc)
running.)

Besides that, you can try the usual things like turning off all virus
scanners and disabling Address Space Layout Randomization (see points
5-7 in this mail:
http://mail.openjdk.java.net/pipermail/build-dev/2012-February/005594.html).
But I don't know if that will help because that all were workarounds
for Cygwin problems.

Please keep me posted if you find any new fixes/workarounds for this problem:)

Regards,
Volker


On Wed, Aug 6, 2014 at 11:36 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 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
> concurrency?
>
> /Erik
>
>
> 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.
>>
>>
>