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

[Erik Joelsson]

Thanks, I will try that. The reports I found also said the problem was 
introduced in 1.0.18.

/Erik

On 2014-08-06 17:00, Volker Simonis wrote:
> 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.
>>>