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 <[email protected]> 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.
