Is anyone able to build on Win 7 (original) (raw)

Volker Simonis volker.simonis at gmail.com
Fri Mar 9 18:15:46 UTC 2012

On Thu, Mar 8, 2012 at 8:00 PM, Kelly O'Hair <kelly.ohair at oracle.com> wrote:

On Mar 8, 2012, at 10:00 AM, Volker Simonis wrote:

This thread will probably never end (Windows 2046 :)

So I did more test...... - I wanted to compare with MKS and the first thing I hit on was a bug in MKS's 9.4 version of  cpio ("CFS# 32408--- cpio can not handle files which are ReadOnly"). And it's expensive and installation and license handling is PITA if you use several virtual machiines.. MKS 9.4 is seriously broken for us.  I use 9.0p3 or 9.0p4. I filed a ticket with MKS on this issue months ago and have never heard back from them, and we have a support contract with them too. :^(

- Still couldn't find the reason why the build hangs with Cygwin 1.7.10 that's a new one for me. When both MKS and CYGWIN are installed on the same system it can be tricky. After I install MKS I usually go in and take MKS out of the default PATH, and change SHELL to be just /usr/bin/sh (which appears to be more of a universal keyword than a path to a shell). Then I go shut down and disable all MKS services. Then when I want an MKS shell started up, I have some hacky PATH setting and exec of the MKS shell.  I could send you the formula if you would like. I've just kept wishing MKS could go away for us... someday... And you have provide a light at the end of the tunnel. ;^)  Thanks! Finally I decided to try something new - MinGW/MSYS. And indeed - it worked, it's nearly as fast as MKS, it can use the default make which comes with the MinGW/Installation. Read the glory details at: http://mail.openjdk.java.net/pipermail/build-dev/2012-March/005729.html Please feel free to test, review and (hopfully) submit it. The changes are intentionally against the old, "traditional" build system to fix the mentioned Cygwin problems and simplify the Windows build just now. As next steps I see the following points: - integrate MinGW/MSYS with the new build system - completely remove nmake from the HotSpot build and use prallel GNU make  like on Linux (I know this works and that it's faster - just have to build a OpenJDK patch) Any comments? Fantastic stuff.  I'll work on getting it in place. On replacing NMAKE, I agree with you however, I think NMAKE may be in cahoots with the VS compiler with regards to licensing checks or pre-compiled headers, the build is pretty fast. In my crude attempts in the past, I could never get anywhere close to the NMAKE build speed. Never completely understood why. :^(

I don't understand the licensing checks problem you mention? Do you mean 'cl' can only be called from nmake? I havn't seen this problem, although our internal build without 'nmake' I was mentioning runs with the commercial and not the Express version of MSVS.

For the precompiled headers issue we found a solution. I'll just have to port it to the OpenJDK.

-kto

Volker On Wed, Feb 15, 2012 at 1:10 PM, Fredrik Öhrström <fredrik.ohrstrom at oracle.com> wrote: ----- kelly.ohair at oracle.com skrev:

So I'm with you on the stat() theory, makes a great deal of sense. The stat theory is very interesting, but it is unclear to me if it explains all of the problem. I setup a quadruple boot x8664 machine with 4GB of ram and 4 cores: Winxp 32bit Win7 64bit Solaris 64bit Ubuntu 64bit And tested the build times on the different OS:es. Ubuntu Fastest by far. Solaris, slower, but this is only because of bad CC performance. Winxp, even slower but still ok. Win7, ridiculously slow. The configure script prints one line per second! Clearly, just running a bash script in cygwin/win7/64bit is problematic. If we get 10% speedup from dash, then that is not going to help because the slowdown is a factor 10. Could someone try out the difference between a 32bit win7 clean install and a 64 bit win7 clean install when running the latest cygwin and just the build-infra/jdk8/common/autoconf/configure script? (My patience for installing many OSes into the same box, just ran out. And virtualization testing can give a hint, but cannot be entirely trusted.) //Fredrik

More information about the build-dev mailing list