From erik.joelsson at oracle.com  Wed Apr  1 07:56:35 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 01 Apr 2015 09:56:35 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
	to java.lang.management
In-Reply-To: <551ACDBD.6000703@oracle.com>
References: <551ACDBD.6000703@oracle.com>
Message-ID: <551BA4B3.7010105@oracle.com>

Hello,

(Adding build-dev since this touches makefiles and jigsaw-dev since this 
touches modules.xml)

In general, the build changes look pretty good. I much appreciate moving 
the OS specific source into OS specific source dirs. A few notes 
however. Though I realize you followed existing patterns, we have some 
more current best practices that I would like to incorporate in new code.

jdk/make/lib/Lib-jdk.management.gmk:

The variables BUILD_LIBJDKMANAGEMENT_SRC and 
BUILD_LIBJDKMANAGEMENT_CFLAGS should lose the "BUILD_" prefix. While it 
works, it makes them unnecessarily long and it risks conflicting with 
internal variables created in the SetupNativeCompilation call.

BUILD_LIBJDKMANAGEMENT_EXCLUDES is unused and should just be removed. 
The EXCLUDE_FILES parameter too.

LIBJDKMANAGEMENT_MAPFILE should be removed. This was a special construct 
for libmanagement used for a while until cmm was split into a separate 
module. Just inline the mapfile line into the macro call.


jdk/make/lib/Lib-java.management.gmk:

BUILD_LIBMANAGEMENT_EXCLUDES is unused here as well.

LIBMANAGEMENT_MAPFILE should be inlined here as well.

While you are at it, might as well fix the BUILD_ prefix on the SRC and 
CFLAGS variables here too if you don't mind.


Is the need for low optimization when debug symbols are active still 
valid for both libmanagement and libmanagement_ext?

/Erik

On 2015-03-31 18:39, shanliang wrote:
> Please review this fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>
> Some code within the module java.management is separated and moved to 
> the new module jdk.management, the new module takes the implementation 
> code for Oracle Corporation's platform extension to the implementation 
> of the java.lang.management API and also the management interface for 
> some other components for the platform.
>
> Thanks,
> Shanliang
>



From magnus.ihse.bursie at oracle.com  Wed Apr  1 08:33:12 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 1 Apr 2015 10:33:12 +0200
Subject: FYI: Build system rewrite in Ant
Message-ID: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>

The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows. 

An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.

The Build Team has therefore decided to rewrite the current build system from scratch in Ant. The old Makefiles will be put in maintenance mode while the new Ant scripts are being developed. To facilitate a speedy switch, all new build enhancements must be expressed in Ant logic, starting today. No modifications in the old Makefiles will be accepted by the Build Team.

To increase the robustness of the code base, the new build system will automatically check the integrity of all source code files before compilation. Each source file therefore must be accompanied by a Integrity Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have an Object.java.Integ_Manif.xml. This is a simple xml file, describing the purpose of the source code file, and a log of mercurial changeset id:s. An example file could looks like this:

<manifest xmlns="http://openjdk.java.net/ns/manifest/integrity/1">
    <type>net.java.openjdk.build.ant.manifest.integrity</type>
    <artifacts>
        <artifact>
            <source-code-descriptor>
               <filename>Object.java</filename>
               <description>Class Object is the root of the class hierarchy.</description>
            </source-code-descriptor>
        </artifact>
    </artifacts>
    <integrity>
        <revision-control>
            <committed-change>
                <changeid>541a8cef4e0d</changeid>
                <revision-control-system>mercurial</revision-control-system>
            </committed-change>
            <committed-change>
                <changeid>458adf31ad5b</changeid>
                <revision-control-system>mercurial</revision-control-system>
            </committed-change>
            <committed-change>
                <changeid>0846eddb56d5</changeid>
                <revision-control-system>mercurial</revision-control-system>
            </committed-change>
        </revision-control>
    </integrity>
</manifest>

Each time a new version of the file is committed to the mercurial repo, the developer just has to add a new committed-change stanza to the block in the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand, the Integrity Manifest file must be updated in a subsequent commit. 

But fear not! To assist developers in preserving the integrity of the source files, an addition to jcheck has been developed. If the subsequent commit does not properly describe the previous changeset ID, the original changeset will be automatically reverted, so no untracked changes will be stored permanently in the revision control system.

Finally, to fully utilize the promise of portability that the Ant and Java? technology brings, platforms with portability issues will be removed from the supported platform matrix. Currently, this only includes non-POSIX-compliant operating systems, since these have been known to cause various platform issues in the build system. The only known non-POSIX-compliant OS that the OpenJDK build system currently supports is the Windows OS family, so this reduction in support is hopefully not too burdensome.

These changes will take immediate effect of today, April 1 2015.

That's all for today, folks! :-)

/Magnus

From neugens.limasoftware at gmail.com  Wed Apr  1 08:41:30 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 1 Apr 2015 10:41:30 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID: <CAGUMyaTv_6gLn8rtqk90Ky0AgKp3SAOgAewXODWK-mJoEky4VQ@mail.gmail.com>

2015-04-01 10:33 GMT+02:00 Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com>:
> The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows.
>
> An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.

To be honest, I'm pretty disappointed by this move. In 2015 and with
the advancements in the JVM technology, I would have expected that
OpenJDK would be able to know how to build itself *without* a build
tool!!

:)

Mario


-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/


From volker.simonis at gmail.com  Wed Apr  1 08:49:34 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Wed, 1 Apr 2015 10:49:34 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID: <CA+3eh11c6PhN4SbrZC_0N=KqCYMPq7mV1piur5kFc1m-3VQ3VQ@mail.gmail.com>

Why not starting with the easiest part of your proposal which you've
sketched in the last paragraph and just remove the "only known
non-POSIX-compliant OS".

I'm preparing a webrev if you don't mind:)

Rgards,
Volker


On Wed, Apr 1, 2015 at 10:33 AM, Magnus Ihse Bursie
<magnus.ihse.bursie at oracle.com> wrote:
> The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows.
>
> An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.
>
> The Build Team has therefore decided to rewrite the current build system from scratch in Ant. The old Makefiles will be put in maintenance mode while the new Ant scripts are being developed. To facilitate a speedy switch, all new build enhancements must be expressed in Ant logic, starting today. No modifications in the old Makefiles will be accepted by the Build Team.
>
> To increase the robustness of the code base, the new build system will automatically check the integrity of all source code files before compilation. Each source file therefore must be accompanied by a Integrity Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have an Object.java.Integ_Manif.xml. This is a simple xml file, describing the purpose of the source code file, and a log of mercurial changeset id:s. An example file could looks like this:
>
> <manifest xmlns="http://openjdk.java.net/ns/manifest/integrity/1">
>     <type>net.java.openjdk.build.ant.manifest.integrity</type>
>     <artifacts>
>         <artifact>
>             <source-code-descriptor>
>                <filename>Object.java</filename>
>                <description>Class Object is the root of the class hierarchy.</description>
>             </source-code-descriptor>
>         </artifact>
>     </artifacts>
>     <integrity>
>         <revision-control>
>             <committed-change>
>                 <changeid>541a8cef4e0d</changeid>
>                 <revision-control-system>mercurial</revision-control-system>
>             </committed-change>
>             <committed-change>
>                 <changeid>458adf31ad5b</changeid>
>                 <revision-control-system>mercurial</revision-control-system>
>             </committed-change>
>             <committed-change>
>                 <changeid>0846eddb56d5</changeid>
>                 <revision-control-system>mercurial</revision-control-system>
>             </committed-change>
>         </revision-control>
>     </integrity>
> </manifest>
>
> Each time a new version of the file is committed to the mercurial repo, the developer just has to add a new committed-change stanza to the block in the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand, the Integrity Manifest file must be updated in a subsequent commit.
>
> But fear not! To assist developers in preserving the integrity of the source files, an addition to jcheck has been developed. If the subsequent commit does not properly describe the previous changeset ID, the original changeset will be automatically reverted, so no untracked changes will be stored permanently in the revision control system.
>
> Finally, to fully utilize the promise of portability that the Ant and Java? technology brings, platforms with portability issues will be removed from the supported platform matrix. Currently, this only includes non-POSIX-compliant operating systems, since these have been known to cause various platform issues in the build system. The only known non-POSIX-compliant OS that the OpenJDK build system currently supports is the Windows OS family, so this reduction in support is hopefully not too burdensome.
>
> These changes will take immediate effect of today, April 1 2015.
>
> That's all for today, folks! :-)
>
> /Magnus


From david.katleman at oracle.com  Wed Apr  1 09:21:19 2015
From: david.katleman at oracle.com (David Katleman (Oracle))
Date: Wed, 1 Apr 2015 02:21:19 -0700
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
Message-ID: <C466D5A0-6259-42AA-B5BE-220447BE843B@oracle.com>

+1

Please say were going to use the extension that predict build failures before they occur and provides an automated root cause analysis.  I believe is called Ant predictive recursive interpreter language with Forensic object oriented linguistic syntax.


> On Apr 1, 2015, at 1:33 AM, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com> wrote:
> 
> The build system currently uses make to build OpenJDK. This is a technology that has been around for decades, and in places this legacy clearly shows. 
> 
> An alternative build tool, Ant, is based on cutting-edge technology. Compared to the native GNU Make, Ant is based on Java? technology, which makes portability issues a thing of the past. Ant is also directed using modern XML systems, with well-defined tags, compared to the aged and idiosyncratic Makefile syntax.
> 
> The Build Team has therefore decided to rewrite the current build system from scratch in Ant. The old Makefiles will be put in maintenance mode while the new Ant scripts are being developed. To facilitate a speedy switch, all new build enhancements must be expressed in Ant logic, starting today. No modifications in the old Makefiles will be accepted by the Build Team.
> 
> To increase the robustness of the code base, the new build system will automatically check the integrity of all source code files before compilation. Each source file therefore must be accompanied by a Integrity Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have an Object.java.Integ_Manif.xml. This is a simple xml file, describing the purpose of the source code file, and a log of mercurial changeset id:s. An example file could looks like this:
> 
> <manifest xmlns="http://openjdk.java.net/ns/manifest/integrity/1">
>    <type>net.java.openjdk.build.ant.manifest.integrity</type>
>    <artifacts>
>        <artifact>
>            <source-code-descriptor>
>               <filename>Object.java</filename>
>               <description>Class Object is the root of the class hierarchy.</description>
>            </source-code-descriptor>
>        </artifact>
>    </artifacts>
>    <integrity>
>        <revision-control>
>            <committed-change>
>                <changeid>541a8cef4e0d</changeid>
>                <revision-control-system>mercurial</revision-control-system>
>            </committed-change>
>            <committed-change>
>                <changeid>458adf31ad5b</changeid>
>                <revision-control-system>mercurial</revision-control-system>
>            </committed-change>
>            <committed-change>
>                <changeid>0846eddb56d5</changeid>
>                <revision-control-system>mercurial</revision-control-system>
>            </committed-change>
>        </revision-control>
>    </integrity>
> </manifest>
> 
> Each time a new version of the file is committed to the mercurial repo, the developer just has to add a new committed-change stanza to the block in the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand, the Integrity Manifest file must be updated in a subsequent commit. 
> 
> But fear not! To assist developers in preserving the integrity of the source files, an addition to jcheck has been developed. If the subsequent commit does not properly describe the previous changeset ID, the original changeset will be automatically reverted, so no untracked changes will be stored permanently in the revision control system.
> 
> Finally, to fully utilize the promise of portability that the Ant and Java? technology brings, platforms with portability issues will be removed from the supported platform matrix. Currently, this only includes non-POSIX-compliant operating systems, since these have been known to cause various platform issues in the build system. The only known non-POSIX-compliant OS that the OpenJDK build system currently supports is the Windows OS family, so this reduction in support is hopefully not too burdensome.
> 
> These changes will take immediate effect of today, April 1 2015.
> 
> That's all for today, folks! :-)
> 
> /Magnus


From martijnverburg at gmail.com  Wed Apr  1 09:59:46 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 1 Apr 2015 10:59:46 +0100
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <C466D5A0-6259-42AA-B5BE-220447BE843B@oracle.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
	<C466D5A0-6259-42AA-B5BE-220447BE843B@oracle.com>
Message-ID: <CAP7YuATKAemQgPmmQ2c3HGiAM5aWxEAzMDLqU3RSQPqCLWiMtw@mail.gmail.com>

I'm personally willing to provide a ANT to MAVEN conversion tool which will
allow for a more verbose an rdable build system.  It will also ensure that
dependencies are always downloaded at all times ensuring network pipes are
kept clean.

Cheers,
Martijn

On 1 April 2015 at 10:21, David Katleman (Oracle) <david.katleman at oracle.com
> wrote:

> +1
>
> Please say were going to use the extension that predict build failures
> before they occur and provides an automated root cause analysis.  I believe
> is called Ant predictive recursive interpreter language with Forensic
> object oriented linguistic syntax.
>
>
> > On Apr 1, 2015, at 1:33 AM, Magnus Ihse Bursie <
> magnus.ihse.bursie at oracle.com> wrote:
> >
> > The build system currently uses make to build OpenJDK. This is a
> technology that has been around for decades, and in places this legacy
> clearly shows.
> >
> > An alternative build tool, Ant, is based on cutting-edge technology.
> Compared to the native GNU Make, Ant is based on Java? technology, which
> makes portability issues a thing of the past. Ant is also directed using
> modern XML systems, with well-defined tags, compared to the aged and
> idiosyncratic Makefile syntax.
> >
> > The Build Team has therefore decided to rewrite the current build system
> from scratch in Ant. The old Makefiles will be put in maintenance mode
> while the new Ant scripts are being developed. To facilitate a speedy
> switch, all new build enhancements must be expressed in Ant logic, starting
> today. No modifications in the old Makefiles will be accepted by the Build
> Team.
> >
> > To increase the robustness of the code base, the new build system will
> automatically check the integrity of all source code files before
> compilation. Each source file therefore must be accompanied by a Integrity
> Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have
> an Object.java.Integ_Manif.xml. This is a simple xml file, describing the
> purpose of the source code file, and a log of mercurial changeset id:s. An
> example file could looks like this:
> >
> > <manifest xmlns="http://openjdk.java.net/ns/manifest/integrity/1">
> >    <type>net.java.openjdk.build.ant.manifest.integrity</type>
> >    <artifacts>
> >        <artifact>
> >            <source-code-descriptor>
> >               <filename>Object.java</filename>
> >               <description>Class Object is the root of the class
> hierarchy.</description>
> >            </source-code-descriptor>
> >        </artifact>
> >    </artifacts>
> >    <integrity>
> >        <revision-control>
> >            <committed-change>
> >                <changeid>541a8cef4e0d</changeid>
> >
> <revision-control-system>mercurial</revision-control-system>
> >            </committed-change>
> >            <committed-change>
> >                <changeid>458adf31ad5b</changeid>
> >
> <revision-control-system>mercurial</revision-control-system>
> >            </committed-change>
> >            <committed-change>
> >                <changeid>0846eddb56d5</changeid>
> >
> <revision-control-system>mercurial</revision-control-system>
> >            </committed-change>
> >        </revision-control>
> >    </integrity>
> > </manifest>
> >
> > Each time a new version of the file is committed to the mercurial repo,
> the developer just has to add a new committed-change stanza to the block in
> the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand,
> the Integrity Manifest file must be updated in a subsequent commit.
> >
> > But fear not! To assist developers in preserving the integrity of the
> source files, an addition to jcheck has been developed. If the subsequent
> commit does not properly describe the previous changeset ID, the original
> changeset will be automatically reverted, so no untracked changes will be
> stored permanently in the revision control system.
> >
> > Finally, to fully utilize the promise of portability that the Ant and
> Java? technology brings, platforms with portability issues will be removed
> from the supported platform matrix. Currently, this only includes
> non-POSIX-compliant operating systems, since these have been known to cause
> various platform issues in the build system. The only known
> non-POSIX-compliant OS that the OpenJDK build system currently supports is
> the Windows OS family, so this reduction in support is hopefully not too
> burdensome.
> >
> > These changes will take immediate effect of today, April 1 2015.
> >
> > That's all for today, folks! :-)
> >
> > /Magnus
>


From james.laskey at oracle.com  Wed Apr  1 10:18:14 2015
From: james.laskey at oracle.com (James Laskey)
Date: Wed, 1 Apr 2015 07:18:14 -0300
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <CAP7YuATKAemQgPmmQ2c3HGiAM5aWxEAzMDLqU3RSQPqCLWiMtw@mail.gmail.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
	<C466D5A0-6259-42AA-B5BE-220447BE843B@oracle.com>
	<CAP7YuATKAemQgPmmQ2c3HGiAM5aWxEAzMDLqU3RSQPqCLWiMtw@mail.gmail.com>
Message-ID: <D61E8422-0C8F-442B-A2CF-7D3BDE6F294C@oracle.com>

I may have been misled, but I thought Ant was replaced by a non-deterministic build system called Termight. 

Sent from my iPhone

> On Apr 1, 2015, at 6:59 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
> 
> I'm personally willing to provide a ANT to MAVEN conversion tool which will
> allow for a more verbose an rdable build system.  It will also ensure that
> dependencies are always downloaded at all times ensuring network pipes are
> kept clean.
> 
> Cheers,
> Martijn
> 
> On 1 April 2015 at 10:21, David Katleman (Oracle) <david.katleman at oracle.com
>> wrote:
> 
>> +1
>> 
>> Please say were going to use the extension that predict build failures
>> before they occur and provides an automated root cause analysis.  I believe
>> is called Ant predictive recursive interpreter language with Forensic
>> object oriented linguistic syntax.
>> 
>> 
>>>> On Apr 1, 2015, at 1:33 AM, Magnus Ihse Bursie <
>>> magnus.ihse.bursie at oracle.com> wrote:
>>> 
>>> The build system currently uses make to build OpenJDK. This is a
>> technology that has been around for decades, and in places this legacy
>> clearly shows.
>>> 
>>> An alternative build tool, Ant, is based on cutting-edge technology.
>> Compared to the native GNU Make, Ant is based on Java? technology, which
>> makes portability issues a thing of the past. Ant is also directed using
>> modern XML systems, with well-defined tags, compared to the aged and
>> idiosyncratic Makefile syntax.
>>> 
>>> The Build Team has therefore decided to rewrite the current build system
>> from scratch in Ant. The old Makefiles will be put in maintenance mode
>> while the new Ant scripts are being developed. To facilitate a speedy
>> switch, all new build enhancements must be expressed in Ant logic, starting
>> today. No modifications in the old Makefiles will be accepted by the Build
>> Team.
>>> 
>>> To increase the robustness of the code base, the new build system will
>> automatically check the integrity of all source code files before
>> compilation. Each source file therefore must be accompanied by a Integrity
>> Manifest (.Ingeg_Manif.xml). For instance, the file Object.java would have
>> an Object.java.Integ_Manif.xml. This is a simple xml file, describing the
>> purpose of the source code file, and a log of mercurial changeset id:s. An
>> example file could looks like this:
>>> 
>>> <manifest xmlns="http://openjdk.java.net/ns/manifest/integrity/1">
>>>   <type>net.java.openjdk.build.ant.manifest.integrity</type>
>>>   <artifacts>
>>>       <artifact>
>>>           <source-code-descriptor>
>>>              <filename>Object.java</filename>
>>>              <description>Class Object is the root of the class
>> hierarchy.</description>
>>>           </source-code-descriptor>
>>>       </artifact>
>>>   </artifacts>
>>>   <integrity>
>>>       <revision-control>
>>>           <committed-change>
>>>               <changeid>541a8cef4e0d</changeid>
>> <revision-control-system>mercurial</revision-control-system>
>>>           </committed-change>
>>>           <committed-change>
>>>               <changeid>458adf31ad5b</changeid>
>> <revision-control-system>mercurial</revision-control-system>
>>>           </committed-change>
>>>           <committed-change>
>>>               <changeid>0846eddb56d5</changeid>
>> <revision-control-system>mercurial</revision-control-system>
>>>           </committed-change>
>>>       </revision-control>
>>>   </integrity>
>>> </manifest>
>>> 
>>> Each time a new version of the file is committed to the mercurial repo,
>> the developer just has to add a new committed-change stanza to the block in
>> the .Ingeg_Manif.xml file. Since the changeset ID is not known before hand,
>> the Integrity Manifest file must be updated in a subsequent commit.
>>> 
>>> But fear not! To assist developers in preserving the integrity of the
>> source files, an addition to jcheck has been developed. If the subsequent
>> commit does not properly describe the previous changeset ID, the original
>> changeset will be automatically reverted, so no untracked changes will be
>> stored permanently in the revision control system.
>>> 
>>> Finally, to fully utilize the promise of portability that the Ant and
>> Java? technology brings, platforms with portability issues will be removed
>> from the supported platform matrix. Currently, this only includes
>> non-POSIX-compliant operating systems, since these have been known to cause
>> various platform issues in the build system. The only known
>> non-POSIX-compliant OS that the OpenJDK build system currently supports is
>> the Windows OS family, so this reduction in support is hopefully not too
>> burdensome.
>>> 
>>> These changes will take immediate effect of today, April 1 2015.
>>> 
>>> That's all for today, folks! :-)
>>> 
>>> /Magnus
>> 


From neugens.limasoftware at gmail.com  Wed Apr  1 10:30:03 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 1 Apr 2015 12:30:03 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <D61E8422-0C8F-442B-A2CF-7D3BDE6F294C@oracle.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
	<C466D5A0-6259-42AA-B5BE-220447BE843B@oracle.com>
	<CAP7YuATKAemQgPmmQ2c3HGiAM5aWxEAzMDLqU3RSQPqCLWiMtw@mail.gmail.com>
	<D61E8422-0C8F-442B-A2CF-7D3BDE6F294C@oracle.com>
Message-ID: <CAGUMyaQyZuB1=vROyCU7R6E3F7-fUOPH4rPE2VjK7MDeSAHhCw@mail.gmail.com>

2015-04-01 12:18 GMT+02:00 James Laskey <james.laskey at oracle.com>:
> I may have been misled, but I thought Ant was replaced by a non-deterministic build system called Termight.

:)

I think that indeed Ant is obsolete already, and since we are in the
space exploration era, this may be more appropriate:

https://github.com/lhartikk/AstroBuild

Mario


-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/


From neugens.limasoftware at gmail.com  Wed Apr  1 10:41:50 2015
From: neugens.limasoftware at gmail.com (Mario Torre)
Date: Wed, 1 Apr 2015 12:41:50 +0200
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <CAP7YuATKAemQgPmmQ2c3HGiAM5aWxEAzMDLqU3RSQPqCLWiMtw@mail.gmail.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
	<C466D5A0-6259-42AA-B5BE-220447BE843B@oracle.com>
	<CAP7YuATKAemQgPmmQ2c3HGiAM5aWxEAzMDLqU3RSQPqCLWiMtw@mail.gmail.com>
Message-ID: <CAGUMyaThY1JLLKkmeTNaLHZoR6aq_VW1cqAG1Fx6r0v3Jfz5bg@mail.gmail.com>

2015-04-01 11:59 GMT+02:00 Martijn Verburg <martijnverburg at gmail.com>:
> I'm personally willing to provide a ANT to MAVEN conversion tool which will
> allow for a more verbose an rdable build system.  It will also ensure that
> dependencies are always downloaded at all times ensuring network pipes are
> kept clean.

Ok, I've had a discussion with the rest of my team and we are
convinced that real Free Software projects cannot live without
Makefiles.

So in order to give people choice I'm volunteering to restore the old
system used in IcedTea version 6 as a fork of the current ant based
build tool.

While there, we noticed that Mercurial is really leading to a very
high flow of patches, too difficult to work with and follow, so we
decide to move to RCS.

We think this is the only reasonable thing to do in a fast paced
project and the increased workflow will create less and more focused
commits, leading to a higher quality of them!

Cheers,
Mario
-- 
pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF

Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
Proud GNU Classpath developer: http://www.classpath.org/
OpenJDK: http://openjdk.java.net/projects/caciocavallo/

Please, support open standards:
http://endsoftpatents.org/


From shanliang.jiang at oracle.com  Wed Apr  1 18:03:04 2015
From: shanliang.jiang at oracle.com (shanliang)
Date: Wed, 01 Apr 2015 20:03:04 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
	to java.lang.management
In-Reply-To: <551BA4B3.7010105@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551BA4B3.7010105@oracle.com>
Message-ID: <551C32D8.3020100@oracle.com>

Erik Joelsson wrote:
> Hello,
>
> (Adding build-dev since this touches makefiles and jigsaw-dev since 
> this touches modules.xml)
>
> In general, the build changes look pretty good. I much appreciate 
> moving the OS specific source into OS specific source dirs. A few 
> notes however. Though I realize you followed existing patterns, we 
> have some more current best practices that I would like to incorporate 
> in new code.
>
> jdk/make/lib/Lib-jdk.management.gmk:
>
> The variables BUILD_LIBJDKMANAGEMENT_SRC and 
> BUILD_LIBJDKMANAGEMENT_CFLAGS should lose the "BUILD_" prefix. While 
> it works, it makes them unnecessarily long and it risks conflicting 
> with internal variables created in the SetupNativeCompilation call.
Done.
>
> BUILD_LIBJDKMANAGEMENT_EXCLUDES is unused and should just be removed. 
> The EXCLUDE_FILES parameter too.
Done.
>
> LIBJDKMANAGEMENT_MAPFILE should be removed. This was a special 
> construct for libmanagement used for a while until cmm was split into 
> a separate module. Just inline the mapfile line into the macro call.
Done.
>
>
> jdk/make/lib/Lib-java.management.gmk:
>
> BUILD_LIBMANAGEMENT_EXCLUDES is unused here as well.
Removed.
>
> LIBMANAGEMENT_MAPFILE should be inlined here as well.
Done.
>
> While you are at it, might as well fix the BUILD_ prefix on the SRC 
> and CFLAGS variables here too if you don't mind.
Done.
>
>
> Is the need for low optimization when debug symbols are active still 
> valid for both libmanagement and libmanagement_ext?
Sorry I do not know, I did not touch that flag stting in libmanagement, 
and I copied it for libmanagement_ext.

Here is the new version:
    http://cr.openjdk.java.net/~sjiang/JDK-8042901/01/

Thanks for the review.
Shanliang

>
> /Erik
>
> On 2015-03-31 18:39, shanliang wrote:
>> Please review this fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>>
>> Some code within the module java.management is separated and moved to 
>> the new module jdk.management, the new module takes the 
>> implementation code for Oracle Corporation's platform extension to 
>> the implementation of the java.lang.management API and also the 
>> management interface for some other components for the platform.
>>
>> Thanks,
>> Shanliang
>>
>



From sandeep.konchady at oracle.com  Wed Apr  1 20:34:54 2015
From: sandeep.konchady at oracle.com (Sandeep Konchady)
Date: Wed, 1 Apr 2015 13:34:54 -0700
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
Message-ID: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>

Hi,

I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.

Darwin Kernel Version 14.1.0

using configure arguments '--enable-ccache'.

Configuration summary:
* Debug level:    release
* HS debug level: product
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64

Tools summary:
* Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
* Toolchain:      clang (clang/LLVM)
* C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
* C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   2
* Memory limit:   8192 MB
* ccache status:  Active (3.1.6)


Error Log:

Creating data for first make execution in new configuration...
Done
Building target(s) 'default' in configuration 'macosx-x86_64-normal-server-release'
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Parsing 1 properties into enum-like class for jdk.compiler
Compiling 20 properties into resource bundles for jdk.compiler
Compiling 5 properties into resource bundles for jdk.dev
Compiling 10 properties into resource bundles for jdk.javadoc
Compiling 822 files for BUILD_INTERIM_LANGTOOLS
Creating buildtools/interim_langtools.jar
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
Compiling 23 files for BUILD_INTERIM_JIMAGE
Compiling 161 files for BUILD_TOOLS_JDK
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 141 files for BUILD_IDLJ
clang: error: argument unused during compilation: '-I .'
clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/prims'
clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm'
clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/precompiled'
clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/cpu/x86/vm'
clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os_cpu/bsd_x86/vm'
clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/bsd/vm'
clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/posix/vm'
clang: error: argument unused during compilation: '-I ../generated'
clang: error: argument unused during compilation: '-include precompiled.hpp'
make[10]: *** [abstractCompiler.o] Error 1
make[9]: *** [the_vm] Error 2
make[8]: *** [product] Error 2
make[7]: *** [generic_build2] Error 2
make[6]: *** [product] Error 2
make[5]: *** [all_product_universal] Error 2
make[4]: *** [universal_product] Error 2
make[3]: *** [/Users/sandeepk/Workspace/JDK/jdk9-dev/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2
make[2]: *** [hotspot] Error 2
make[2]: *** Waiting for unfinished jobs....
Compiling 6 files for BUILD_TOOLS_CORBA
Note: /Users/sandeepk/Workspace/JDK/jdk9-dev/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
make[1]: *** [main] Error 2
make: *** [default] Error 2

Thanks,
Sandeep

From sandeep.konchady at oracle.com  Wed Apr  1 20:51:24 2015
From: sandeep.konchady at oracle.com (Sandeep Konchady)
Date: Wed, 1 Apr 2015 13:51:24 -0700
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
Message-ID: <D573C3B4-2FBA-4D5C-92BD-2D9FB95A5B91@oracle.com>

Forgot to mention, I am trying to build jdk9/dev

Thanks,
Sandeep

> On Apr 1, 2015, at 1:34 PM, Sandeep Konchady <sandeep.konchady at oracle.com> wrote:
> 
> Hi,
> 
> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.
> 
> Darwin Kernel Version 14.1.0
> 
> using configure arguments '--enable-ccache'.
> 
> Configuration summary:
> * Debug level:    release
> * HS debug level: product
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
> 
> Tools summary:
> * Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
> * Toolchain:      clang (clang/LLVM)
> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)
> 
> Build performance summary:
> * Cores to use:   2
> * Memory limit:   8192 MB
> * ccache status:  Active (3.1.6)
> 
> 
> Error Log:
> 
> Creating data for first make execution in new configuration...
> Done
> Building target(s) 'default' in configuration 'macosx-x86_64-normal-server-release'
> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
> Parsing 1 properties into enum-like class for jdk.compiler
> Compiling 20 properties into resource bundles for jdk.compiler
> Compiling 5 properties into resource bundles for jdk.dev
> Compiling 10 properties into resource bundles for jdk.javadoc
> Compiling 822 files for BUILD_INTERIM_LANGTOOLS
> Creating buildtools/interim_langtools.jar
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> Warning: generation and use of skeletons and static stubs for JRMP
> is deprecated. Skeletons are unnecessary, and static stubs have
> been superseded by dynamically generated stubs. Users are
> encouraged to migrate away from using rmic to generate skeletons and static
> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
> Compiling 23 files for BUILD_INTERIM_JIMAGE
> Compiling 161 files for BUILD_TOOLS_JDK
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> Compiling 141 files for BUILD_IDLJ
> clang: error: argument unused during compilation: '-I .'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/prims'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/precompiled'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/cpu/x86/vm'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os_cpu/bsd_x86/vm'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/bsd/vm'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/posix/vm'
> clang: error: argument unused during compilation: '-I ../generated'
> clang: error: argument unused during compilation: '-include precompiled.hpp'
> make[10]: *** [abstractCompiler.o] Error 1
> make[9]: *** [the_vm] Error 2
> make[8]: *** [product] Error 2
> make[7]: *** [generic_build2] Error 2
> make[6]: *** [product] Error 2
> make[5]: *** [all_product_universal] Error 2
> make[4]: *** [universal_product] Error 2
> make[3]: *** [/Users/sandeepk/Workspace/JDK/jdk9-dev/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2
> make[2]: *** [hotspot] Error 2
> make[2]: *** Waiting for unfinished jobs....
> Compiling 6 files for BUILD_TOOLS_CORBA
> Note: /Users/sandeepk/Workspace/JDK/jdk9-dev/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> make[1]: *** [main] Error 2
> make: *** [default] Error 2
> 
> Thanks,
> Sandeep



From david.dehaven at oracle.com  Wed Apr  1 20:53:11 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 1 Apr 2015 13:53:11 -0700
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
Message-ID: <077F15CA-2A7E-48FF-8F85-11E1C9649E09@oracle.com>


> On Apr 1, 2015, at 1:34 PM, Sandeep Konchady <sandeep.konchady at oracle.com> wrote:
> 
> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.
> 
> Darwin Kernel Version 14.1.0
> 
> using configure arguments '--enable-ccache'.

I haven't tried running ccache in a long time. Have you tried with it disabled?

-DrD-



From sandeep.konchady at oracle.com  Wed Apr  1 21:31:38 2015
From: sandeep.konchady at oracle.com (Sandeep Konchady)
Date: Wed, 1 Apr 2015 14:31:38 -0700
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <077F15CA-2A7E-48FF-8F85-11E1C9649E09@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
	<077F15CA-2A7E-48FF-8F85-11E1C9649E09@oracle.com>
Message-ID: <64190B95-B7CC-4538-BD92-F55387098D83@oracle.com>


Thanks for the suggestion David. Interestingly enough it did build without ccache.

- Sandeep


> On Apr 1, 2015, at 1:53 PM, David DeHaven <david.dehaven at oracle.com> wrote:
> 
> 
>> On Apr 1, 2015, at 1:34 PM, Sandeep Konchady <sandeep.konchady at oracle.com> wrote:
>> 
>> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.
>> 
>> Darwin Kernel Version 14.1.0
>> 
>> using configure arguments '--enable-ccache'.
> 
> I haven't tried running ccache in a long time. Have you tried with it disabled?
> 
> -DrD-
> 



From sadhak001 at gmail.com  Wed Apr  1 21:41:35 2015
From: sadhak001 at gmail.com (Mani Sarkar)
Date: Wed, 1 Apr 2015 22:41:35 +0100
Subject: FYI: Build system rewrite in Ant
In-Reply-To: <CAGUMyaThY1JLLKkmeTNaLHZoR6aq_VW1cqAG1Fx6r0v3Jfz5bg@mail.gmail.com>
References: <02859F1B-FFBD-4155-B6B8-77DF1D8C951C@oracle.com>
	<C466D5A0-6259-42AA-B5BE-220447BE843B@oracle.com>
	<CAP7YuATKAemQgPmmQ2c3HGiAM5aWxEAzMDLqU3RSQPqCLWiMtw@mail.gmail.com>
	<CAGUMyaThY1JLLKkmeTNaLHZoR6aq_VW1cqAG1Fx6r0v3Jfz5bg@mail.gmail.com>
Message-ID: <CAGHtMWnr6DQ1hEycNc7a7CHT6P3008W757dTiANQKNokKMuj4g@mail.gmail.com>

+1 to Martijn's gesture to a conversion tool, I'm personally driven to
explore these:

- Gradle
- Maven and its derivatives are a good option too
(see this article
http://www.drdobbs.com/jvm/why-build-your-java-projects-with-gradle/240168608
)

- https://buildr.apache.org/

- https://facebook.github.io/buck/ - ultra fast ;)

You might not go for this immediately, but ideas from here are good for the
present and future of Java -
https://typesafe.com/blog/zinc-and-incremental-compilation

Here's a nice comparison -
https://www.symphonious.net/2010/01/11/comparing-build-systems/

I find XML hard to read compared to JSON or YAML - especially when your XML
file grows into a big huge monolith.

With this I hope I have made some friends and some will likely become
friends eventually.

Cheers,
Mani



On Wed, Apr 1, 2015 at 11:41 AM, Mario Torre <neugens.limasoftware at gmail.com
> wrote:

> 2015-04-01 11:59 GMT+02:00 Martijn Verburg <martijnverburg at gmail.com>:
> > I'm personally willing to provide a ANT to MAVEN conversion tool which
> will
> > allow for a more verbose an rdable build system.  It will also ensure
> that
> > dependencies are always downloaded at all times ensuring network pipes
> are
> > kept clean.
>
> Ok, I've had a discussion with the rest of my team and we are
> convinced that real Free Software projects cannot live without
> Makefiles.
>
> So in order to give people choice I'm volunteering to restore the old
> system used in IcedTea version 6 as a fork of the current ant based
> build tool.
>
> While there, we noticed that Mercurial is really leading to a very
> high flow of patches, too difficult to work with and follow, so we
> decide to move to RCS.
>
> We think this is the only reasonable thing to do in a fast paced
> project and the increased workflow will create less and more focused
> commits, leading to a higher quality of them!
>
> Cheers,
> Mario
> --
> pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF
> Fingerprint: BA39 9666 94EC 8B73 27FA  FC7C 4086 63E3 80F2 40CF
>
> Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens
> Proud GNU Classpath developer: http://www.classpath.org/
> OpenJDK: http://openjdk.java.net/projects/caciocavallo/
>
> Please, support open standards:
> http://endsoftpatents.org/
>



-- 
@theNeomatrix369 <http://twitter.com/theNeomatrix369>*  |  **Blog
<http://neomatrix369.wordpress.com>**  |  *LJC Associate & LJC Advocate
(@adoptopenjdk & @adoptajsr programs)
*Meet-a-Project - *MutabilityDetector
<https://github.com/MutabilityDetector>*  |  **Bitbucket
<https://bitbucket.org/neomatrix369>* * |  **Github
<https://github.com/neomatrix369>* * |  **LinkedIn
<http://uk.linkedin.com/pub/mani-sarkar/71/a77/39b>*
*Come to Devoxx UK 2015:* http://www.devoxx.co.uk/

*Don't chase success, rather aim for "Excellence", and success will come
chasing after you!*


From mandy.chung at oracle.com  Wed Apr  1 21:41:54 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 01 Apr 2015 14:41:54 -0700
Subject: RFR 8042901: Allow com.sun.management to be in a different module
	to java.lang.management
In-Reply-To: <551ACDBD.6000703@oracle.com>
References: <551ACDBD.6000703@oracle.com>
Message-ID: <551C6622.1020609@oracle.com>

On 3/31/2015 9:39 AM, shanliang wrote:
> Please review this fix:
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/

Thank you for doing this big change to separate com.sun.management
API from java.management module.   Looking really good.

Also thanks for fixing the tests to eliminate the unnecessary use of
JDK internal APIs.

modules.xml change looks good to me.

sun/management/ThreadImpl.java
   35 /**
   36  * Implementation class for the thread subsystem.
   37  * Standard and committed hotspot-specific metrics if any.
   38  *
   39  * ManagementFactory.getThreadMXBean() returns an instance
   40  * of this class.
   41  */
   42 // the implementation for com.sun.management.ThreadMXBean can
   43 // be moved to jdk.management in the future.

What about:
   Implementation for java.lang.management.ThreadMXBean as well as
   providing the supporting method for com.sun.management.ThreadMXBean.
   
   The supporting method for com.sun.management.ThreadMXBean can
   be moved to jdk.management in the future.

CheckSomeMXBeanImplPackage.java
    Thanks for adding this test.

    Iterating jrt file system to find jdk.management module is one way.
    Another simpler alternative is to call:
      Class.forName("com.sun.management.GarbageCollectorMXBean");
    and catch CNFE to determine if it's present or not.

    You should also call ManagementFactory.getPlatformMXBeans on
    com.sun.management.GarbageCollectorMXBean if present.

VMOptionOpenDataTest.java
    copyright header year is wrong.

PlatformMBeanProviderConstructorCheck.java
    The test needs to restore the original policy and security manager
    before the test exits in case this case runs in agent vm mode.
    The static permName and accepted variables are more appropriate
    in MyPolicy class.  Perhaps rename "accepted" to an instance
    "denied" or "allowed" variable of MyPolicy class to reflect
    what it intends to mean.

I'm okay if you make the change before the push.  No need for a new
webrev.

Mandy



From david.dehaven at oracle.com  Wed Apr  1 22:04:00 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 1 Apr 2015 15:04:00 -0700
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <64190B95-B7CC-4538-BD92-F55387098D83@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
	<077F15CA-2A7E-48FF-8F85-11E1C9649E09@oracle.com>
	<64190B95-B7CC-4538-BD92-F55387098D83@oracle.com>
Message-ID: <418DFC4F-2086-4B22-A920-19BE3D07B8B6@oracle.com>


Cool, glad it helped!

-DrD-

> Thanks for the suggestion David. Interestingly enough it did build without ccache.
> 
> - Sandeep
> 
> 
>> On Apr 1, 2015, at 1:53 PM, David DeHaven <david.dehaven at oracle.com> wrote:
>> 
>> 
>>> On Apr 1, 2015, at 1:34 PM, Sandeep Konchady <sandeep.konchady at oracle.com> wrote:
>>> 
>>> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.
>>> 
>>> Darwin Kernel Version 14.1.0
>>> 
>>> using configure arguments '--enable-ccache'.
>> 
>> I haven't tried running ccache in a long time. Have you tried with it disabled?
>> 
>> -DrD-
>> 
> 



From magnus.ihse.bursie at oracle.com  Thu Apr  2 07:34:07 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 02 Apr 2015 09:34:07 +0200
Subject: Subject: RFR: JDK-8076465 New Init.gmk needs improvements
Message-ID: <551CF0EF.6040406@oracle.com>

It turned out that the new make bootstrapping file Init.gmk needed some 
redesign.

First of all, we should always respect the SPEC if possible, and not 
chose a random configuration for extracting targets.

Secondly, tab completion did not work in a non-standard configuration 
directory. (This is slightly related to the problem above.)

And third, there were still some code cleanup necessary.

Bug: https://bugs.openjdk.java.net/browse/JDK-8076465
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8076465-init-improvements/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Thu Apr  2 07:38:03 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 02 Apr 2015 09:38:03 +0200
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <64190B95-B7CC-4538-BD92-F55387098D83@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>	<077F15CA-2A7E-48FF-8F85-11E1C9649E09@oracle.com>
	<64190B95-B7CC-4538-BD92-F55387098D83@oracle.com>
Message-ID: <551CF1DB.8010208@oracle.com>

On 2015-04-01 23:31, Sandeep Konchady wrote:
> Thanks for the suggestion David. Interestingly enough it did build without ccache.

Erik told me that ccache introduced support for precompiled headers in 
v3.2. According to your logs, you are using ccache v.3.1.6. If you 
really want to use ccache, you should try to upgrade to 3.2 or later.

/Magnus


From erik.joelsson at oracle.com  Thu Apr  2 07:38:31 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 02 Apr 2015 09:38:31 +0200
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
Message-ID: <551CF1F7.9010107@oracle.com>

Hello,

I haven't tried ccache since we introduced clang as the official 
toolchain for macosx. According to the ccache changelog, support for 
precompiled headers on clang was introduced in version 3.2, while you 
are using 3.1.6. I don't know if just switching version will make it 
work or if there is additional configuration needed for this 
configuration, but it would be good to know. At the very least we will 
need to warn/fail in configure when precompiled headers and ccache are 
used together with clang.

/Erik

On 2015-04-01 22:34, Sandeep Konchady wrote:
> Hi,
>
> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.
>
> Darwin Kernel Version 14.1.0
>
> using configure arguments '--enable-ccache'.
>
> Configuration summary:
> * Debug level:    release
> * HS debug level: product
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>
> Tools summary:
> * Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
> * Toolchain:      clang (clang/LLVM)
> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)
>
> Build performance summary:
> * Cores to use:   2
> * Memory limit:   8192 MB
> * ccache status:  Active (3.1.6)
>
>
> Error Log:
>
> Creating data for first make execution in new configuration...
> Done
> Building target(s) 'default' in configuration 'macosx-x86_64-normal-server-release'
> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
> Parsing 1 properties into enum-like class for jdk.compiler
> Compiling 20 properties into resource bundles for jdk.compiler
> Compiling 5 properties into resource bundles for jdk.dev
> Compiling 10 properties into resource bundles for jdk.javadoc
> Compiling 822 files for BUILD_INTERIM_LANGTOOLS
> Creating buildtools/interim_langtools.jar
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> Warning: generation and use of skeletons and static stubs for JRMP
> is deprecated. Skeletons are unnecessary, and static stubs have
> been superseded by dynamically generated stubs. Users are
> encouraged to migrate away from using rmic to generate skeletons and static
> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
> Compiling 23 files for BUILD_INTERIM_JIMAGE
> Compiling 161 files for BUILD_TOOLS_JDK
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> Compiling 141 files for BUILD_IDLJ
> clang: error: argument unused during compilation: '-I .'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/prims'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/precompiled'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/cpu/x86/vm'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os_cpu/bsd_x86/vm'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/bsd/vm'
> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/posix/vm'
> clang: error: argument unused during compilation: '-I ../generated'
> clang: error: argument unused during compilation: '-include precompiled.hpp'
> make[10]: *** [abstractCompiler.o] Error 1
> make[9]: *** [the_vm] Error 2
> make[8]: *** [product] Error 2
> make[7]: *** [generic_build2] Error 2
> make[6]: *** [product] Error 2
> make[5]: *** [all_product_universal] Error 2
> make[4]: *** [universal_product] Error 2
> make[3]: *** [/Users/sandeepk/Workspace/JDK/jdk9-dev/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2
> make[2]: *** [hotspot] Error 2
> make[2]: *** Waiting for unfinished jobs....
> Compiling 6 files for BUILD_TOOLS_CORBA
> Note: /Users/sandeepk/Workspace/JDK/jdk9-dev/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java uses or overrides a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> make[1]: *** [main] Error 2
> make: *** [default] Error 2
>
> Thanks,
> Sandeep



From erik.joelsson at oracle.com  Thu Apr  2 07:43:34 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 02 Apr 2015 09:43:34 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
	to java.lang.management
In-Reply-To: <551C32D8.3020100@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551BA4B3.7010105@oracle.com>
	<551C32D8.3020100@oracle.com>
Message-ID: <551CF326.5010402@oracle.com>

Looks good, thanks!

/Erik

On 2015-04-01 20:03, shanliang wrote:
> Erik Joelsson wrote:
>> Hello,
>>
>> (Adding build-dev since this touches makefiles and jigsaw-dev since 
>> this touches modules.xml)
>>
>> In general, the build changes look pretty good. I much appreciate 
>> moving the OS specific source into OS specific source dirs. A few 
>> notes however. Though I realize you followed existing patterns, we 
>> have some more current best practices that I would like to 
>> incorporate in new code.
>>
>> jdk/make/lib/Lib-jdk.management.gmk:
>>
>> The variables BUILD_LIBJDKMANAGEMENT_SRC and 
>> BUILD_LIBJDKMANAGEMENT_CFLAGS should lose the "BUILD_" prefix. While 
>> it works, it makes them unnecessarily long and it risks conflicting 
>> with internal variables created in the SetupNativeCompilation call.
> Done.
>>
>> BUILD_LIBJDKMANAGEMENT_EXCLUDES is unused and should just be removed. 
>> The EXCLUDE_FILES parameter too.
> Done.
>>
>> LIBJDKMANAGEMENT_MAPFILE should be removed. This was a special 
>> construct for libmanagement used for a while until cmm was split into 
>> a separate module. Just inline the mapfile line into the macro call.
> Done.
>>
>>
>> jdk/make/lib/Lib-java.management.gmk:
>>
>> BUILD_LIBMANAGEMENT_EXCLUDES is unused here as well.
> Removed.
>>
>> LIBMANAGEMENT_MAPFILE should be inlined here as well.
> Done.
>>
>> While you are at it, might as well fix the BUILD_ prefix on the SRC 
>> and CFLAGS variables here too if you don't mind.
> Done.
>>
>>
>> Is the need for low optimization when debug symbols are active still 
>> valid for both libmanagement and libmanagement_ext?
> Sorry I do not know, I did not touch that flag stting in 
> libmanagement, and I copied it for libmanagement_ext.
>
> Here is the new version:
>    http://cr.openjdk.java.net/~sjiang/JDK-8042901/01/
>
> Thanks for the review.
> Shanliang
>
>>
>> /Erik
>>
>> On 2015-03-31 18:39, shanliang wrote:
>>> Please review this fix:
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
>>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>>>
>>> Some code within the module java.management is separated and moved 
>>> to the new module jdk.management, the new module takes the 
>>> implementation code for Oracle Corporation's platform extension to 
>>> the implementation of the java.lang.management API and also the 
>>> management interface for some other components for the platform.
>>>
>>> Thanks,
>>> Shanliang
>>>
>>
>



From erik.joelsson at oracle.com  Thu Apr  2 09:09:55 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 02 Apr 2015 11:09:55 +0200
Subject: RFR: JDK-8076531: Switch default compiler on Windows to VS2013
Message-ID: <551D0763.7030304@oracle.com>

Hello,

Please review this change which will make the official switch of the 
preferred compiler toolchain on Windows for JDK 9.

Changes are needed in:

* configure, for changing the default when multiple versions are available
* jprt.properties, for picking the right type of machine for Oracle 
internal building
* README-builds.html to make the documentation a little more correct in 
reflecting the current state of the build requirements

Note that README-builds certainly needs a lot more love, but this is not 
the time for correcting the rest of the mess. I'm only updating the 
numbers so that it's no longer blatantly wrong.

Bug: https://bugs.openjdk.java.net/browse/JDK-8076531
Webrev: http://cr.openjdk.java.net/~erikj/8076531/webrev.01/

/Erik




From magnus.ihse.bursie at oracle.com  Thu Apr  2 09:13:45 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 02 Apr 2015 11:13:45 +0200
Subject: RFR: JDK-8076531: Switch default compiler on Windows to VS2013
In-Reply-To: <551D0763.7030304@oracle.com>
References: <551D0763.7030304@oracle.com>
Message-ID: <551D0849.80901@oracle.com>

On 2015-04-02 11:09, Erik Joelsson wrote:
> Hello,
>
> Please review this change which will make the official switch of the 
> preferred compiler toolchain on Windows for JDK 9.
>
> Changes are needed in:
>
> * configure, for changing the default when multiple versions are 
> available
> * jprt.properties, for picking the right type of machine for Oracle 
> internal building
> * README-builds.html to make the documentation a little more correct 
> in reflecting the current state of the build requirements
>
> Note that README-builds certainly needs a lot more love, but this is 
> not the time for correcting the rest of the mess. I'm only updating 
> the numbers so that it's no longer blatantly wrong.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8076531
> Webrev: http://cr.openjdk.java.net/~erikj/8076531/webrev.01/

Looks good to me.

/Magnus


From volker.simonis at gmail.com  Thu Apr  2 09:22:25 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Thu, 2 Apr 2015 11:22:25 +0200
Subject: RFR: JDK-8076531: Switch default compiler on Windows to VS2013
In-Reply-To: <551D0763.7030304@oracle.com>
References: <551D0763.7030304@oracle.com>
Message-ID: <CA+3eh13-2RqWQVO=hHU3hiUF3W+48uDns24tGtMAS7GyNZRkvw@mail.gmail.com>

Hi Erik,

can you please also update
https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
once this change has been submitted and is in effect.

Thanks,
Volker


On Thu, Apr 2, 2015 at 11:09 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> Hello,
>
> Please review this change which will make the official switch of the
> preferred compiler toolchain on Windows for JDK 9.
>
> Changes are needed in:
>
> * configure, for changing the default when multiple versions are available
> * jprt.properties, for picking the right type of machine for Oracle internal
> building
> * README-builds.html to make the documentation a little more correct in
> reflecting the current state of the build requirements
>
> Note that README-builds certainly needs a lot more love, but this is not the
> time for correcting the rest of the mess. I'm only updating the numbers so
> that it's no longer blatantly wrong.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8076531
> Webrev: http://cr.openjdk.java.net/~erikj/8076531/webrev.01/
>
> /Erik
>
>


From erik.joelsson at oracle.com  Thu Apr  2 09:42:39 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 02 Apr 2015 11:42:39 +0200
Subject: RFR: JDK-8076531: Switch default compiler on Windows to VS2013
In-Reply-To: <CA+3eh13-2RqWQVO=hHU3hiUF3W+48uDns24tGtMAS7GyNZRkvw@mail.gmail.com>
References: <551D0763.7030304@oracle.com>
	<CA+3eh13-2RqWQVO=hHU3hiUF3W+48uDns24tGtMAS7GyNZRkvw@mail.gmail.com>
Message-ID: <551D0F0F.8000205@oracle.com>

Hello Volker,

Certainly, adding to todo list for next week when this is done. Thanks 
for the reminder.

/Erik

On 2015-04-02 11:22, Volker Simonis wrote:
> Hi Erik,
>
> can you please also update
> https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms
> once this change has been submitted and is in effect.
>
> Thanks,
> Volker
>
>
> On Thu, Apr 2, 2015 at 11:09 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> Hello,
>>
>> Please review this change which will make the official switch of the
>> preferred compiler toolchain on Windows for JDK 9.
>>
>> Changes are needed in:
>>
>> * configure, for changing the default when multiple versions are available
>> * jprt.properties, for picking the right type of machine for Oracle internal
>> building
>> * README-builds.html to make the documentation a little more correct in
>> reflecting the current state of the build requirements
>>
>> Note that README-builds certainly needs a lot more love, but this is not the
>> time for correcting the rest of the mess. I'm only updating the numbers so
>> that it's no longer blatantly wrong.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076531
>> Webrev: http://cr.openjdk.java.net/~erikj/8076531/webrev.01/
>>
>> /Erik
>>
>>



From sandeep.konchady at oracle.com  Thu Apr  2 12:28:11 2015
From: sandeep.konchady at oracle.com (Sandeep Konchady)
Date: Thu, 2 Apr 2015 05:28:11 -0700
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <551CF1F7.9010107@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
	<551CF1F7.9010107@oracle.com>
Message-ID: <C31D2890-5CD1-4ADB-9F4E-AE3FFB130D3D@oracle.com>

Thanks Erik and Magnus for your feedback. I will give it a try with ccache 3.2 and reply with my observation.

> At the very least we will need to warn/fail in configure when precompiled headers and ccache are used together with clang

This would be good.

- Sandeep

> On Apr 2, 2015, at 12:38 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> I haven't tried ccache since we introduced clang as the official toolchain for macosx. According to the ccache changelog, support for precompiled headers on clang was introduced in version 3.2, while you are using 3.1.6. I don't know if just switching version will make it work or if there is additional configuration needed for this configuration, but it would be good to know. At the very least we will need to warn/fail in configure when precompiled headers and ccache are used together with clang.
> 
> /Erik
> 
> On 2015-04-01 22:34, Sandeep Konchady wrote:
>> Hi,
>> 
>> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.
>> 
>> Darwin Kernel Version 14.1.0
>> 
>> using configure arguments '--enable-ccache'.
>> 
>> Configuration summary:
>> * Debug level:    release
>> * HS debug level: product
>> * JDK variant:    normal
>> * JVM variants:   server
>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>> 
>> Tools summary:
>> * Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
>> * Toolchain:      clang (clang/LLVM)
>> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
>> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)
>> 
>> Build performance summary:
>> * Cores to use:   2
>> * Memory limit:   8192 MB
>> * ccache status:  Active (3.1.6)
>> 
>> 
>> Error Log:
>> 
>> Creating data for first make execution in new configuration...
>> Done
>> Building target(s) 'default' in configuration 'macosx-x86_64-normal-server-release'
>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>> Parsing 1 properties into enum-like class for jdk.compiler
>> Compiling 20 properties into resource bundles for jdk.compiler
>> Compiling 5 properties into resource bundles for jdk.dev
>> Compiling 10 properties into resource bundles for jdk.javadoc
>> Compiling 822 files for BUILD_INTERIM_LANGTOOLS
>> Creating buildtools/interim_langtools.jar
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> Warning: generation and use of skeletons and static stubs for JRMP
>> is deprecated. Skeletons are unnecessary, and static stubs have
>> been superseded by dynamically generated stubs. Users are
>> encouraged to migrate away from using rmic to generate skeletons and static
>> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
>> Compiling 23 files for BUILD_INTERIM_JIMAGE
>> Compiling 161 files for BUILD_TOOLS_JDK
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> Compiling 141 files for BUILD_IDLJ
>> clang: error: argument unused during compilation: '-I .'
>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/prims'
>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm'
>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/precompiled'
>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/cpu/x86/vm'
>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os_cpu/bsd_x86/vm'
>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/bsd/vm'
>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/posix/vm'
>> clang: error: argument unused during compilation: '-I ../generated'
>> clang: error: argument unused during compilation: '-include precompiled.hpp'
>> make[10]: *** [abstractCompiler.o] Error 1
>> make[9]: *** [the_vm] Error 2
>> make[8]: *** [product] Error 2
>> make[7]: *** [generic_build2] Error 2
>> make[6]: *** [product] Error 2
>> make[5]: *** [all_product_universal] Error 2
>> make[4]: *** [universal_product] Error 2
>> make[3]: *** [/Users/sandeepk/Workspace/JDK/jdk9-dev/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2
>> make[2]: *** [hotspot] Error 2
>> make[2]: *** Waiting for unfinished jobs....
>> Compiling 6 files for BUILD_TOOLS_CORBA
>> Note: /Users/sandeepk/Workspace/JDK/jdk9-dev/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java uses or overrides a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> make[1]: *** [main] Error 2
>> make: *** [default] Error 2
>> 
>> Thanks,
>> Sandeep
> 



From erik.joelsson at oracle.com  Thu Apr  2 13:05:25 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 02 Apr 2015 15:05:25 +0200
Subject: RFR: JDK-8073634: Improve clean targets
Message-ID: <551D3E95.8030804@oracle.com>

Our top level clean targets need some improvement.

* There is no clean-docs
* dist-clean does not remove everything configure creates on all platforms

For the latter, moving a lot of the files generated by configure into a 
separate sub dir of the output dir helped. It's named configure-support 
as to mirror make-support. The difference between the two is who is 
responsible for the files inside them and thus which target will clean them.

I also made the clean targets work better with LOG=debug, so you can 
actually see the rm commands.

Bug: https://bugs.openjdk.java.net/browse/JDK-8073634
Webrev: http://cr.openjdk.java.net/~erikj/8073634/webrev.01/

/Erik


From erik.joelsson at oracle.com  Thu Apr  2 13:14:21 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 02 Apr 2015 15:14:21 +0200
Subject: Subject: RFR: JDK-8076465 New Init.gmk needs improvements
In-Reply-To: <551CF0EF.6040406@oracle.com>
References: <551CF0EF.6040406@oracle.com>
Message-ID: <551D40AD.40009@oracle.com>

Looks good to me.

/Erik

On 2015-04-02 09:34, Magnus Ihse Bursie wrote:
> It turned out that the new make bootstrapping file Init.gmk needed 
> some redesign.
>
> First of all, we should always respect the SPEC if possible, and not 
> chose a random configuration for extracting targets.
>
> Secondly, tab completion did not work in a non-standard configuration 
> directory. (This is slightly related to the problem above.)
>
> And third, there were still some code cleanup necessary.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8076465
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8076465-init-improvements/webrev.01
>
> /Magnus



From sandeep.konchady at oracle.com  Thu Apr  2 13:40:29 2015
From: sandeep.konchady at oracle.com (Sandeep Konchady)
Date: Thu, 2 Apr 2015 06:40:29 -0700
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <C31D2890-5CD1-4ADB-9F4E-AE3FFB130D3D@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
	<551CF1F7.9010107@oracle.com>
	<C31D2890-5CD1-4ADB-9F4E-AE3FFB130D3D@oracle.com>
Message-ID: <045E7A54-3351-4122-A69F-A52F7709D9FD@oracle.com>

I can confirm that after upgrade to ccache 3.2.x, build works just fine. Thanks for the tip.

Configure

====================================================
The existing configuration has been successfully updated in
using configure arguments '--enable-ccache --with-jtreg='~/Workspace/JDK/jtreg''.

Configuration summary:
* Debug level:    release
* HS debug level: product
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64

Tools summary:
* Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
* Toolchain:      clang (clang/LLVM)
* C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
* C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)

Build performance summary:
* Cores to use:   2
* Memory limit:   8192 MB
* ccache status:  Active (3.2.1) <<<< UPDATED CCACHE

Build

Copying images/jdk-bundle/jdk1.9.0.jdk/Contents/Home/THIRD_PARTY_README
Creating link images/jdk-bundle/jdk1.9.0.jdk/Contents/MacOS/libjli.dylib
Creating images/jdk-bundle/jdk1.9.0.jdk/Contents/Info.plist
Finished building target(s) 'clean all' in configuration 'macosx-x86_64-normal-server-release'

Thanks,
Sandeep

> On Apr 2, 2015, at 5:28 AM, Sandeep Konchady <sandeep.konchady at oracle.com> wrote:
> 
> Thanks Erik and Magnus for your feedback. I will give it a try with ccache 3.2 and reply with my observation.
> 
>> At the very least we will need to warn/fail in configure when precompiled headers and ccache are used together with clang
> 
> This would be good.
> 
> - Sandeep
> 
>> On Apr 2, 2015, at 12:38 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>> 
>> Hello,
>> 
>> I haven't tried ccache since we introduced clang as the official toolchain for macosx. According to the ccache changelog, support for precompiled headers on clang was introduced in version 3.2, while you are using 3.1.6. I don't know if just switching version will make it work or if there is additional configuration needed for this configuration, but it would be good to know. At the very least we will need to warn/fail in configure when precompiled headers and ccache are used together with clang.
>> 
>> /Erik
>> 
>> On 2015-04-01 22:34, Sandeep Konchady wrote:
>>> Hi,
>>> 
>>> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.
>>> 
>>> Darwin Kernel Version 14.1.0
>>> 
>>> using configure arguments '--enable-ccache'.
>>> 
>>> Configuration summary:
>>> * Debug level:    release
>>> * HS debug level: product
>>> * JDK variant:    normal
>>> * JVM variants:   server
>>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>>> 
>>> Tools summary:
>>> * Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
>>> * Toolchain:      clang (clang/LLVM)
>>> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
>>> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)
>>> 
>>> Build performance summary:
>>> * Cores to use:   2
>>> * Memory limit:   8192 MB
>>> * ccache status:  Active (3.1.6)
>>> 
>>> 
>>> Error Log:
>>> 
>>> Creating data for first make execution in new configuration...
>>> Done
>>> Building target(s) 'default' in configuration 'macosx-x86_64-normal-server-release'
>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>>> Parsing 1 properties into enum-like class for jdk.compiler
>>> Compiling 20 properties into resource bundles for jdk.compiler
>>> Compiling 5 properties into resource bundles for jdk.dev
>>> Compiling 10 properties into resource bundles for jdk.javadoc
>>> Compiling 822 files for BUILD_INTERIM_LANGTOOLS
>>> Creating buildtools/interim_langtools.jar
>>> Note: Some input files use unchecked or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> Warning: generation and use of skeletons and static stubs for JRMP
>>> is deprecated. Skeletons are unnecessary, and static stubs have
>>> been superseded by dynamically generated stubs. Users are
>>> encouraged to migrate away from using rmic to generate skeletons and static
>>> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
>>> Compiling 23 files for BUILD_INTERIM_JIMAGE
>>> Compiling 161 files for BUILD_TOOLS_JDK
>>> Note: Some input files use unchecked or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> Compiling 141 files for BUILD_IDLJ
>>> clang: error: argument unused during compilation: '-I .'
>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/prims'
>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm'
>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/precompiled'
>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/cpu/x86/vm'
>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os_cpu/bsd_x86/vm'
>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/bsd/vm'
>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/posix/vm'
>>> clang: error: argument unused during compilation: '-I ../generated'
>>> clang: error: argument unused during compilation: '-include precompiled.hpp'
>>> make[10]: *** [abstractCompiler.o] Error 1
>>> make[9]: *** [the_vm] Error 2
>>> make[8]: *** [product] Error 2
>>> make[7]: *** [generic_build2] Error 2
>>> make[6]: *** [product] Error 2
>>> make[5]: *** [all_product_universal] Error 2
>>> make[4]: *** [universal_product] Error 2
>>> make[3]: *** [/Users/sandeepk/Workspace/JDK/jdk9-dev/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2
>>> make[2]: *** [hotspot] Error 2
>>> make[2]: *** Waiting for unfinished jobs....
>>> Compiling 6 files for BUILD_TOOLS_CORBA
>>> Note: /Users/sandeepk/Workspace/JDK/jdk9-dev/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java uses or overrides a deprecated API.
>>> Note: Recompile with -Xlint:deprecation for details.
>>> Note: Some input files use unchecked or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> make[1]: *** [main] Error 2
>>> make: *** [default] Error 2
>>> 
>>> Thanks,
>>> Sandeep
>> 
> 



From erik.joelsson at oracle.com  Thu Apr  2 14:13:39 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 02 Apr 2015 16:13:39 +0200
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <045E7A54-3351-4122-A69F-A52F7709D9FD@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>	<551CF1F7.9010107@oracle.com>	<C31D2890-5CD1-4ADB-9F4E-AE3FFB130D3D@oracle.com>
	<045E7A54-3351-4122-A69F-A52F7709D9FD@oracle.com>
Message-ID: <551D4E93.1070500@oracle.com>

Thanks for the report. We should update configure to require 3.2 for 
clang then.

/Erik

On 2015-04-02 15:40, Sandeep Konchady wrote:
> I can confirm that after upgrade to ccache 3.2.x, build works just fine. Thanks for the tip.
>
> Configure
>
> ====================================================
> The existing configuration has been successfully updated in
> using configure arguments '--enable-ccache --with-jtreg='~/Workspace/JDK/jtreg''.
>
> Configuration summary:
> * Debug level:    release
> * HS debug level: product
> * JDK variant:    normal
> * JVM variants:   server
> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>
> Tools summary:
> * Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
> * Toolchain:      clang (clang/LLVM)
> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)
>
> Build performance summary:
> * Cores to use:   2
> * Memory limit:   8192 MB
> * ccache status:  Active (3.2.1) <<<< UPDATED CCACHE
>
> Build
>
> Copying images/jdk-bundle/jdk1.9.0.jdk/Contents/Home/THIRD_PARTY_README
> Creating link images/jdk-bundle/jdk1.9.0.jdk/Contents/MacOS/libjli.dylib
> Creating images/jdk-bundle/jdk1.9.0.jdk/Contents/Info.plist
> Finished building target(s) 'clean all' in configuration 'macosx-x86_64-normal-server-release'
>
> Thanks,
> Sandeep
>
>> On Apr 2, 2015, at 5:28 AM, Sandeep Konchady <sandeep.konchady at oracle.com> wrote:
>>
>> Thanks Erik and Magnus for your feedback. I will give it a try with ccache 3.2 and reply with my observation.
>>
>>> At the very least we will need to warn/fail in configure when precompiled headers and ccache are used together with clang
>> This would be good.
>>
>> - Sandeep
>>
>>> On Apr 2, 2015, at 12:38 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>
>>> Hello,
>>>
>>> I haven't tried ccache since we introduced clang as the official toolchain for macosx. According to the ccache changelog, support for precompiled headers on clang was introduced in version 3.2, while you are using 3.1.6. I don't know if just switching version will make it work or if there is additional configuration needed for this configuration, but it would be good to know. At the very least we will need to warn/fail in configure when precompiled headers and ccache are used together with clang.
>>>
>>> /Erik
>>>
>>> On 2015-04-01 22:34, Sandeep Konchady wrote:
>>>> Hi,
>>>>
>>>> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.
>>>>
>>>> Darwin Kernel Version 14.1.0
>>>>
>>>> using configure arguments '--enable-ccache'.
>>>>
>>>> Configuration summary:
>>>> * Debug level:    release
>>>> * HS debug level: product
>>>> * JDK variant:    normal
>>>> * JVM variants:   server
>>>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>>>>
>>>> Tools summary:
>>>> * Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
>>>> * Toolchain:      clang (clang/LLVM)
>>>> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
>>>> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)
>>>>
>>>> Build performance summary:
>>>> * Cores to use:   2
>>>> * Memory limit:   8192 MB
>>>> * ccache status:  Active (3.1.6)
>>>>
>>>>
>>>> Error Log:
>>>>
>>>> Creating data for first make execution in new configuration...
>>>> Done
>>>> Building target(s) 'default' in configuration 'macosx-x86_64-normal-server-release'
>>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>>>> Parsing 1 properties into enum-like class for jdk.compiler
>>>> Compiling 20 properties into resource bundles for jdk.compiler
>>>> Compiling 5 properties into resource bundles for jdk.dev
>>>> Compiling 10 properties into resource bundles for jdk.javadoc
>>>> Compiling 822 files for BUILD_INTERIM_LANGTOOLS
>>>> Creating buildtools/interim_langtools.jar
>>>> Note: Some input files use unchecked or unsafe operations.
>>>> Note: Recompile with -Xlint:unchecked for details.
>>>> Warning: generation and use of skeletons and static stubs for JRMP
>>>> is deprecated. Skeletons are unnecessary, and static stubs have
>>>> been superseded by dynamically generated stubs. Users are
>>>> encouraged to migrate away from using rmic to generate skeletons and static
>>>> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
>>>> Compiling 23 files for BUILD_INTERIM_JIMAGE
>>>> Compiling 161 files for BUILD_TOOLS_JDK
>>>> Note: Some input files use unchecked or unsafe operations.
>>>> Note: Recompile with -Xlint:unchecked for details.
>>>> Compiling 141 files for BUILD_IDLJ
>>>> clang: error: argument unused during compilation: '-I .'
>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/prims'
>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm'
>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/precompiled'
>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/cpu/x86/vm'
>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os_cpu/bsd_x86/vm'
>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/bsd/vm'
>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/posix/vm'
>>>> clang: error: argument unused during compilation: '-I ../generated'
>>>> clang: error: argument unused during compilation: '-include precompiled.hpp'
>>>> make[10]: *** [abstractCompiler.o] Error 1
>>>> make[9]: *** [the_vm] Error 2
>>>> make[8]: *** [product] Error 2
>>>> make[7]: *** [generic_build2] Error 2
>>>> make[6]: *** [product] Error 2
>>>> make[5]: *** [all_product_universal] Error 2
>>>> make[4]: *** [universal_product] Error 2
>>>> make[3]: *** [/Users/sandeepk/Workspace/JDK/jdk9-dev/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2
>>>> make[2]: *** [hotspot] Error 2
>>>> make[2]: *** Waiting for unfinished jobs....
>>>> Compiling 6 files for BUILD_TOOLS_CORBA
>>>> Note: /Users/sandeepk/Workspace/JDK/jdk9-dev/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java uses or overrides a deprecated API.
>>>> Note: Recompile with -Xlint:deprecation for details.
>>>> Note: Some input files use unchecked or unsafe operations.
>>>> Note: Recompile with -Xlint:unchecked for details.
>>>> make[1]: *** [main] Error 2
>>>> make: *** [default] Error 2
>>>>
>>>> Thanks,
>>>> Sandeep



From tim.bell at oracle.com  Thu Apr  2 15:13:16 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 02 Apr 2015 08:13:16 -0700
Subject: RFR: JDK-8073634: Improve clean targets
In-Reply-To: <551D3E95.8030804@oracle.com>
References: <551D3E95.8030804@oracle.com>
Message-ID: <551D5C8C.3060004@oracle.com>

Erik:

> Our top level clean targets need some improvement.
>
> * There is no clean-docs
> * dist-clean does not remove everything configure creates on all 
> platforms
>
> For the latter, moving a lot of the files generated by configure into 
> a separate sub dir of the output dir helped. It's named 
> configure-support as to mirror make-support. The difference between 
> the two is who is responsible for the files inside them and thus which 
> target will clean them.
>
> I also made the clean targets work better with LOG=debug, so you can 
> actually see the rm commands.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8073634
> Webrev: http://cr.openjdk.java.net/~erikj/8073634/webrev.01/

Very nice.  Looks good to me.

Tim



From tim.bell at oracle.com  Thu Apr  2 15:37:00 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 02 Apr 2015 08:37:00 -0700
Subject: Subject: RFR: JDK-8076465 New Init.gmk needs improvements
In-Reply-To: <551D40AD.40009@oracle.com>
References: <551CF0EF.6040406@oracle.com> <551D40AD.40009@oracle.com>
Message-ID: <551D621C.5060806@oracle.com>

Magnus

Looks good to me as well.

/Tim


On 04/02/15 06:14, Erik Joelsson wrote:
> Looks good to me.
>
> /Erik
>
> On 2015-04-02 09:34, Magnus Ihse Bursie wrote:
>> It turned out that the new make bootstrapping file Init.gmk needed 
>> some redesign.
>>
>> First of all, we should always respect the SPEC if possible, and not 
>> chose a random configuration for extracting targets.
>>
>> Secondly, tab completion did not work in a non-standard configuration 
>> directory. (This is slightly related to the problem above.)
>>
>> And third, there were still some code cleanup necessary.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076465
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8076465-init-improvements/webrev.01
>>
>> /Magnus
>



From tim.bell at oracle.com  Thu Apr  2 16:09:47 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 02 Apr 2015 09:09:47 -0700
Subject: RFR: JDK-8076531: Switch default compiler on Windows to VS2013
In-Reply-To: <551D0849.80901@oracle.com>
References: <551D0763.7030304@oracle.com> <551D0849.80901@oracle.com>
Message-ID: <551D69CB.2030207@oracle.com>

Hello Erik

On 04/02/15 02:13, Magnus Ihse Bursie wrote:
> On 2015-04-02 11:09, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this change which will make the official switch of the 
>> preferred compiler toolchain on Windows for JDK 9.
>>
>> Changes are needed in:
>>
>> * configure, for changing the default when multiple versions are 
>> available
>> * jprt.properties, for picking the right type of machine for Oracle 
>> internal building
>> * README-builds.html to make the documentation a little more correct 
>> in reflecting the current state of the build requirements
>>
>> Note that README-builds certainly needs a lot more love, but this is 
>> not the time for correcting the rest of the mess. I'm only updating 
>> the numbers so that it's no longer blatantly wrong.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076531
>> Webrev: http://cr.openjdk.java.net/~erikj/8076531/webrev.01/
>
> Looks good to me.
>
> /Magnus

Looks good to me as well.

/Tim



From sandeep.konchady at oracle.com  Thu Apr  2 16:30:49 2015
From: sandeep.konchady at oracle.com (Sandeep Konchady)
Date: Thu, 2 Apr 2015 09:30:49 -0700
Subject: Build issue on Mac 10.10.2 and Xcode 5.1
In-Reply-To: <551D4E93.1070500@oracle.com>
References: <861CB30D-EB6B-4F61-ACB2-3AB54A655CFD@oracle.com>
	<551CF1F7.9010107@oracle.com>
	<C31D2890-5CD1-4ADB-9F4E-AE3FFB130D3D@oracle.com>
	<045E7A54-3351-4122-A69F-A52F7709D9FD@oracle.com>
	<551D4E93.1070500@oracle.com>
Message-ID: <F6B2D0D6-3673-41B7-93E6-3F99816ED9D6@oracle.com>

Filed a bug which can be used to track this.

https://bugs.openjdk.java.net/browse/JDK-8076577

Thanks,
Sandeep


> On Apr 2, 2015, at 7:13 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Thanks for the report. We should update configure to require 3.2 for clang then.
> 
> /Erik
> 
> On 2015-04-02 15:40, Sandeep Konchady wrote:
>> I can confirm that after upgrade to ccache 3.2.x, build works just fine. Thanks for the tip.
>> 
>> Configure
>> 
>> ====================================================
>> The existing configuration has been successfully updated in
>> using configure arguments '--enable-ccache --with-jtreg='~/Workspace/JDK/jtreg''.
>> 
>> Configuration summary:
>> * Debug level:    release
>> * HS debug level: product
>> * JDK variant:    normal
>> * JVM variants:   server
>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>> 
>> Tools summary:
>> * Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
>> * Toolchain:      clang (clang/LLVM)
>> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
>> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)
>> 
>> Build performance summary:
>> * Cores to use:   2
>> * Memory limit:   8192 MB
>> * ccache status:  Active (3.2.1) <<<< UPDATED CCACHE
>> 
>> Build
>> 
>> Copying images/jdk-bundle/jdk1.9.0.jdk/Contents/Home/THIRD_PARTY_README
>> Creating link images/jdk-bundle/jdk1.9.0.jdk/Contents/MacOS/libjli.dylib
>> Creating images/jdk-bundle/jdk1.9.0.jdk/Contents/Info.plist
>> Finished building target(s) 'clean all' in configuration 'macosx-x86_64-normal-server-release'
>> 
>> Thanks,
>> Sandeep
>> 
>>> On Apr 2, 2015, at 5:28 AM, Sandeep Konchady <sandeep.konchady at oracle.com> wrote:
>>> 
>>> Thanks Erik and Magnus for your feedback. I will give it a try with ccache 3.2 and reply with my observation.
>>> 
>>>> At the very least we will need to warn/fail in configure when precompiled headers and ccache are used together with clang
>>> This would be good.
>>> 
>>> - Sandeep
>>> 
>>>> On Apr 2, 2015, at 12:38 AM, Erik Joelsson <erik.joelsson at oracle.com> wrote:
>>>> 
>>>> Hello,
>>>> 
>>>> I haven't tried ccache since we introduced clang as the official toolchain for macosx. According to the ccache changelog, support for precompiled headers on clang was introduced in version 3.2, while you are using 3.1.6. I don't know if just switching version will make it work or if there is additional configuration needed for this configuration, but it would be good to know. At the very least we will need to warn/fail in configure when precompiled headers and ccache are used together with clang.
>>>> 
>>>> /Erik
>>>> 
>>>> On 2015-04-01 22:34, Sandeep Konchady wrote:
>>>>> Hi,
>>>>> 
>>>>> I am trying to build OpenJDK only on my MBP with OS X 10.10.2 and Xcode 5.1. Log from configure and build error attached. Any help would be much appreciated.
>>>>> 
>>>>> Darwin Kernel Version 14.1.0
>>>>> 
>>>>> using configure arguments '--enable-ccache'.
>>>>> 
>>>>> Configuration summary:
>>>>> * Debug level:    release
>>>>> * HS debug level: product
>>>>> * JDK variant:    normal
>>>>> * JVM variants:   server
>>>>> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64
>>>>> 
>>>>> Tools summary:
>>>>> * Boot JDK:       java version "1.8.0_40" Java(TM) SE Runtime Environment (build 1.8.0_40-b25) Java HotSpot(TM) 64-Bit Server VM (build 25.40-b25, mixed mode)  (at /Library/Java/JavaVirtualMachines/jdk1.8.0_40.jdk/Contents/Home)
>>>>> * Toolchain:      clang (clang/LLVM)
>>>>> * C Compiler:     Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang)
>>>>> * C++ Compiler:   Version Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at /usr/bin/clang++)
>>>>> 
>>>>> Build performance summary:
>>>>> * Cores to use:   2
>>>>> * Memory limit:   8192 MB
>>>>> * ccache status:  Active (3.1.6)
>>>>> 
>>>>> 
>>>>> Error Log:
>>>>> 
>>>>> Creating data for first make execution in new configuration...
>>>>> Done
>>>>> Building target(s) 'default' in configuration 'macosx-x86_64-normal-server-release'
>>>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS
>>>>> Parsing 1 properties into enum-like class for jdk.compiler
>>>>> Compiling 20 properties into resource bundles for jdk.compiler
>>>>> Compiling 5 properties into resource bundles for jdk.dev
>>>>> Compiling 10 properties into resource bundles for jdk.javadoc
>>>>> Compiling 822 files for BUILD_INTERIM_LANGTOOLS
>>>>> Creating buildtools/interim_langtools.jar
>>>>> Note: Some input files use unchecked or unsafe operations.
>>>>> Note: Recompile with -Xlint:unchecked for details.
>>>>> Warning: generation and use of skeletons and static stubs for JRMP
>>>>> is deprecated. Skeletons are unnecessary, and static stubs have
>>>>> been superseded by dynamically generated stubs. Users are
>>>>> encouraged to migrate away from using rmic to generate skeletons and static
>>>>> stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
>>>>> Compiling 23 files for BUILD_INTERIM_JIMAGE
>>>>> Compiling 161 files for BUILD_TOOLS_JDK
>>>>> Note: Some input files use unchecked or unsafe operations.
>>>>> Note: Recompile with -Xlint:unchecked for details.
>>>>> Compiling 141 files for BUILD_IDLJ
>>>>> clang: error: argument unused during compilation: '-I .'
>>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/prims'
>>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm'
>>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/share/vm/precompiled'
>>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/cpu/x86/vm'
>>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os_cpu/bsd_x86/vm'
>>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/bsd/vm'
>>>>> clang: error: argument unused during compilation: '-I ../../../../../hotspot/src/os/posix/vm'
>>>>> clang: error: argument unused during compilation: '-I ../generated'
>>>>> clang: error: argument unused during compilation: '-include precompiled.hpp'
>>>>> make[10]: *** [abstractCompiler.o] Error 1
>>>>> make[9]: *** [the_vm] Error 2
>>>>> make[8]: *** [product] Error 2
>>>>> make[7]: *** [generic_build2] Error 2
>>>>> make[6]: *** [product] Error 2
>>>>> make[5]: *** [all_product_universal] Error 2
>>>>> make[4]: *** [universal_product] Error 2
>>>>> make[3]: *** [/Users/sandeepk/Workspace/JDK/jdk9-dev/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2
>>>>> make[2]: *** [hotspot] Error 2
>>>>> make[2]: *** Waiting for unfinished jobs....
>>>>> Compiling 6 files for BUILD_TOOLS_CORBA
>>>>> Note: /Users/sandeepk/Workspace/JDK/jdk9-dev/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java uses or overrides a deprecated API.
>>>>> Note: Recompile with -Xlint:deprecation for details.
>>>>> Note: Some input files use unchecked or unsafe operations.
>>>>> Note: Recompile with -Xlint:unchecked for details.
>>>>> make[1]: *** [main] Error 2
>>>>> make: *** [default] Error 2
>>>>> 
>>>>> Thanks,
>>>>> Sandeep
> 



From jon.masamitsu at oracle.com  Thu Apr  2 16:48:05 2015
From: jon.masamitsu at oracle.com (Jon Masamitsu)
Date: Thu, 02 Apr 2015 09:48:05 -0700
Subject: Fwd: We REALLY nead a NON-PCH build in JPRT NOW!
In-Reply-To: <CA+3eh10CVuAxfm1udE8cskycaUcuxk92u3OBdbMQw7qMAz=7OA@mail.gmail.com>
References: <CA+3eh10CVuAxfm1udE8cskycaUcuxk92u3OBdbMQw7qMAz=7OA@mail.gmail.com>
Message-ID: <551D72C5.3010904@oracle.com>




-------- Forwarded Message --------
Subject: 	We REALLY nead a NON-PCH build in JPRT NOW!
Date: 	Thu, 2 Apr 2015 18:06:01 +0200
From: 	Volker Simonis <volker.simonis at gmail.com>
To: 	HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>



Hi,

while precompiled headers (PCH) are a nice and effective way of
improving hotspot build times this feature also drastically increases
the risk of introducing missing dependencies into the source base.
This is especially annoying on platforms where precompield headers
aren't available at all.

In the last two weeks we had two cases [1,2] of such missing
dependencies which haven't been caught by JPRT because JPRT uses the
default platform settings and thus always uses PCHs on all platforms
where they are supported.

I want to strongly advocate for a change in the JPRT configurations
such that at least on one Windows and one Linux platform the automatic
pre-integration builds are done with
"--with-debug-level=[slow/fast]debug --disable-precompiled-headers".
This simple change which comes at the minor cost of a few CPU-cycles
will save a big amount of (hopfully) much more precious developer
cycles and at the same time considerably improve the code quality.
Notice that I intentionally ask for a *debug build without PCHs
because debug builds exercise much more source code and are
specifically prone to missing include dependency errors.

As this change can only be decided upon and implemented inside Oracle
I hereby kindly ask for an appropriate sponsor.

Thank you and best regards,
Volker

[1]
Introduced by: https://bugs.openjdk.java.net/browse/JDK-8075416
Fixed by: https://bugs.openjdk.java.net/browse/JDK-8075735

[2]
Introduced by: https://bugs.openjdk.java.net/browse/JDK-8076314
Fix proposed: http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-April/012659.html





From philip.race at oracle.com  Thu Apr  2 17:04:45 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 02 Apr 2015 10:04:45 -0700
Subject: RFR: JDK-8076531: Switch default compiler on Windows to VS2013
In-Reply-To: <551D0763.7030304@oracle.com>
References: <551D0763.7030304@oracle.com>
Message-ID: <551D76AD.7040700@oracle.com>

I am a bit surprised to note we'd prefer 2012 over 2010.
.. and that we'd been preferring it over 2013. Seems odd to have a version
that was never the 'official' compiler be preferred over offical versions.
It won't affect me as I don't  have 2012 but might affect someone else.
So if someone has just 2010 and 2012 installed, can I assume the build
is 'known to work' ?

Other than that question, "+1".

-phil.

On 4/2/2015 2:09 AM, Erik Joelsson wrote:
> Hello,
>
> Please review this change which will make the official switch of the 
> preferred compiler toolchain on Windows for JDK 9.
>
> Changes are needed in:
>
> * configure, for changing the default when multiple versions are 
> available
> * jprt.properties, for picking the right type of machine for Oracle 
> internal building
> * README-builds.html to make the documentation a little more correct 
> in reflecting the current state of the build requirements
>
> Note that README-builds certainly needs a lot more love, but this is 
> not the time for correcting the rest of the mess. I'm only updating 
> the numbers so that it's no longer blatantly wrong.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8076531
> Webrev: http://cr.openjdk.java.net/~erikj/8076531/webrev.01/
>
> /Erik
>
>



From tim.bell at oracle.com  Thu Apr  2 17:28:22 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 02 Apr 2015 10:28:22 -0700
Subject: Fwd: We REALLY nead a NON-PCH build in JPRT NOW!
In-Reply-To: <551D72C5.3010904@oracle.com>
References: <CA+3eh10CVuAxfm1udE8cskycaUcuxk92u3OBdbMQw7qMAz=7OA@mail.gmail.com>
	<551D72C5.3010904@oracle.com>
Message-ID: <551D7C36.7000903@oracle.com>

Thanks, Jon and Volker

I filed a new bug report to track this issue:

   JDK-8076581 - Need a NON-PCH build to quickly detect missing 
dependencies in the source base has been successfully created.

   https://bugs.openjdk.java.net/browse/JDK-8076581

Tim

On 04/02/15 09:48, Jon Masamitsu wrote:
>
>
>
> -------- Forwarded Message --------
> Subject:     We REALLY nead a NON-PCH build in JPRT NOW!
> Date:     Thu, 2 Apr 2015 18:06:01 +0200
> From:     Volker Simonis <volker.simonis at gmail.com>
> To:     HotSpot Open Source Developers <hotspot-dev at openjdk.java.net>
>
>
>
> Hi,
>
> while precompiled headers (PCH) are a nice and effective way of
> improving hotspot build times this feature also drastically increases
> the risk of introducing missing dependencies into the source base.
> This is especially annoying on platforms where precompield headers
> aren't available at all.
>
> In the last two weeks we had two cases [1,2] of such missing
> dependencies which haven't been caught by JPRT because JPRT uses the
> default platform settings and thus always uses PCHs on all platforms
> where they are supported.
>
> I want to strongly advocate for a change in the JPRT configurations
> such that at least on one Windows and one Linux platform the automatic
> pre-integration builds are done with
> "--with-debug-level=[slow/fast]debug --disable-precompiled-headers".
> This simple change which comes at the minor cost of a few CPU-cycles
> will save a big amount of (hopfully) much more precious developer
> cycles and at the same time considerably improve the code quality.
> Notice that I intentionally ask for a *debug build without PCHs
> because debug builds exercise much more source code and are
> specifically prone to missing include dependency errors.
>
> As this change can only be decided upon and implemented inside Oracle
> I hereby kindly ask for an appropriate sponsor.
>
> Thank you and best regards,
> Volker
>
> [1]
> Introduced by: https://bugs.openjdk.java.net/browse/JDK-8075416
> Fixed by: https://bugs.openjdk.java.net/browse/JDK-8075735
>
> [2]
> Introduced by: https://bugs.openjdk.java.net/browse/JDK-8076314
> Fix proposed: 
> http://mail.openjdk.java.net/pipermail/hotspot-gc-dev/2015-April/012659.html
>
>
>



From shanliang.jiang at oracle.com  Thu Apr  2 19:58:14 2015
From: shanliang.jiang at oracle.com (Shanliang Jiang)
Date: Thu, 02 Apr 2015 21:58:14 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
	to java.lang.management
In-Reply-To: <551C6622.1020609@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551C6622.1020609@oracle.com>
Message-ID: <551D9F56.4050201@oracle.com>

Hi,

I have to ask the review again because I need to modify:
    langtools/src/jdk.dev/share/classes/com/sun/tools/jdeps/Profile.java

The issue was found when langtools tests were added into my test list.

The new version is:
    http://cr.openjdk.java.net/~sjiang/JDK-8042901/02/

which integrated also the Mandy's comments in the following mail.

Thanks,
Shanliang

Mandy Chung wrote:
> On 3/31/2015 9:39 AM, shanliang wrote:
>> Please review this fix:
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8042901
>> Webrev: http://cr.openjdk.java.net/~sjiang/JDK-8042901/00/
>
> Thank you for doing this big change to separate com.sun.management
> API from java.management module.   Looking really good.
>
> Also thanks for fixing the tests to eliminate the unnecessary use of
> JDK internal APIs.
>
> modules.xml change looks good to me.
>
> sun/management/ThreadImpl.java
>   35 /**
>   36  * Implementation class for the thread subsystem.
>   37  * Standard and committed hotspot-specific metrics if any.
>   38  *
>   39  * ManagementFactory.getThreadMXBean() returns an instance
>   40  * of this class.
>   41  */
>   42 // the implementation for com.sun.management.ThreadMXBean can
>   43 // be moved to jdk.management in the future.
>
> What about:
>   Implementation for java.lang.management.ThreadMXBean as well as
>   providing the supporting method for com.sun.management.ThreadMXBean.
>     The supporting method for com.sun.management.ThreadMXBean can
>   be moved to jdk.management in the future.
>
> CheckSomeMXBeanImplPackage.java
>    Thanks for adding this test.
>
>    Iterating jrt file system to find jdk.management module is one way.
>    Another simpler alternative is to call:
>      Class.forName("com.sun.management.GarbageCollectorMXBean");
>    and catch CNFE to determine if it's present or not.
>
>    You should also call ManagementFactory.getPlatformMXBeans on
>    com.sun.management.GarbageCollectorMXBean if present.
>
> VMOptionOpenDataTest.java
>    copyright header year is wrong.
>
> PlatformMBeanProviderConstructorCheck.java
>    The test needs to restore the original policy and security manager
>    before the test exits in case this case runs in agent vm mode.
>    The static permName and accepted variables are more appropriate
>    in MyPolicy class.  Perhaps rename "accepted" to an instance
>    "denied" or "allowed" variable of MyPolicy class to reflect
>    what it intends to mean.
>
> I'm okay if you make the change before the push.  No need for a new
> webrev.
>
> Mandy
>



From mandy.chung at oracle.com  Thu Apr  2 20:09:08 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Thu, 02 Apr 2015 13:09:08 -0700
Subject: RFR 8042901: Allow com.sun.management to be in a different module
	to java.lang.management
In-Reply-To: <551D9F56.4050201@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551C6622.1020609@oracle.com>
	<551D9F56.4050201@oracle.com>
Message-ID: <551DA1E4.6070709@oracle.com>

On 4/2/15 12:58 PM, Shanliang Jiang wrote:
> Hi,
>
> I have to ask the review again because I need to modify:
> langtools/src/jdk.dev/share/classes/com/sun/tools/jdeps/Profile.java
>
> The issue was found when langtools tests were added into my test list.
>
> The new version is:
>    http://cr.openjdk.java.net/~sjiang/JDK-8042901/02/
>

Thanks for catching the jdeps change.  Profile.java change looks okay 
and this list is temporary.  jdeps will be updated to determine the 
exported APIs at runtime when the module system is moving along.

> which integrated also the Mandy's comments in the following mail.
>
CheckSomeMXBeanImplPackage.java
   line 45-50 & 58-60: should be called unconditionally since they
   should pass if java.management is present.

Okay to push once the test is updated.

Mandy



From jonathan.gibbons at oracle.com  Thu Apr  2 23:52:04 2015
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Thu, 02 Apr 2015 16:52:04 -0700
Subject: RFR:  JDK-8076583: move jdk.Exported from langtools to jdk
Message-ID: <551DD624.4060701@oracle.com>

Sorry for the relatively wide distribution.

JDK-8076583 is a conceptually simple cleanup, to move the source file 
for the jdk.Exported class from the langtools repo (where it is a 
singleton outlier) to the jdk repo (alongside most of the rest of the 
classes in the jdk package hierarchy). The class was originally placed 
in the langtools repo for bootstrapping reasons that no longer apply.

As a result of moving the source file, references to java.base in a 
number of places in the langtools repo can be cleaned up.

@Build folk:
There is a trivial change to a makefile in the langtools repo.

@Core-libs folk:
The source file gets moved into the jdk/ repo.

@Compiler-dev folk:
We can remove references to the java.base folder from the private Ant 
build, and from IDE support files.

JBS: https://bugs.openjdk.java.net/browse/JDK-8076583
Webrev: http://cr.openjdk.java.net/~jjg/8076583/webrev.00/

-- Jon


From joe.darcy at oracle.com  Fri Apr  3 01:27:58 2015
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 02 Apr 2015 18:27:58 -0700
Subject: RFR:  JDK-8076583: move jdk.Exported from langtools to jdk
In-Reply-To: <551DD624.4060701@oracle.com>
References: <551DD624.4060701@oracle.com>
Message-ID: <551DEC9E.3050906@oracle.com>

Jon,

The actual file move looks fine to me.

Thanks,

-Joe

On 4/2/2015 4:52 PM, Jonathan Gibbons wrote:
> Sorry for the relatively wide distribution.
>
> JDK-8076583 is a conceptually simple cleanup, to move the source file 
> for the jdk.Exported class from the langtools repo (where it is a 
> singleton outlier) to the jdk repo (alongside most of the rest of the 
> classes in the jdk package hierarchy). The class was originally placed 
> in the langtools repo for bootstrapping reasons that no longer apply.
>
> As a result of moving the source file, references to java.base in a 
> number of places in the langtools repo can be cleaned up.
>
> @Build folk:
> There is a trivial change to a makefile in the langtools repo.
>
> @Core-libs folk:
> The source file gets moved into the jdk/ repo.
>
> @Compiler-dev folk:
> We can remove references to the java.base folder from the private Ant 
> build, and from IDE support files.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8076583
> Webrev: http://cr.openjdk.java.net/~jjg/8076583/webrev.00/
>
> -- Jon



From Alan.Bateman at oracle.com  Fri Apr  3 06:47:34 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 03 Apr 2015 07:47:34 +0100
Subject: RFR:  JDK-8076583: move jdk.Exported from langtools to jdk
In-Reply-To: <551DD624.4060701@oracle.com>
References: <551DD624.4060701@oracle.com>
Message-ID: <551E3786.9090005@oracle.com>

On 03/04/2015 00:52, Jonathan Gibbons wrote:
> Sorry for the relatively wide distribution.
>
> JDK-8076583 is a conceptually simple cleanup, to move the source file 
> for the jdk.Exported class from the langtools repo (where it is a 
> singleton outlier) to the jdk repo (alongside most of the rest of the 
> classes in the jdk package hierarchy). The class was originally placed 
> in the langtools repo for bootstrapping reasons that no longer apply.
>
> As a result of moving the source file, references to java.base in a 
> number of places in the langtools repo can be cleaned up.
>
> @Build folk:
> There is a trivial change to a makefile in the langtools repo.
>
> @Core-libs folk:
> The source file gets moved into the jdk/ repo.
The move looks okay although the new home might be temporary given the 
design principles in JEP 200 (meaning java.base should not export the 
jdk API package).

-Alan


From shanliang.jiang at oracle.com  Fri Apr  3 07:30:52 2015
From: shanliang.jiang at oracle.com (Shanliang Jiang)
Date: Fri, 03 Apr 2015 09:30:52 +0200
Subject: RFR 8042901: Allow com.sun.management to be in a different module
	to java.lang.management
In-Reply-To: <551DA1E4.6070709@oracle.com>
References: <551ACDBD.6000703@oracle.com> <551C6622.1020609@oracle.com>
	<551D9F56.4050201@oracle.com> <551DA1E4.6070709@oracle.com>
Message-ID: <551E41AC.6000407@oracle.com>

Mandy Chung wrote:
> CheckSomeMXBeanImplPackage.java
>   line 45-50 & 58-60: should be called unconditionally since they
>   should pass if java.management is present.
The method "check" checks that an MBean implementation must be from 
"com.sun.management.internal", so even we look for an MXBean with its 
standard MXBean class (java.lang.management.*), do "check" still needs 
jdk.management module to be present.

We need more unit tests for the case when jdk.management is absent.

Thanks,
Shanliang



From mandy.chung at oracle.com  Fri Apr  3 14:47:49 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 03 Apr 2015 07:47:49 -0700
Subject: RFR:  JDK-8076583: move jdk.Exported from langtools to jdk
In-Reply-To: <551DD624.4060701@oracle.com>
References: <551DD624.4060701@oracle.com>
Message-ID: <551EA815.4010408@oracle.com>

On 4/2/2015 4:52 PM, Jonathan Gibbons wrote:
> Sorry for the relatively wide distribution.
>
> JDK-8076583 is a conceptually simple cleanup, to move the source file 
> for the jdk.Exported class from the langtools repo (where it is a 
> singleton outlier) to the jdk repo (alongside most of the rest of the 
> classes in the jdk package hierarchy). The class was originally placed 
> in the langtools repo for bootstrapping reasons that no longer apply.
>
> As a result of moving the source file, references to java.base in a 
> number of places in the langtools repo can be cleaned up.
>
> @Build folk:
> There is a trivial change to a makefile in the langtools repo.
>
> @Core-libs folk:
> The source file gets moved into the jdk/ repo.
>
> @Compiler-dev folk:
> We can remove references to the java.base folder from the private Ant 
> build, and from IDE support files.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8076583
> Webrev: http://cr.openjdk.java.net/~jjg/8076583/webrev.00/

Moving jdk.Exported to jdk repo is fine.

Mandy


From jan.lahoda at oracle.com  Fri Apr  3 17:34:17 2015
From: jan.lahoda at oracle.com (Jan Lahoda)
Date: Fri, 03 Apr 2015 19:34:17 +0200
Subject: RFR:  JDK-8076583: move jdk.Exported from langtools to jdk
In-Reply-To: <551DD624.4060701@oracle.com>
References: <551DD624.4060701@oracle.com>
Message-ID: <551ECF19.70305@oracle.com>

On 3.4.2015 01:52, Jonathan Gibbons wrote:
> Sorry for the relatively wide distribution.
>
> JDK-8076583 is a conceptually simple cleanup, to move the source file
> for the jdk.Exported class from the langtools repo (where it is a
> singleton outlier) to the jdk repo (alongside most of the rest of the
> classes in the jdk package hierarchy). The class was originally placed
> in the langtools repo for bootstrapping reasons that no longer apply.
>
> As a result of moving the source file, references to java.base in a
> number of places in the langtools repo can be cleaned up.
>
> @Build folk:
> There is a trivial change to a makefile in the langtools repo.
>
> @Core-libs folk:
> The source file gets moved into the jdk/ repo.
>
> @Compiler-dev folk:
> We can remove references to the java.base folder from the private Ant
> build, and from IDE support files.

These changes seem fine to me. I am not that big expert on the IntelliJ 
support, though.

Jan

>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8076583
> Webrev: http://cr.openjdk.java.net/~jjg/8076583/webrev.00/
>
> -- Jon


From tim.bell at oracle.com  Fri Apr  3 20:14:43 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Fri, 03 Apr 2015 13:14:43 -0700
Subject: RFR:  JDK-8076583: move jdk.Exported from langtools to jdk
In-Reply-To: <551DD624.4060701@oracle.com>
References: <551DD624.4060701@oracle.com>
Message-ID: <551EF4B3.6080904@oracle.com>

> @Build folk:
> There is a trivial change to a makefile in the langtools repo.

Looks good to me.

Tim


On 04/02/15 16:52, Jonathan Gibbons wrote:
> Sorry for the relatively wide distribution.
>
> JDK-8076583 is a conceptually simple cleanup, to move the source file 
> for the jdk.Exported class from the langtools repo (where it is a 
> singleton outlier) to the jdk repo (alongside most of the rest of the 
> classes in the jdk package hierarchy). The class was originally placed 
> in the langtools repo for bootstrapping reasons that no longer apply.
>
> As a result of moving the source file, references to java.base in a 
> number of places in the langtools repo can be cleaned up.
>
> @Build folk:
> There is a trivial change to a makefile in the langtools repo.
>
> @Core-libs folk:
> The source file gets moved into the jdk/ repo.
>
> @Compiler-dev folk:
> We can remove references to the java.base folder from the private Ant 
> build, and from IDE support files.
>
> JBS: https://bugs.openjdk.java.net/browse/JDK-8076583
> Webrev: http://cr.openjdk.java.net/~jjg/8076583/webrev.00/
>
> -- Jon



From erik.joelsson at oracle.com  Tue Apr  7 08:12:02 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 07 Apr 2015 10:12:02 +0200
Subject: RFR: JDK-8076531: Switch default compiler on Windows to VS2013
In-Reply-To: <551D76AD.7040700@oracle.com>
References: <551D0763.7030304@oracle.com> <551D76AD.7040700@oracle.com>
Message-ID: <55239152.6040000@oracle.com>

Hello,

That's a fair point. We did aim for 2012 when trying to do this work for 
JDK 8, but it hasn't been tried (at least not that I know) for a while 
now. I agree that perhaps 2010 should be prioritized before 2012 since 
it has been an official compiler. On the other hand, 2012 is much closer 
to 2013 in functionality so it's more likely to continue working for 
longer. In any case, the user can choose between them using 
--with-toolchain-version=2010.

/Erik

On 2015-04-02 19:04, Phil Race wrote:
> I am a bit surprised to note we'd prefer 2012 over 2010.
> .. and that we'd been preferring it over 2013. Seems odd to have a 
> version
> that was never the 'official' compiler be preferred over offical 
> versions.
> It won't affect me as I don't  have 2012 but might affect someone else.
> So if someone has just 2010 and 2012 installed, can I assume the build
> is 'known to work' ?
>
> Other than that question, "+1".
>
> -phil.
>
> On 4/2/2015 2:09 AM, Erik Joelsson wrote:
>> Hello,
>>
>> Please review this change which will make the official switch of the 
>> preferred compiler toolchain on Windows for JDK 9.
>>
>> Changes are needed in:
>>
>> * configure, for changing the default when multiple versions are 
>> available
>> * jprt.properties, for picking the right type of machine for Oracle 
>> internal building
>> * README-builds.html to make the documentation a little more correct 
>> in reflecting the current state of the build requirements
>>
>> Note that README-builds certainly needs a lot more love, but this is 
>> not the time for correcting the rest of the mess. I'm only updating 
>> the numbers so that it's no longer blatantly wrong.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076531
>> Webrev: http://cr.openjdk.java.net/~erikj/8076531/webrev.01/
>>
>> /Erik
>>
>>
>



From magnus.ihse.bursie at oracle.com  Tue Apr  7 11:26:00 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 07 Apr 2015 13:26:00 +0200
Subject: RFR: JDK-8073634: Improve clean targets
In-Reply-To: <551D3E95.8030804@oracle.com>
References: <551D3E95.8030804@oracle.com>
Message-ID: <5523BEC8.3060902@oracle.com>

On 2015-04-02 15:05, Erik Joelsson wrote:
> Our top level clean targets need some improvement.
>
> * There is no clean-docs
> * dist-clean does not remove everything configure creates on all 
> platforms
>
> For the latter, moving a lot of the files generated by configure into 
> a separate sub dir of the output dir helped. It's named 
> configure-support as to mirror make-support. The difference between 
> the two is who is responsible for the files inside them and thus which 
> target will clean them.
>
> I also made the clean targets work better with LOG=debug, so you can 
> actually see the rm commands.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8073634
> Webrev: http://cr.openjdk.java.net/~erikj/8073634/webrev.01/

In general it looks good. I have a couple of remarks, though.

1) In Clean-docs, you do:
+        $(RM) -r $(SUPPORT_OUTPUTDIR)/docs
+        $(RM) -r $(IMAGES_OUTPUTDIR)/docs

I'm not quite certain cleaning images/docs the right thing to do. For 
all other clean targets, we only clean the support part. If we want to 
clean images, we run clean-images. And if you think this is the right 
thing to do for images, wouldn't it then also be the right thing for 
e.g. java.base-native? And then things quickly become complicated.

2) The new configure-support, as well as the rather new make-support 
seems to be a bit unfairly treated. There is a MAKESUPPORT_OUTPUTDIR in 
spec.gmk but it's hardcoded there, so you can't use it in configure, 
e.g. in your changes in build-performance.m4. The new configure-support 
does not even have a corresponding CONFIGURESUPPORT_OUTPUTDIR in the 
spec.gmk. Instead, it has a variable CONFIGURE_SUPPORT that is present 
only in the configure files.

I'm not sure how much, if anything, of these inconsistencies that should 
be fixed now. But I'd suggest that you rename CONFIGURE_SUPPORT to 
CONFIGURESUPPORT_OUTPUTDIR at the very least. (Or, maybe, 
MAKESUPPORT_OUTPUTDIR should be MAKE_SUPPORT_OUTPUTDIR.)

/Magnus


From peter.brunet at oracle.com  Tue Apr  7 12:56:19 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 07 Apr 2015 07:56:19 -0500
Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for Maveriks
	10.9.5
In-Reply-To: <552377C1.7020305@oracle.com>
References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com>
	<55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com>
	<552377C1.7020305@oracle.com>
Message-ID: <5523D3F3.40309@oracle.com>

Hi, I need some help so I can build on MacOSX to fix a build break.

First since I had Xcode 6.1.1 and configure complained that I didn't
have v4 I installed v4.6.3.  After installing 4.6.3 and doing
sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/
I got past that.  Then for some reason my compile environment is now
bad.  I get

...
configure:20476: checking for C compiler version
configure:20485: /usr/bin/gcc --version >&5
i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
5658) (LLVM build 2336.11.00)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

configure:20496: $? = 0
configure:20485: /usr/bin/gcc -v >&5
Using built-in specs.
Target: i686-apple-darwin11
Configured with:
/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure
--disable-checking --enable-werror
--prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2
--mandir=/share/man --enable-languages=c,objc,c++,obj-c++
--program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
--with-slibdir=/usr/lib --build=i686-apple-darwin11
--enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local
--program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
--target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
configure:20496: $? = 0
configure:20485: /usr/bin/gcc -V >&5
llvm-gcc-4.2: argument to `-V' is missing
configure:20496: $? = 1
configure:20485: /usr/bin/gcc -qversion >&5
i686-apple-darwin11-llvm-gcc-4.2: no input files
configure:20496: $? = 1
configure:20516: checking whether the C compiler works
configure:20538: /usr/bin/gcc    conftest.c  >&5
ld: library not found for -lcrt1.10.6.o
collect2: ld returned 1 exit status
...

Trying find from the root:
find . -name crt1\*

...
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o
./Applications/Xcode
4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o
./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o
...

Xcode.app above is v6.1.1.  I am on OS X 10.9.5 and notice that for 10.9
I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3.

Pete


From erik.joelsson at oracle.com  Tue Apr  7 15:15:56 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 07 Apr 2015 17:15:56 +0200
Subject: RFR
Message-ID: <5523F4AC.9050007@oracle.com>

Hello,

When upgrading the toolchain to VS2013, management.dll stopped working 
on certain Windows hosts. I've identified this to be related to the call 
to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the 
problem goes away.

Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
Patch inline:

diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
--- a/make/lib/Lib-java.management.gmk  Tue Apr 07 10:33:08 2015 +0100
+++ b/make/lib/Lib-java.management.gmk  Tue Apr 07 17:11:29 2015 +0200
@@ -38,6 +38,11 @@
      $(LIBJAVA_HEADER_FLAGS) \
      #

+# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
+# a binary that is compatible with windows versions older than 7/2008R2.
+# See MSDN documentation for GetProcessMemoryInfo for more information.
+BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
+
  BUILD_LIBMANAGEMENT_EXCLUDES :=

  ifneq ($(OPENJDK_TARGET_OS), solaris)


/Erik


From erik.joelsson at oracle.com  Tue Apr  7 15:21:02 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 07 Apr 2015 17:21:02 +0200
Subject: RFR: JDK-8076557: The specified procedure could not be found in
	management.dll
In-Reply-To: <5523F4AC.9050007@oracle.com>
References: <5523F4AC.9050007@oracle.com>
Message-ID: <5523F5DE.9030601@oracle.com>

(corrected subject)

On 2015-04-07 17:15, Erik Joelsson wrote:
> Hello,
>
> When upgrading the toolchain to VS2013, management.dll stopped working 
> on certain Windows hosts. I've identified this to be related to the 
> call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, 
> the problem goes away.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
> Patch inline:
>
> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
> --- a/make/lib/Lib-java.management.gmk  Tue Apr 07 10:33:08 2015 +0100
> +++ b/make/lib/Lib-java.management.gmk  Tue Apr 07 17:11:29 2015 +0200
> @@ -38,6 +38,11 @@
>      $(LIBJAVA_HEADER_FLAGS) \
>      #
>
> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to 
> generate
> +# a binary that is compatible with windows versions older than 7/2008R2.
> +# See MSDN documentation for GetProcessMemoryInfo for more information.
> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
> +
>  BUILD_LIBMANAGEMENT_EXCLUDES :=
>
>  ifneq ($(OPENJDK_TARGET_OS), solaris)
>
>
> /Erik



From vadim.pakhnushev at oracle.com  Tue Apr  7 15:22:02 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Tue, 07 Apr 2015 18:22:02 +0300
Subject: MacOSX, jdk8u-dev build break, getting Xcode 4.6.3 set up for
	Maveriks 10.9.5
In-Reply-To: <5523D3F3.40309@oracle.com>
References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com>	<55230C8A.8060909@oracle.com>
	<55234669.3080007@oracle.com>	<552377C1.7020305@oracle.com>
	<5523D3F3.40309@oracle.com>
Message-ID: <5523F61A.4000303@oracle.com>

Pete, have you tried
sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/
?
It seems that the configure doesn't pick the correct path from the 
xcode-select.
Although I successfully built jdk8u on 10.10 with both xcode-select and 
--with-xcode-path
BTW, the correct path for xcode-select would be /Applications/Xcode\ 
4.6.3.app/Contents/Developer I guess.

Thanks,
Vadim

On 07.04.2015 15:56, Pete Brunet wrote:
> Hi, I need some help so I can build on MacOSX to fix a build break.
>
> First since I had Xcode 6.1.1 and configure complained that I didn't
> have v4 I installed v4.6.3.  After installing 4.6.3 and doing
> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/
> I got past that.  Then for some reason my compile environment is now
> bad.  I get
>
> ...
> configure:20476: checking for C compiler version
> configure:20485: /usr/bin/gcc --version >&5
> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
> 5658) (LLVM build 2336.11.00)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> configure:20496: $? = 0
> configure:20485: /usr/bin/gcc -v >&5
> Using built-in specs.
> Target: i686-apple-darwin11
> Configured with:
> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure
> --disable-checking --enable-werror
> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2
> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++
> --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
> --with-slibdir=/usr/lib --build=i686-apple-darwin11
> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local
> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
> --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
> Thread model: posix
> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
> configure:20496: $? = 0
> configure:20485: /usr/bin/gcc -V >&5
> llvm-gcc-4.2: argument to `-V' is missing
> configure:20496: $? = 1
> configure:20485: /usr/bin/gcc -qversion >&5
> i686-apple-darwin11-llvm-gcc-4.2: no input files
> configure:20496: $? = 1
> configure:20516: checking whether the C compiler works
> configure:20538: /usr/bin/gcc    conftest.c  >&5
> ld: library not found for -lcrt1.10.6.o
> collect2: ld returned 1 exit status
> ...
>
> Trying find from the root:
> find . -name crt1\*
>
> ...
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o
> ./Applications/Xcode
> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o
> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o
> ...
>
> Xcode.app above is v6.1.1.  I am on OS X 10.9.5 and notice that for 10.9
> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3.
>
> Pete



From david.dehaven at oracle.com  Tue Apr  7 16:20:34 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Tue, 7 Apr 2015 09:20:34 -0700
Subject: MacOSX, jdk8u-dev build break,
	getting Xcode 4.6.3 set up for Maveriks 10.9.5
In-Reply-To: <5523F61A.4000303@oracle.com>
References: <87FB164B-41BF-400B-A771-3C760C8B9B75@oracle.com>
	<55230C8A.8060909@oracle.com> <55234669.3080007@oracle.com>
	<552377C1.7020305@oracle.com> <5523D3F3.40309@oracle.com>
	<5523F61A.4000303@oracle.com>
Message-ID: <E745BD0E-9C3D-4854-B6FC-C6336D729071@oracle.com>


Be careful placing older versions of Xcode in /Applications. I've had MAS auto-update Xcode deleting old versions in the process.

-DrD-

> Pete, have you tried
> sh configure --with-xcode-path=/Applications/Xcode\ 4.6.3.app/
> ?
> It seems that the configure doesn't pick the correct path from the xcode-select.
> Although I successfully built jdk8u on 10.10 with both xcode-select and --with-xcode-path
> BTW, the correct path for xcode-select would be /Applications/Xcode\ 4.6.3.app/Contents/Developer I guess.
> 
> Thanks,
> Vadim
> 
> On 07.04.2015 15:56, Pete Brunet wrote:
>> Hi, I need some help so I can build on MacOSX to fix a build break.
>> 
>> First since I had Xcode 6.1.1 and configure complained that I didn't
>> have v4 I installed v4.6.3.  After installing 4.6.3 and doing
>> sudo xcode-select -s /Applications/Xcode\ 4.6.3.app/
>> I got past that.  Then for some reason my compile environment is now
>> bad.  I get
>> 
>> ...
>> configure:20476: checking for C compiler version
>> configure:20485: /usr/bin/gcc --version >&5
>> i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build
>> 5658) (LLVM build 2336.11.00)
>> Copyright (C) 2007 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>> 
>> configure:20496: $? = 0
>> configure:20485: /usr/bin/gcc -v >&5
>> Using built-in specs.
>> Target: i686-apple-darwin11
>> Configured with:
>> /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure
>> --disable-checking --enable-werror
>> --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2
>> --mandir=/share/man --enable-languages=c,objc,c++,obj-c++
>> --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/
>> --with-slibdir=/usr/lib --build=i686-apple-darwin11
>> --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local
>> --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11
>> --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
>> Thread model: posix
>> gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
>> configure:20496: $? = 0
>> configure:20485: /usr/bin/gcc -V >&5
>> llvm-gcc-4.2: argument to `-V' is missing
>> configure:20496: $? = 1
>> configure:20485: /usr/bin/gcc -qversion >&5
>> i686-apple-darwin11-llvm-gcc-4.2: no input files
>> configure:20496: $? = 1
>> configure:20516: checking whether the C compiler works
>> configure:20538: /usr/bin/gcc    conftest.c  >&5
>> ld: library not found for -lcrt1.10.6.o
>> collect2: ld returned 1 exit status
>> ...
>> 
>> Trying find from the root:
>> find . -name crt1\*
>> 
>> ...
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.3.1.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.1.sdk/usr/lib/crt1.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.5.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.10.6.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.3.1.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator6.1.sdk/usr/lib/crt1.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.5.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.10.6.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk/usr/lib/crt1.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.5.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.10.6.o
>> ./Applications/Xcode
>> 4.6.3.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/usr/lib/crt1.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.3.1.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/usr/lib/crt1.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.5.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.10.6.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.3.1.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator.sdk/usr/lib/crt1.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.5.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.10.6.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/lib/crt1.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.5.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.10.6.o
>> ./Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk/usr/lib/crt1.o
>> ...
>> 
>> Xcode.app above is v6.1.1.  I am on OS X 10.9.5 and notice that for 10.9
>> I have crt1.10.6.o Xcode (6.1.1) but not for Xcode 4.6.3.
>> 
>> Pete
> 



From tim.bell at oracle.com  Tue Apr  7 17:08:37 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Tue, 07 Apr 2015 10:08:37 -0700
Subject: RFR: JDK-8076557: The specified procedure could not be found
	in management.dll
In-Reply-To: <5523F5DE.9030601@oracle.com>
References: <5523F4AC.9050007@oracle.com> <5523F5DE.9030601@oracle.com>
Message-ID: <55240F15.7060406@oracle.com>

Erik-

Looks good to me.

Tim

On 04/07/15 08:21, Erik Joelsson wrote:
> (corrected subject)
>
> On 2015-04-07 17:15, Erik Joelsson wrote:
>> Hello,
>>
>> When upgrading the toolchain to VS2013, management.dll stopped 
>> working on certain Windows hosts. I've identified this to be related 
>> to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to 
>> CFLAGS, the problem goes away.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
>> Patch inline:
>>
>> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
>> --- a/make/lib/Lib-java.management.gmk  Tue Apr 07 10:33:08 2015 +0100
>> +++ b/make/lib/Lib-java.management.gmk  Tue Apr 07 17:11:29 2015 +0200
>> @@ -38,6 +38,11 @@
>>      $(LIBJAVA_HEADER_FLAGS) \
>>      #
>>
>> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to 
>> generate
>> +# a binary that is compatible with windows versions older than 
>> 7/2008R2.
>> +# See MSDN documentation for GetProcessMemoryInfo for more information.
>> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
>> +
>>  BUILD_LIBMANAGEMENT_EXCLUDES :=
>>
>>  ifneq ($(OPENJDK_TARGET_OS), solaris)
>>
>>
>> /Erik
>



From staffan.larsen at oracle.com  Tue Apr  7 18:49:06 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Tue, 7 Apr 2015 20:49:06 +0200
Subject: RFR
In-Reply-To: <5523F4AC.9050007@oracle.com>
References: <5523F4AC.9050007@oracle.com>
Message-ID: <E623FAE8-05E1-4196-BF02-1D64E55E6D19@oracle.com>

Looks good!

Thanks,
/Staffan

> On 7 apr 2015, at 17:15, Erik Joelsson <erik.joelsson at oracle.com> wrote:
> 
> Hello,
> 
> When upgrading the toolchain to VS2013, management.dll stopped working on certain Windows hosts. I've identified this to be related to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the problem goes away.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
> Patch inline:
> 
> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
> --- a/make/lib/Lib-java.management.gmk  Tue Apr 07 10:33:08 2015 +0100
> +++ b/make/lib/Lib-java.management.gmk  Tue Apr 07 17:11:29 2015 +0200
> @@ -38,6 +38,11 @@
>     $(LIBJAVA_HEADER_FLAGS) \
>     #
> 
> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
> +# a binary that is compatible with windows versions older than 7/2008R2.
> +# See MSDN documentation for GetProcessMemoryInfo for more information.
> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
> +
> BUILD_LIBMANAGEMENT_EXCLUDES :=
> 
> ifneq ($(OPENJDK_TARGET_OS), solaris)
> 
> 
> /Erik



From peter.brunet at oracle.com  Wed Apr  8 05:51:56 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 00:51:56 -0500
Subject: RfR JDK-8076552 nightly build break fix
Message-ID: <5524C1FC.2020805@oracle.com>

Please review/approve the following patch.

http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/

The recent push for JDK-8076182 caused a build break, i.e. a problem for
the creation of the Javadoc in the environment used by the nightly
build.  This was because a newly opened package
com.sun.java.accessibility.util was mistakenly located in a windows
directory.  This patch moves the package's files from
jdk/src/windows/classes to jdk/src/share/classes and this should resolve
the build break for the jdk8u-dev nightly.

JPRT builds run OK on solaris, mac, and linux.  As of this writing the
Win jobs haven't started yet but the 64 bit build completed OK on my
local machine.

This patch also had to include the fix for JDK-8051297 "Remove
com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
is dead code and its existence in jdk/src/share/classes causes a
compilation failure, access of a non-existent enum, the reason the file
was planned to be removed.

Thanks, Pete




From mandy.chung at oracle.com  Wed Apr  8 06:06:13 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Tue, 07 Apr 2015 23:06:13 -0700
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <5524C1FC.2020805@oracle.com>
References: <5524C1FC.2020805@oracle.com>
Message-ID: <5524C555.5030607@oracle.com>

This API is only available on windows but not other platforms.  I think 
src/windows/classes is the right location.

Mandy

On 4/7/2015 10:51 PM, Pete Brunet wrote:
> Please review/approve the following patch.
>
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>
> The recent push for JDK-8076182 caused a build break, i.e. a problem for
> the creation of the Javadoc in the environment used by the nightly
> build.  This was because a newly opened package
> com.sun.java.accessibility.util was mistakenly located in a windows
> directory.  This patch moves the package's files from
> jdk/src/windows/classes to jdk/src/share/classes and this should resolve
> the build break for the jdk8u-dev nightly.
>
> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
> Win jobs haven't started yet but the 64 bit build completed OK on my
> local machine.
>
> This patch also had to include the fix for JDK-8051297 "Remove
> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
> is dead code and its existence in jdk/src/share/classes causes a
> compilation failure, access of a non-existent enum, the reason the file
> was planned to be removed.
>
> Thanks, Pete
>
>



From david.holmes at oracle.com  Wed Apr  8 06:22:06 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 08 Apr 2015 16:22:06 +1000
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <5524C1FC.2020805@oracle.com>
References: <5524C1FC.2020805@oracle.com>
Message-ID: <5524C90E.303@oracle.com>

Pete,

I think Erik's suggestion in the bug report is more appropriate. If this 
is only a source bundle issue then the build instructions for javadoc 
should either be Windows specific, or else check for source existence.

David

On 8/04/2015 3:51 PM, Pete Brunet wrote:
> Please review/approve the following patch.
>
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>
> The recent push for JDK-8076182 caused a build break, i.e. a problem for
> the creation of the Javadoc in the environment used by the nightly
> build.  This was because a newly opened package
> com.sun.java.accessibility.util was mistakenly located in a windows
> directory.  This patch moves the package's files from
> jdk/src/windows/classes to jdk/src/share/classes and this should resolve
> the build break for the jdk8u-dev nightly.
>
> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
> Win jobs haven't started yet but the 64 bit build completed OK on my
> local machine.
>
> This patch also had to include the fix for JDK-8051297 "Remove
> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
> is dead code and its existence in jdk/src/share/classes causes a
> compilation failure, access of a non-existent enum, the reason the file
> was planned to be removed.
>
> Thanks, Pete
>
>


From magnus.ihse.bursie at oracle.com  Wed Apr  8 06:39:46 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 8 Apr 2015 08:39:46 +0200
Subject: RFR: JDK-8076557: The specified procedure could not be found in
	management.dll
In-Reply-To: <5523F5DE.9030601@oracle.com>
References: <5523F4AC.9050007@oracle.com> <5523F5DE.9030601@oracle.com>
Message-ID: <E3F5683F-2553-45C9-AE7E-E05A72648D6B@oracle.com>

Looks good to me. 

/Magnus

> 7 apr 2015 kl. 17:21 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> (corrected subject)
> 
>> On 2015-04-07 17:15, Erik Joelsson wrote:
>> Hello,
>> 
>> When upgrading the toolchain to VS2013, management.dll stopped working on certain Windows hosts. I've identified this to be related to the call to GetProcessMemoryInfo. By adding -DPSAPI_VERSION=1 to CFLAGS, the problem goes away.
>> 
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8076557
>> Patch inline:
>> 
>> diff -r 85380cfe4f0f make/lib/Lib-java.management.gmk
>> --- a/make/lib/Lib-java.management.gmk  Tue Apr 07 10:33:08 2015 +0100
>> +++ b/make/lib/Lib-java.management.gmk  Tue Apr 07 17:11:29 2015 +0200
>> @@ -38,6 +38,11 @@
>>     $(LIBJAVA_HEADER_FLAGS) \
>>     #
>> 
>> +# In (at least) VS2013 and later, -DPSAPI_VERSION=1 is needed to generate
>> +# a binary that is compatible with windows versions older than 7/2008R2.
>> +# See MSDN documentation for GetProcessMemoryInfo for more information.
>> +BUILD_LIBMANAGEMENT_CFLAGS += -DPSAPI_VERSION=1
>> +
>> BUILD_LIBMANAGEMENT_EXCLUDES :=
>> 
>> ifneq ($(OPENJDK_TARGET_OS), solaris)
>> 
>> 
>> /Erik
> 


From erik.joelsson at oracle.com  Wed Apr  8 09:18:19 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 08 Apr 2015 11:18:19 +0200
Subject: RFR: JDK-8073634: Improve clean targets
In-Reply-To: <5523BEC8.3060902@oracle.com>
References: <551D3E95.8030804@oracle.com> <5523BEC8.3060902@oracle.com>
Message-ID: <5524F25B.6000102@oracle.com>

Hello,

New webrev: http://cr.openjdk.java.net/~erikj/8073634/webrev.02/

On 2015-04-07 13:26, Magnus Ihse Bursie wrote:
> In general it looks good. I have a couple of remarks, though.
>
> 1) In Clean-docs, you do:
> +        $(RM) -r $(SUPPORT_OUTPUTDIR)/docs
> +        $(RM) -r $(IMAGES_OUTPUTDIR)/docs
>
> I'm not quite certain cleaning images/docs the right thing to do. For 
> all other clean targets, we only clean the support part. If we want to 
> clean images, we run clean-images. And if you think this is the right 
> thing to do for images, wouldn't it then also be the right thing for 
> e.g. java.base-native? And then things quickly become complicated.
>
The docs target generates docs directly into images. The directory in 
support is for temporary/intermediate files. Building to support and 
then just copy it all over to images seems like a waste of both time and 
disk space. Also note that the clean targets aren't mutually exclusive 
today. You can for example do clean-support or you can do clean-java.base.
> 2) The new configure-support, as well as the rather new make-support 
> seems to be a bit unfairly treated. There is a MAKESUPPORT_OUTPUTDIR 
> in spec.gmk but it's hardcoded there, so you can't use it in 
> configure, e.g. in your changes in build-performance.m4. The new 
> configure-support does not even have a corresponding 
> CONFIGURESUPPORT_OUTPUTDIR in the spec.gmk. Instead, it has a variable 
> CONFIGURE_SUPPORT that is present only in the configure files.
>
> I'm not sure how much, if anything, of these inconsistencies that 
> should be fixed now. But I'd suggest that you rename CONFIGURE_SUPPORT 
> to CONFIGURESUPPORT_OUTPUTDIR at the very least. (Or, maybe, 
> MAKESUPPORT_OUTPUTDIR should be MAKE_SUPPORT_OUTPUTDIR.)
>
Renamed to CONFIGURESUPPORT_OUTPUTDIR and put it in spec. Removed 
reference to make-support in configure and put the single use directly 
in spec.gmk.in instead. There is no need for configure to know about the 
sjavacservers dir. Changed dist-clean in Main.gmk to use the variable 
CONFIGURESUPPORT_OUTPUTDIR.

/Erik


From staffan.larsen at oracle.com  Wed Apr  8 10:21:14 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Wed, 8 Apr 2015 12:21:14 +0200
Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk 9
Message-ID: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>

Please review these small changes to support an addition of closed code to the java.instrument module.

webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ <http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/>

Thanks,
/Staffan

From erik.joelsson at oracle.com  Wed Apr  8 10:32:07 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 08 Apr 2015 12:32:07 +0200
Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk
 9
In-Reply-To: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
References: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
Message-ID: <552503A7.9080901@oracle.com>

Looks good to me.

/Erik

On 2015-04-08 12:21, Staffan Larsen wrote:
> Please review these small changes to support an addition of closed code to the java.instrument module.
>
> webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ <http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/>
>
> Thanks,
> /Staffan



From peter.brunet at oracle.com  Wed Apr  8 13:23:49 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 08:23:49 -0500
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <5524C555.5030607@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5524C555.5030607@oracle.com>
Message-ID: <55252BE5.8040503@oracle.com>

Hi Mandy, com.sun.java.accessibility.util can be used on other
platforms.  com.sun.java.accessibility is Win only.  -Pete

On 4/8/15 1:06 AM, Mandy Chung wrote:
> This API is only available on windows but not other platforms.  I
> think src/windows/classes is the right location.
>
> Mandy
>
> On 4/7/2015 10:51 PM, Pete Brunet wrote:
>> Please review/approve the following patch.
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>
>> The recent push for JDK-8076182 caused a build break, i.e. a problem for
>> the creation of the Javadoc in the environment used by the nightly
>> build.  This was because a newly opened package
>> com.sun.java.accessibility.util was mistakenly located in a windows
>> directory.  This patch moves the package's files from
>> jdk/src/windows/classes to jdk/src/share/classes and this should resolve
>> the build break for the jdk8u-dev nightly.
>>
>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>> Win jobs haven't started yet but the 64 bit build completed OK on my
>> local machine.
>>
>> This patch also had to include the fix for JDK-8051297 "Remove
>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
>> is dead code and its existence in jdk/src/share/classes causes a
>> compilation failure, access of a non-existent enum, the reason the file
>> was planned to be removed.
>>
>> Thanks, Pete
>>
>>
>



From peter.brunet at oracle.com  Wed Apr  8 13:47:29 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 08:47:29 -0500
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <5524C90E.303@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5524C90E.303@oracle.com>
Message-ID: <55253171.1040503@oracle.com>



On 4/8/15 1:22 AM, David Holmes wrote:
> Pete,
>
> I think Erik's suggestion in the bug report is more appropriate. If
> this is only a source bundle issue then the build instructions for
> javadoc should either be Windows specific, or else check for source
> existence.
David, Considering that the source should be in jdk/src/share/classes
does that change things?  -Pete
>
> David
>
> On 8/04/2015 3:51 PM, Pete Brunet wrote:
>> Please review/approve the following patch.
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>
>> The recent push for JDK-8076182 caused a build break, i.e. a problem for
>> the creation of the Javadoc in the environment used by the nightly
>> build.  This was because a newly opened package
>> com.sun.java.accessibility.util was mistakenly located in a windows
>> directory.  This patch moves the package's files from
>> jdk/src/windows/classes to jdk/src/share/classes and this should resolve
>> the build break for the jdk8u-dev nightly.
>>
>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>> Win jobs haven't started yet but the 64 bit build completed OK on my
>> local machine.
>>
>> This patch also had to include the fix for JDK-8051297 "Remove
>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
>> is dead code and its existence in jdk/src/share/classes causes a
>> compilation failure, access of a non-existent enum, the reason the file
>> was planned to be removed.
>>
>> Thanks, Pete
>>
>>



From mandy.chung at oracle.com  Wed Apr  8 15:12:29 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 08 Apr 2015 08:12:29 -0700
Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk
 9
In-Reply-To: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
References: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
Message-ID: <5525455D.7000501@oracle.com>

On 4/8/2015 3:21 AM, Staffan Larsen wrote:
> Please review these small changes to support an addition of closed code to the java.instrument module.
>
> webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ <http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/>

The change looks fine.

Mandy



From peter.brunet at oracle.com  Wed Apr  8 17:25:32 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 12:25:32 -0500
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <5524C1FC.2020805@oracle.com>
References: <5524C1FC.2020805@oracle.com>
Message-ID: <5525648C.2060106@oracle.com>

Here is an updated patch.
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/

It simply removes the com.sun.java.accessibility.util part of the
javadoc generation.

How to better deal with the javadoc generation can be left to later.

Please let me know if this patch meets with your approval.

I have started a local Win build and will start JPRT builds on Linux,
Windows, Solaris, and Mac shortly.

Thanks,
Pete

On 4/8/15 12:51 AM, Pete Brunet wrote:
> Please review/approve the following patch.
>
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>
> The recent push for JDK-8076182 caused a build break, i.e. a problem for
> the creation of the Javadoc in the environment used by the nightly
> build.  This was because a newly opened package
> com.sun.java.accessibility.util was mistakenly located in a windows
> directory.  This patch moves the package's files from
> jdk/src/windows/classes to jdk/src/share/classes and this should resolve
> the build break for the jdk8u-dev nightly.
>
> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
> Win jobs haven't started yet but the 64 bit build completed OK on my
> local machine.
>
> This patch also had to include the fix for JDK-8051297 "Remove
> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
> is dead code and its existence in jdk/src/share/classes causes a
> compilation failure, access of a non-existent enum, the reason the file
> was planned to be removed.
>
> Thanks, Pete
>
>



From philip.race at oracle.com  Wed Apr  8 17:29:14 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 08 Apr 2015 10:29:14 -0700
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <5525648C.2060106@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
Message-ID: <5525656A.1000106@oracle.com>

Isn't it sufficient to comment out this one line ?

1215 ALL_OTHER_TARGETS += jaccessdocs

.. and add a comment as to why ?

-phil.


On 04/08/2015 10:25 AM, Pete Brunet wrote:
> Here is an updated patch.
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>
> It simply removes the com.sun.java.accessibility.util part of the
> javadoc generation.
>
> How to better deal with the javadoc generation can be left to later.
>
> Please let me know if this patch meets with your approval.
>
> I have started a local Win build and will start JPRT builds on Linux,
> Windows, Solaris, and Mac shortly.
>
> Thanks,
> Pete
>
> On 4/8/15 12:51 AM, Pete Brunet wrote:
>> Please review/approve the following patch.
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>
>> The recent push for JDK-8076182 caused a build break, i.e. a problem for
>> the creation of the Javadoc in the environment used by the nightly
>> build.  This was because a newly opened package
>> com.sun.java.accessibility.util was mistakenly located in a windows
>> directory.  This patch moves the package's files from
>> jdk/src/windows/classes to jdk/src/share/classes and this should resolve
>> the build break for the jdk8u-dev nightly.
>>
>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>> Win jobs haven't started yet but the 64 bit build completed OK on my
>> local machine.
>>
>> This patch also had to include the fix for JDK-8051297 "Remove
>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
>> is dead code and its existence in jdk/src/share/classes causes a
>> compilation failure, access of a non-existent enum, the reason the file
>> was planned to be removed.
>>
>> Thanks, Pete
>>
>>



From peter.brunet at oracle.com  Wed Apr  8 17:36:27 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 12:36:27 -0500
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <5525656A.1000106@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com>
Message-ID: <5525671B.3050705@oracle.com>



On 4/8/15 12:29 PM, Phil Race wrote:
> Isn't it sufficient to comment out this one line ?
>
> 1215 ALL_OTHER_TARGETS += jaccessdocs
>
> .. and add a comment as to why ?
I'm not familiar with this make file so I took the straightforward
approach.

If you are confident that will work I'll redo the patch.  Let me know.
>
> -phil.
>
>
> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>> Here is an updated patch.
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>
>> It simply removes the com.sun.java.accessibility.util part of the
>> javadoc generation.
>>
>> How to better deal with the javadoc generation can be left to later.
>>
>> Please let me know if this patch meets with your approval.
>>
>> I have started a local Win build and will start JPRT builds on Linux,
>> Windows, Solaris, and Mac shortly.
>>
>> Thanks,
>> Pete
>>
>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>> Please review/approve the following patch.
>>>
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>
>>> The recent push for JDK-8076182 caused a build break, i.e. a problem
>>> for
>>> the creation of the Javadoc in the environment used by the nightly
>>> build.  This was because a newly opened package
>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>> directory.  This patch moves the package's files from
>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>> resolve
>>> the build break for the jdk8u-dev nightly.
>>>
>>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>> local machine.
>>>
>>> This patch also had to include the fix for JDK-8051297 "Remove
>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator".  That file
>>> is dead code and its existence in jdk/src/share/classes causes a
>>> compilation failure, access of a non-existent enum, the reason the file
>>> was planned to be removed.
>>>
>>> Thanks, Pete
>>>
>>>
>



From mandy.chung at oracle.com  Wed Apr  8 17:47:15 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 08 Apr 2015 10:47:15 -0700
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <5525656A.1000106@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com>
Message-ID: <552569A3.3080004@oracle.com>

I agree with Phil's suggestion and file a bug to follow up the javadoc 
build issue.

You can verify the result from make docs that there is no javadoc 
generated for this package on windows build.

Mandy

On 4/8/2015 10:29 AM, Phil Race wrote:
> Isn't it sufficient to comment out this one line ?
>
> 1215 ALL_OTHER_TARGETS += jaccessdocs
>
> .. and add a comment as to why ?
>
> -phil.
>
>
> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>> Here is an updated patch.
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>
>> It simply removes the com.sun.java.accessibility.util part of the
>> javadoc generation.
>>
>> How to better deal with the javadoc generation can be left to later.
>>
>> Please let me know if this patch meets with your approval.
>>
>> I have started a local Win build and will start JPRT builds on Linux,
>> Windows, Solaris, and Mac shortly.
>>
>> Thanks,
>> Pete
>>
>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>> Please review/approve the following patch.
>>>
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>
>>> The recent push for JDK-8076182 caused a build break, i.e. a problem 
>>> for
>>> the creation of the Javadoc in the environment used by the nightly
>>> build.  This was because a newly opened package
>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>> directory.  This patch moves the package's files from
>>> jdk/src/windows/classes to jdk/src/share/classes and this should 
>>> resolve
>>> the build break for the jdk8u-dev nightly.
>>>
>>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>> local machine.
>>>
>>> This patch also had to include the fix for JDK-8051297 "Remove
>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That file
>>> is dead code and its existence in jdk/src/share/classes causes a
>>> compilation failure, access of a non-existent enum, the reason the file
>>> was planned to be removed.
>>>
>>> Thanks, Pete
>>>
>>>
>



From peter.brunet at oracle.com  Wed Apr  8 17:55:35 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 12:55:35 -0500
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <552569A3.3080004@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
Message-ID: <55256B97.5040105@oracle.com>

How's this?
http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03

On 4/8/15 12:47 PM, Mandy Chung wrote:
> I agree with Phil's suggestion and file a bug to follow up the javadoc
> build issue.
>
> You can verify the result from make docs that there is no javadoc
> generated for this package on windows build.
>
> Mandy
>
> On 4/8/2015 10:29 AM, Phil Race wrote:
>> Isn't it sufficient to comment out this one line ?
>>
>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>
>> .. and add a comment as to why ?
>>
>> -phil.
>>
>>
>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>> Here is an updated patch.
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>
>>> It simply removes the com.sun.java.accessibility.util part of the
>>> javadoc generation.
>>>
>>> How to better deal with the javadoc generation can be left to later.
>>>
>>> Please let me know if this patch meets with your approval.
>>>
>>> I have started a local Win build and will start JPRT builds on Linux,
>>> Windows, Solaris, and Mac shortly.
>>>
>>> Thanks,
>>> Pete
>>>
>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>> Please review/approve the following patch.
>>>>
>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>
>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>> problem for
>>>> the creation of the Javadoc in the environment used by the nightly
>>>> build.  This was because a newly opened package
>>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>>> directory.  This patch moves the package's files from
>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>> resolve
>>>> the build break for the jdk8u-dev nightly.
>>>>
>>>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>>> local machine.
>>>>
>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That file
>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>> compilation failure, access of a non-existent enum, the reason the
>>>> file
>>>> was planned to be removed.
>>>>
>>>> Thanks, Pete
>>>>
>>>>
>>
>



From philip.race at oracle.com  Wed Apr  8 18:00:57 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 08 Apr 2015 11:00:57 -0700
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <55256B97.5040105@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
	<55256B97.5040105@oracle.com>
Message-ID: <55256CD9.4060501@oracle.com>

That looks good to me.

-phil.

On 4/8/2015 10:55 AM, Pete Brunet wrote:
> How's this?
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>
> On 4/8/15 12:47 PM, Mandy Chung wrote:
>> I agree with Phil's suggestion and file a bug to follow up the javadoc
>> build issue.
>>
>> You can verify the result from make docs that there is no javadoc
>> generated for this package on windows build.
>>
>> Mandy
>>
>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>> Isn't it sufficient to comment out this one line ?
>>>
>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>
>>> .. and add a comment as to why ?
>>>
>>> -phil.
>>>
>>>
>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>>> Here is an updated patch.
>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>>
>>>> It simply removes the com.sun.java.accessibility.util part of the
>>>> javadoc generation.
>>>>
>>>> How to better deal with the javadoc generation can be left to later.
>>>>
>>>> Please let me know if this patch meets with your approval.
>>>>
>>>> I have started a local Win build and will start JPRT builds on Linux,
>>>> Windows, Solaris, and Mac shortly.
>>>>
>>>> Thanks,
>>>> Pete
>>>>
>>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>>> Please review/approve the following patch.
>>>>>
>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>>
>>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>>> problem for
>>>>> the creation of the Javadoc in the environment used by the nightly
>>>>> build.  This was because a newly opened package
>>>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>>>> directory.  This patch moves the package's files from
>>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>>> resolve
>>>>> the build break for the jdk8u-dev nightly.
>>>>>
>>>>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>>>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>>>> local machine.
>>>>>
>>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That file
>>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>>> compilation failure, access of a non-existent enum, the reason the
>>>>> file
>>>>> was planned to be removed.
>>>>>
>>>>> Thanks, Pete
>>>>>
>>>>>



From peter.brunet at oracle.com  Wed Apr  8 18:14:36 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 13:14:36 -0500
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <55256EAA.1040107@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
	<55256B97.5040105@oracle.com> <55256CD9.4060501@oracle.com>
	<55256EAA.1040107@oracle.com>
Message-ID: <5525700C.1080706@oracle.com>

resending - too many on To:/Cc:

On 4/8/15 1:08 PM, Pete Brunet wrote:
> I confirmed the javadoc is gone, and make docs did not fail.
>
> I have yet to submit the JPRT job.
>
> Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
> you approve the push?
>
> Phil will have to do the push; my committer status is pending.
>
> Pete
>
> On 4/8/15 1:00 PM, Phil Race wrote:
>> That looks good to me.
>>
>> -phil.
>>
>> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>>> How's this?
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>>
>>> On 4/8/15 12:47 PM, Mandy Chung wrote:
>>>> I agree with Phil's suggestion and file a bug to follow up the javadoc
>>>> build issue.
>>>>
>>>> You can verify the result from make docs that there is no javadoc
>>>> generated for this package on windows build.
>>>>
>>>> Mandy
>>>>
>>>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>>>> Isn't it sufficient to comment out this one line ?
>>>>>
>>>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>>>
>>>>> .. and add a comment as to why ?
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>>>>> Here is an updated patch.
>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>>>>
>>>>>> It simply removes the com.sun.java.accessibility.util part of the
>>>>>> javadoc generation.
>>>>>>
>>>>>> How to better deal with the javadoc generation can be left to later.
>>>>>>
>>>>>> Please let me know if this patch meets with your approval.
>>>>>>
>>>>>> I have started a local Win build and will start JPRT builds on Linux,
>>>>>> Windows, Solaris, and Mac shortly.
>>>>>>
>>>>>> Thanks,
>>>>>> Pete
>>>>>>
>>>>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>>>>> Please review/approve the following patch.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>>>>
>>>>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>>>>> problem for
>>>>>>> the creation of the Javadoc in the environment used by the nightly
>>>>>>> build.  This was because a newly opened package
>>>>>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>>>>>> directory.  This patch moves the package's files from
>>>>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>>>>> resolve
>>>>>>> the build break for the jdk8u-dev nightly.
>>>>>>>
>>>>>>> JPRT builds run OK on solaris, mac, and linux.  As of this
>>>>>>> writing the
>>>>>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>>>>>> local machine.
>>>>>>>
>>>>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
>>>>>>> file
>>>>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>>>>> compilation failure, access of a non-existent enum, the reason the
>>>>>>> file
>>>>>>> was planned to be removed.
>>>>>>>
>>>>>>> Thanks, Pete
>>>>>>>
>>>>>>>



From mandy.chung at oracle.com  Wed Apr  8 18:18:16 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Wed, 08 Apr 2015 11:18:16 -0700
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <55256CD9.4060501@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
	<55256B97.5040105@oracle.com> <55256CD9.4060501@oracle.com>
Message-ID: <552570E8.8010100@oracle.com>

+1

Mandy

On 4/8/2015 11:00 AM, Phil Race wrote:
> That looks good to me.
>
> -phil.
>
> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>> How's this?
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>
>> On 4/8/15 12:47 PM, Mandy Chung wrote:
>>> I agree with Phil's suggestion and file a bug to follow up the javadoc
>>> build issue.
>>>
>>> You can verify the result from make docs that there is no javadoc
>>> generated for this package on windows build.
>>>
>>> Mandy
>>>
>>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>>> Isn't it sufficient to comment out this one line ?
>>>>
>>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>>
>>>> .. and add a comment as to why ?
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>>>> Here is an updated patch.
>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>>>
>>>>> It simply removes the com.sun.java.accessibility.util part of the
>>>>> javadoc generation.
>>>>>
>>>>> How to better deal with the javadoc generation can be left to later.
>>>>>
>>>>> Please let me know if this patch meets with your approval.
>>>>>
>>>>> I have started a local Win build and will start JPRT builds on Linux,
>>>>> Windows, Solaris, and Mac shortly.
>>>>>
>>>>> Thanks,
>>>>> Pete
>>>>>
>>>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>>>> Please review/approve the following patch.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>>>
>>>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>>>> problem for
>>>>>> the creation of the Javadoc in the environment used by the nightly
>>>>>> build.  This was because a newly opened package
>>>>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>>>>> directory.  This patch moves the package's files from
>>>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>>>> resolve
>>>>>> the build break for the jdk8u-dev nightly.
>>>>>>
>>>>>> JPRT builds run OK on solaris, mac, and linux.  As of this 
>>>>>> writing the
>>>>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>>>>> local machine.
>>>>>>
>>>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That 
>>>>>> file
>>>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>>>> compilation failure, access of a non-existent enum, the reason the
>>>>>> file
>>>>>> was planned to be removed.
>>>>>>
>>>>>> Thanks, Pete
>>>>>>
>>>>>>
>



From peter.brunet at oracle.com  Wed Apr  8 18:08:42 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 13:08:42 -0500
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <55256CD9.4060501@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
	<55256B97.5040105@oracle.com> <55256CD9.4060501@oracle.com>
Message-ID: <55256EAA.1040107@oracle.com>

I confirmed the javadoc is gone, and make docs did not fail.

I have yet to submit the JPRT job.

Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
you approve the push?

Phil will have to do the push; my committer status is pending.

Pete

On 4/8/15 1:00 PM, Phil Race wrote:
> That looks good to me.
>
> -phil.
>
> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>> How's this?
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>
>> On 4/8/15 12:47 PM, Mandy Chung wrote:
>>> I agree with Phil's suggestion and file a bug to follow up the javadoc
>>> build issue.
>>>
>>> You can verify the result from make docs that there is no javadoc
>>> generated for this package on windows build.
>>>
>>> Mandy
>>>
>>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>>> Isn't it sufficient to comment out this one line ?
>>>>
>>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>>
>>>> .. and add a comment as to why ?
>>>>
>>>> -phil.
>>>>
>>>>
>>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>>>> Here is an updated patch.
>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>>>
>>>>> It simply removes the com.sun.java.accessibility.util part of the
>>>>> javadoc generation.
>>>>>
>>>>> How to better deal with the javadoc generation can be left to later.
>>>>>
>>>>> Please let me know if this patch meets with your approval.
>>>>>
>>>>> I have started a local Win build and will start JPRT builds on Linux,
>>>>> Windows, Solaris, and Mac shortly.
>>>>>
>>>>> Thanks,
>>>>> Pete
>>>>>
>>>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>>>> Please review/approve the following patch.
>>>>>>
>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>>>
>>>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>>>> problem for
>>>>>> the creation of the Javadoc in the environment used by the nightly
>>>>>> build.  This was because a newly opened package
>>>>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>>>>> directory.  This patch moves the package's files from
>>>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>>>> resolve
>>>>>> the build break for the jdk8u-dev nightly.
>>>>>>
>>>>>> JPRT builds run OK on solaris, mac, and linux.  As of this
>>>>>> writing the
>>>>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>>>>> local machine.
>>>>>>
>>>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
>>>>>> file
>>>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>>>> compilation failure, access of a non-existent enum, the reason the
>>>>>> file
>>>>>> was planned to be removed.
>>>>>>
>>>>>> Thanks, Pete
>>>>>>
>>>>>>
>



From sean.coffey at oracle.com  Wed Apr  8 18:39:45 2015
From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=)
Date: Wed, 08 Apr 2015 19:39:45 +0100
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <5525700C.1080706@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
	<55256B97.5040105@oracle.com> <55256CD9.4060501@oracle.com>
	<55256EAA.1040107@oracle.com> <5525700C.1080706@oracle.com>
Message-ID: <552575F1.2040301@oracle.com>

Pete,

http://openjdk.java.net/projects/jdk8u/groundrules.html
Rule 1. What are your plans for JDK 9 ? Is that family affected ? If not 
- add '9-na' label to bug report.

Rule 4. Approval requests should be carried out on jdk8u-dev mailing list.

regards,
Sean.

On 08/04/2015 19:14, Pete Brunet wrote:
> resending - too many on To:/Cc:
>
> On 4/8/15 1:08 PM, Pete Brunet wrote:
>> I confirmed the javadoc is gone, and make docs did not fail.
>>
>> I have yet to submit the JPRT job.
>>
>> Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
>> you approve the push?
>>
>> Phil will have to do the push; my committer status is pending.
>>
>> Pete
>>
>> On 4/8/15 1:00 PM, Phil Race wrote:
>>> That looks good to me.
>>>
>>> -phil.
>>>
>>> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>>>> How's this?
>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>>>
>>>> On 4/8/15 12:47 PM, Mandy Chung wrote:
>>>>> I agree with Phil's suggestion and file a bug to follow up the javadoc
>>>>> build issue.
>>>>>
>>>>> You can verify the result from make docs that there is no javadoc
>>>>> generated for this package on windows build.
>>>>>
>>>>> Mandy
>>>>>
>>>>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>>>>> Isn't it sufficient to comment out this one line ?
>>>>>>
>>>>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>>>>
>>>>>> .. and add a comment as to why ?
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>>
>>>>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>>>>>> Here is an updated patch.
>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>>>>>
>>>>>>> It simply removes the com.sun.java.accessibility.util part of the
>>>>>>> javadoc generation.
>>>>>>>
>>>>>>> How to better deal with the javadoc generation can be left to later.
>>>>>>>
>>>>>>> Please let me know if this patch meets with your approval.
>>>>>>>
>>>>>>> I have started a local Win build and will start JPRT builds on Linux,
>>>>>>> Windows, Solaris, and Mac shortly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Pete
>>>>>>>
>>>>>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>>>>>> Please review/approve the following patch.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>>>>>
>>>>>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>>>>>> problem for
>>>>>>>> the creation of the Javadoc in the environment used by the nightly
>>>>>>>> build.  This was because a newly opened package
>>>>>>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>>>>>>> directory.  This patch moves the package's files from
>>>>>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>>>>>> resolve
>>>>>>>> the build break for the jdk8u-dev nightly.
>>>>>>>>
>>>>>>>> JPRT builds run OK on solaris, mac, and linux.  As of this
>>>>>>>> writing the
>>>>>>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>>>>>>> local machine.
>>>>>>>>
>>>>>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>>>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
>>>>>>>> file
>>>>>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>>>>>> compilation failure, access of a non-existent enum, the reason the
>>>>>>>> file
>>>>>>>> was planned to be removed.
>>>>>>>>
>>>>>>>> Thanks, Pete
>>>>>>>>
>>>>>>>>



From lana.steuck at oracle.com  Wed Apr  8 18:38:36 2015
From: lana.steuck at oracle.com (Lana Steuck)
Date: Wed, 08 Apr 2015 11:38:36 -0700
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <55256EAA.1040107@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
	<55256B97.5040105@oracle.com> <55256CD9.4060501@oracle.com>
	<55256EAA.1040107@oracle.com>
Message-ID: <552575AC.9000702@oracle.com>

Hi Pete,

Sean said 'your fix will go via 8u-dev' - is this the case?

Or are we planning on pushing your changes to 8u Master directly (after 
proper build/test)?

Do you have a forest on nfs? (from where I can pull/clone your fixes)?

- Lana


On 04/08/2015 11:08 AM, Pete Brunet wrote:
> I confirmed the javadoc is gone, and make docs did not fail.
>
> I have yet to submit the JPRT job.
>
> Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
> you approve the push?
>
> Phil will have to do the push; my committer status is pending.
>
> Pete
>
> On 4/8/15 1:00 PM, Phil Race wrote:
>> That looks good to me.
>>
>> -phil.
>>
>> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>>> How's this?
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>>
>>> On 4/8/15 12:47 PM, Mandy Chung wrote:
>>>> I agree with Phil's suggestion and file a bug to follow up the javadoc
>>>> build issue.
>>>>
>>>> You can verify the result from make docs that there is no javadoc
>>>> generated for this package on windows build.
>>>>
>>>> Mandy
>>>>
>>>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>>>> Isn't it sufficient to comment out this one line ?
>>>>>
>>>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>>>
>>>>> .. and add a comment as to why ?
>>>>>
>>>>> -phil.
>>>>>
>>>>>
>>>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>>>>> Here is an updated patch.
>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>>>>
>>>>>> It simply removes the com.sun.java.accessibility.util part of the
>>>>>> javadoc generation.
>>>>>>
>>>>>> How to better deal with the javadoc generation can be left to later.
>>>>>>
>>>>>> Please let me know if this patch meets with your approval.
>>>>>>
>>>>>> I have started a local Win build and will start JPRT builds on Linux,
>>>>>> Windows, Solaris, and Mac shortly.
>>>>>>
>>>>>> Thanks,
>>>>>> Pete
>>>>>>
>>>>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>>>>> Please review/approve the following patch.
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>>>>
>>>>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>>>>> problem for
>>>>>>> the creation of the Javadoc in the environment used by the nightly
>>>>>>> build.  This was because a newly opened package
>>>>>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>>>>>> directory.  This patch moves the package's files from
>>>>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>>>>> resolve
>>>>>>> the build break for the jdk8u-dev nightly.
>>>>>>>
>>>>>>> JPRT builds run OK on solaris, mac, and linux.  As of this
>>>>>>> writing the
>>>>>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>>>>>> local machine.
>>>>>>>
>>>>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
>>>>>>> file
>>>>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>>>>> compilation failure, access of a non-existent enum, the reason the
>>>>>>> file
>>>>>>> was planned to be removed.
>>>>>>>
>>>>>>> Thanks, Pete
>>>>>>>
>>>>>>>



From peter.brunet at oracle.com  Wed Apr  8 18:42:34 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 13:42:34 -0500
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <552575AC.9000702@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
	<55256B97.5040105@oracle.com> <55256CD9.4060501@oracle.com>
	<55256EAA.1040107@oracle.com> <552575AC.9000702@oracle.com>
Message-ID: <5525769A.90100@oracle.com>

Phil will do the push.  I assume it needs to go to 8u-dev.

On 4/8/15 1:38 PM, Lana Steuck wrote:
> Hi Pete,
>
> Sean said 'your fix will go via 8u-dev' - is this the case?
>
> Or are we planning on pushing your changes to 8u Master directly
> (after proper build/test)?
>
> Do you have a forest on nfs? (from where I can pull/clone your fixes)?
>
> - Lana
>
>
> On 04/08/2015 11:08 AM, Pete Brunet wrote:
>> I confirmed the javadoc is gone, and make docs did not fail.
>>
>> I have yet to submit the JPRT job.
>>
>> Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
>> you approve the push?
>>
>> Phil will have to do the push; my committer status is pending.
>>
>> Pete
>>
>> On 4/8/15 1:00 PM, Phil Race wrote:
>>> That looks good to me.
>>>
>>> -phil.
>>>
>>> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>>>> How's this?
>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>>>
>>>> On 4/8/15 12:47 PM, Mandy Chung wrote:
>>>>> I agree with Phil's suggestion and file a bug to follow up the
>>>>> javadoc
>>>>> build issue.
>>>>>
>>>>> You can verify the result from make docs that there is no javadoc
>>>>> generated for this package on windows build.
>>>>>
>>>>> Mandy
>>>>>
>>>>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>>>>> Isn't it sufficient to comment out this one line ?
>>>>>>
>>>>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>>>>
>>>>>> .. and add a comment as to why ?
>>>>>>
>>>>>> -phil.
>>>>>>
>>>>>>
>>>>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>>>>>> Here is an updated patch.
>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>>>>>
>>>>>>> It simply removes the com.sun.java.accessibility.util part of the
>>>>>>> javadoc generation.
>>>>>>>
>>>>>>> How to better deal with the javadoc generation can be left to
>>>>>>> later.
>>>>>>>
>>>>>>> Please let me know if this patch meets with your approval.
>>>>>>>
>>>>>>> I have started a local Win build and will start JPRT builds on
>>>>>>> Linux,
>>>>>>> Windows, Solaris, and Mac shortly.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Pete
>>>>>>>
>>>>>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>>>>>> Please review/approve the following patch.
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>>>>>
>>>>>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>>>>>> problem for
>>>>>>>> the creation of the Javadoc in the environment used by the nightly
>>>>>>>> build.  This was because a newly opened package
>>>>>>>> com.sun.java.accessibility.util was mistakenly located in a
>>>>>>>> windows
>>>>>>>> directory.  This patch moves the package's files from
>>>>>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>>>>>> resolve
>>>>>>>> the build break for the jdk8u-dev nightly.
>>>>>>>>
>>>>>>>> JPRT builds run OK on solaris, mac, and linux.  As of this
>>>>>>>> writing the
>>>>>>>> Win jobs haven't started yet but the 64 bit build completed OK
>>>>>>>> on my
>>>>>>>> local machine.
>>>>>>>>
>>>>>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>>>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
>>>>>>>> file
>>>>>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>>>>>> compilation failure, access of a non-existent enum, the reason the
>>>>>>>> file
>>>>>>>> was planned to be removed.
>>>>>>>>
>>>>>>>> Thanks, Pete
>>>>>>>>
>>>>>>>>
>



From peter.brunet at oracle.com  Wed Apr  8 18:59:25 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 08 Apr 2015 13:59:25 -0500
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <552575F1.2040301@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
	<55256B97.5040105@oracle.com> <55256CD9.4060501@oracle.com>
	<55256EAA.1040107@oracle.com> <5525700C.1080706@oracle.com>
	<552575F1.2040301@oracle.com>
Message-ID: <55257A8D.1060903@oracle.com>

Thanks Sean,

On 4/8/15 1:39 PM, Se?n Coffey wrote:
> Pete,
>
> http://openjdk.java.net/projects/jdk8u/groundrules.html
> Rule 1. What are your plans for JDK 9 ? Is that family affected ? If
> not - add '9-na' label to bug report.
There have been no issues with 9 so I added 9-na.
>
> Rule 4. Approval requests should be carried out on jdk8u-dev mailing
> list.
I did the RfA on jdk8u-dev (but am pending the start/run/success of the
7 JPRT builds).
>
> regards,
> Sean.
>
> On 08/04/2015 19:14, Pete Brunet wrote:
>> resending - too many on To:/Cc:
>>
>> On 4/8/15 1:08 PM, Pete Brunet wrote:
>>> I confirmed the javadoc is gone, and make docs did not fail.
>>>
>>> I have yet to submit the JPRT job.
>>>
>>> Sean/Winston do you want to wait for the 7 JPRT jobs to finish before
>>> you approve the push?
>>>
>>> Phil will have to do the push; my committer status is pending.
>>>
>>> Pete
>>>
>>> On 4/8/15 1:00 PM, Phil Race wrote:
>>>> That looks good to me.
>>>>
>>>> -phil.
>>>>
>>>> On 4/8/2015 10:55 AM, Pete Brunet wrote:
>>>>> How's this?
>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03
>>>>>
>>>>> On 4/8/15 12:47 PM, Mandy Chung wrote:
>>>>>> I agree with Phil's suggestion and file a bug to follow up the
>>>>>> javadoc
>>>>>> build issue.
>>>>>>
>>>>>> You can verify the result from make docs that there is no javadoc
>>>>>> generated for this package on windows build.
>>>>>>
>>>>>> Mandy
>>>>>>
>>>>>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>>>>>> Isn't it sufficient to comment out this one line ?
>>>>>>>
>>>>>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>>>>>
>>>>>>> .. and add a comment as to why ?
>>>>>>>
>>>>>>> -phil.
>>>>>>>
>>>>>>>
>>>>>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>>>>>>> Here is an updated patch.
>>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>>>>>>
>>>>>>>> It simply removes the com.sun.java.accessibility.util part of the
>>>>>>>> javadoc generation.
>>>>>>>>
>>>>>>>> How to better deal with the javadoc generation can be left to
>>>>>>>> later.
>>>>>>>>
>>>>>>>> Please let me know if this patch meets with your approval.
>>>>>>>>
>>>>>>>> I have started a local Win build and will start JPRT builds on
>>>>>>>> Linux,
>>>>>>>> Windows, Solaris, and Mac shortly.
>>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Pete
>>>>>>>>
>>>>>>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>>>>>>> Please review/approve the following patch.
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>>>>>>
>>>>>>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>>>>>>> problem for
>>>>>>>>> the creation of the Javadoc in the environment used by the
>>>>>>>>> nightly
>>>>>>>>> build.  This was because a newly opened package
>>>>>>>>> com.sun.java.accessibility.util was mistakenly located in a
>>>>>>>>> windows
>>>>>>>>> directory.  This patch moves the package's files from
>>>>>>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>>>>>>> resolve
>>>>>>>>> the build break for the jdk8u-dev nightly.
>>>>>>>>>
>>>>>>>>> JPRT builds run OK on solaris, mac, and linux.  As of this
>>>>>>>>> writing the
>>>>>>>>> Win jobs haven't started yet but the 64 bit build completed OK
>>>>>>>>> on my
>>>>>>>>> local machine.
>>>>>>>>>
>>>>>>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>>>>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That
>>>>>>>>> file
>>>>>>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>>>>>>> compilation failure, access of a non-existent enum, the reason
>>>>>>>>> the
>>>>>>>>> file
>>>>>>>>> was planned to be removed.
>>>>>>>>>
>>>>>>>>> Thanks, Pete
>>>>>>>>>
>>>>>>>>>
>



From david.holmes at oracle.com  Wed Apr  8 20:13:32 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 09 Apr 2015 06:13:32 +1000
Subject: RfR JDK-8076552 nightly build break fix
In-Reply-To: <55256B97.5040105@oracle.com>
References: <5524C1FC.2020805@oracle.com> <5525648C.2060106@oracle.com>
	<5525656A.1000106@oracle.com> <552569A3.3080004@oracle.com>
	<55256B97.5040105@oracle.com>
Message-ID: <55258BEC.8040800@oracle.com>

Hi Pete,

Sorry all this was happening in the wee hours for me :)

On 9/04/2015 3:55 AM, Pete Brunet wrote:
> How's this?
> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.03

Seems like a good temporary fix.

To answer your earlier question to my comment, the $60K question is 
whether this stuff is indeed all platforms or not. If it is then of 
course the files should be relocated and the issue will disappear.

Thanks,
David

> On 4/8/15 12:47 PM, Mandy Chung wrote:
>> I agree with Phil's suggestion and file a bug to follow up the javadoc
>> build issue.
>>
>> You can verify the result from make docs that there is no javadoc
>> generated for this package on windows build.
>>
>> Mandy
>>
>> On 4/8/2015 10:29 AM, Phil Race wrote:
>>> Isn't it sufficient to comment out this one line ?
>>>
>>> 1215 ALL_OTHER_TARGETS += jaccessdocs
>>>
>>> .. and add a comment as to why ?
>>>
>>> -phil.
>>>
>>>
>>> On 04/08/2015 10:25 AM, Pete Brunet wrote:
>>>> Here is an updated patch.
>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.02/
>>>>
>>>> It simply removes the com.sun.java.accessibility.util part of the
>>>> javadoc generation.
>>>>
>>>> How to better deal with the javadoc generation can be left to later.
>>>>
>>>> Please let me know if this patch meets with your approval.
>>>>
>>>> I have started a local Win build and will start JPRT builds on Linux,
>>>> Windows, Solaris, and Mac shortly.
>>>>
>>>> Thanks,
>>>> Pete
>>>>
>>>> On 4/8/15 12:51 AM, Pete Brunet wrote:
>>>>> Please review/approve the following patch.
>>>>>
>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8076552/webrev.01/
>>>>>
>>>>> The recent push for JDK-8076182 caused a build break, i.e. a
>>>>> problem for
>>>>> the creation of the Javadoc in the environment used by the nightly
>>>>> build.  This was because a newly opened package
>>>>> com.sun.java.accessibility.util was mistakenly located in a windows
>>>>> directory.  This patch moves the package's files from
>>>>> jdk/src/windows/classes to jdk/src/share/classes and this should
>>>>> resolve
>>>>> the build break for the jdk8u-dev nightly.
>>>>>
>>>>> JPRT builds run OK on solaris, mac, and linux.  As of this writing the
>>>>> Win jobs haven't started yet but the 64 bit build completed OK on my
>>>>> local machine.
>>>>>
>>>>> This patch also had to include the fix for JDK-8051297 "Remove
>>>>> com.sun.java.accessibility.util.java.awt.ChoiceTranslator". That file
>>>>> is dead code and its existence in jdk/src/share/classes causes a
>>>>> compilation failure, access of a non-existent enum, the reason the
>>>>> file
>>>>> was planned to be removed.
>>>>>
>>>>> Thanks, Pete
>>>>>
>>>>>
>>>
>>
>


From magnus.ihse.bursie at oracle.com  Wed Apr  8 20:53:50 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 08 Apr 2015 22:53:50 +0200
Subject: We REALLY nead a NON-PCH build in JPRT NOW!
In-Reply-To: <480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com>
References: <CA+3eh10CVuAxfm1udE8cskycaUcuxk92u3OBdbMQw7qMAz=7OA@mail.gmail.com>
	<480AE697-2A40-433A-A728-51C64C6DEA57@oracle.com>
Message-ID: <5525955E.5000302@oracle.com>


On 2015-04-03 00:36, Kim Barrett wrote:
> On Apr 2, 2015, at 12:06 PM, Volker Simonis <volker.simonis at gmail.com> wrote:
>> while precompiled headers (PCH) are a nice and effective way of
>> improving hotspot build times
> Are we sure about that?

No, we're not. :-)

We in the build team, mainly Erik, have done testing on several 
occasions for the two major special tricks for enhancing build 
performance: PCH and ccache. Erik can probably quote you some numbers, 
but what I remember as the bottom line is that it is very much YMMV. 
There are many different scenarios:
* occasionally doing full builds from scratch
* incremental rebuilds
* repeatingly building full builds from scrach (which benefits ccache)

There are also different versions of compilers and ccache, and different 
operating systems with different file caching policies, and different 
hardware profiles (is your CPU or disk the bottleneck, etc).

Also, it is worth noting that ccache and PCH genereally do not play very 
well together. Sometimes enabling both will result in worse performance 
than just enabling one of them.

So there is no golden answer, the one thing that is most efficient in 
all circumstances.

We try to provide a reasonable default which works well in most cases 
(this currently means ccache off by default and PCH on, for hotspot). If 
you care about performance, the best thing you can do is to measure with 
and without PCH and ccache on your typical work case.

Regarding PCH and JPRT, there seem to be agreement that it typically 
improves compilation performance, at least on some platforms.

/Magnus


From joe.darcy at oracle.com  Wed Apr  8 21:49:29 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 08 Apr 2015 14:49:29 -0700
Subject: JDK 9 RFR of JDK-8075771: Enable "missing" doclint check in build
	of the java.desktop module
Message-ID: <5525A269.3040600@oracle.com>

Hello,

Changes to fix all the "missing" doclint warnings in the client 
libraries are out for review (see subtasks of JDK-8071630: "Fix 
remaining doclint warnings in the jdk repo").

Looking ahead to the happy day when all the changes are pushed and 
propagated to jdk9 / dev, please review the patch below to address

     JDK-8075771: Enable "missing" doclint check in build of the 
java.desktop module

diff -r 8f03e7bb692b make/CompileJavaModules.gmk
--- a/make/CompileJavaModules.gmk    Mon Apr 06 10:35:43 2015 -0700
+++ b/make/CompileJavaModules.gmk    Wed Apr 08 14:49:01 2015 -0700
@@ -99,7 +99,7 @@

  ################################################################################

-java.desktop_ADD_JAVAC_FLAGS := 
-Xdoclint:all/protected,-missing,-reference 
'-Xdoclint/package:java.*,javax.*'
+java.desktop_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference 
'-Xdoclint/package:java.*,javax.*'
  java.desktop_COPY := .gif .png .wav .txt .xml .css .pf
  java.desktop_CLEAN := iio-plugin.properties cursors.properties

Thanks,

-Joe


From magnus.ihse.bursie at oracle.com  Thu Apr  9 13:56:13 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 09 Apr 2015 15:56:13 +0200
Subject: RFR(S): JDK-8077137 Port jdk.internal.instrumentation to jdk
 9
In-Reply-To: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
References: <4F138486-8212-405A-8C5A-72E5C33F8002@oracle.com>
Message-ID: <552684FD.2070100@oracle.com>

On 2015-04-08 12:21, Staffan Larsen wrote:
> Please review these small changes to support an addition of closed code to the java.instrument module.
>
> webrev: http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/ <http://cr.openjdk.java.net/~sla/8077137-open/webrev.01/>

Looks good to me.

/Magnus


From magnus.ihse.bursie at oracle.com  Thu Apr  9 14:04:01 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 09 Apr 2015 16:04:01 +0200
Subject: JDK 9 RFR of JDK-8075771: Enable "missing" doclint check in build
	of the java.desktop module
In-Reply-To: <5525A269.3040600@oracle.com>
References: <5525A269.3040600@oracle.com>
Message-ID: <552686D1.2050407@oracle.com>

On 2015-04-08 23:49, joe darcy wrote:
> Hello,
>
> Changes to fix all the "missing" doclint warnings in the client 
> libraries are out for review (see subtasks of JDK-8071630: "Fix 
> remaining doclint warnings in the jdk repo").
>
> Looking ahead to the happy day when all the changes are pushed and 
> propagated to jdk9 / dev, please review the patch below to address

Looks good to me.

Once again, thanks for all this cleaning up work.

/Magnus
>
>     JDK-8075771: Enable "missing" doclint check in build of the 
> java.desktop module
>
> diff -r 8f03e7bb692b make/CompileJavaModules.gmk
> --- a/make/CompileJavaModules.gmk    Mon Apr 06 10:35:43 2015 -0700
> +++ b/make/CompileJavaModules.gmk    Wed Apr 08 14:49:01 2015 -0700
> @@ -99,7 +99,7 @@
>
>  ################################################################################ 
>
>
> -java.desktop_ADD_JAVAC_FLAGS := 
> -Xdoclint:all/protected,-missing,-reference 
> '-Xdoclint/package:java.*,javax.*'
> +java.desktop_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference 
> '-Xdoclint/package:java.*,javax.*'
>  java.desktop_COPY := .gif .png .wav .txt .xml .css .pf
>  java.desktop_CLEAN := iio-plugin.properties cursors.properties
>
> Thanks,
>
> -Joe



From magnus.ihse.bursie at oracle.com  Thu Apr  9 14:07:55 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 09 Apr 2015 16:07:55 +0200
Subject: RFR: JDK-8073634: Improve clean targets
In-Reply-To: <5524F25B.6000102@oracle.com>
References: <551D3E95.8030804@oracle.com> <5523BEC8.3060902@oracle.com>
	<5524F25B.6000102@oracle.com>
Message-ID: <552687BB.3020501@oracle.com>

On 2015-04-08 11:18, Erik Joelsson wrote:
> Hello,
>
> New webrev: http://cr.openjdk.java.net/~erikj/8073634/webrev.02/

Looks good to me now.

>
> On 2015-04-07 13:26, Magnus Ihse Bursie wrote:
>> In general it looks good. I have a couple of remarks, though.
>>
>> 1) In Clean-docs, you do:
>> +        $(RM) -r $(SUPPORT_OUTPUTDIR)/docs
>> +        $(RM) -r $(IMAGES_OUTPUTDIR)/docs
>>
>> I'm not quite certain cleaning images/docs the right thing to do. For 
>> all other clean targets, we only clean the support part. If we want 
>> to clean images, we run clean-images. And if you think this is the 
>> right thing to do for images, wouldn't it then also be the right 
>> thing for e.g. java.base-native? And then things quickly become 
>> complicated.
>>
> The docs target generates docs directly into images. The directory in 
> support is for temporary/intermediate files. Building to support and 
> then just copy it all over to images seems like a waste of both time 
> and disk space. Also note that the clean targets aren't mutually 
> exclusive today. You can for example do clean-support or you can do 
> clean-java.base.

Alright.

>> 2) The new configure-support, as well as the rather new make-support 
>> seems to be a bit unfairly treated. There is a MAKESUPPORT_OUTPUTDIR 
>> in spec.gmk but it's hardcoded there, so you can't use it in 
>> configure, e.g. in your changes in build-performance.m4. The new 
>> configure-support does not even have a corresponding 
>> CONFIGURESUPPORT_OUTPUTDIR in the spec.gmk. Instead, it has a 
>> variable CONFIGURE_SUPPORT that is present only in the configure files.
>>
>> I'm not sure how much, if anything, of these inconsistencies that 
>> should be fixed now. But I'd suggest that you rename 
>> CONFIGURE_SUPPORT to CONFIGURESUPPORT_OUTPUTDIR at the very least. 
>> (Or, maybe, MAKESUPPORT_OUTPUTDIR should be MAKE_SUPPORT_OUTPUTDIR.)
>>
> Renamed to CONFIGURESUPPORT_OUTPUTDIR and put it in spec. Removed 
> reference to make-support in configure and put the single use directly 
> in spec.gmk.in instead. There is no need for configure to know about 
> the sjavacservers dir. Changed dist-clean in Main.gmk to use the 
> variable CONFIGURESUPPORT_OUTPUTDIR.
Great!

/Magnus



From peter.brunet at oracle.com  Fri Apr 10 12:41:14 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Fri, 10 Apr 2015 07:41:14 -0500
Subject: <AWT Dev> RfR JDK-8055160
In-Reply-To: <551F3210.6000203@oracle.com>
References: <5507429B.1090300@oracle.com>
	<55077FEB.20101@oracle.com>	<5507E910.9090200@oracle.com>
	<550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com>
	<550B71F2.60906@oracle.com> <55108897.7000703@oracle.com>
	<551EFF4E.1070007@oracle.com> <551F3210.6000203@oracle.com>
Message-ID: <5527C4EA.5080302@oracle.com>

I should have cross posted to build-dev.  There is one make change to
remove a properties file which is no longer needed.

On 4/3/15 7:36 PM, Mandy Chung wrote:
> On 4/3/2015 1:59 PM, Pete Brunet wrote:
>> Due to the recent push of JDK-8076182 (Open source Java Access
>> Bridge) which exposed some files that were in closed the webrev needs
>> a full re-review.  I've also made the changes requested by Mandy.
>>
>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/
>>
>
> Looks okay.   The copyright header in the new jdk.accessibility files
> need fixing.
>
> Thanks
> Mandy



From magnus.ihse.bursie at oracle.com  Fri Apr 10 13:15:09 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 10 Apr 2015 15:15:09 +0200
Subject: <AWT Dev> RfR JDK-8055160
In-Reply-To: <5527C4EA.5080302@oracle.com>
References: <5507429B.1090300@oracle.com>	<55077FEB.20101@oracle.com>	<5507E910.9090200@oracle.com>	<550893B9.7050003@oracle.com>
	<55089B98.1000206@oracle.com>	<550B71F2.60906@oracle.com>
	<55108897.7000703@oracle.com>	<551EFF4E.1070007@oracle.com>
	<551F3210.6000203@oracle.com> <5527C4EA.5080302@oracle.com>
Message-ID: <5527CCDD.4080602@oracle.com>

On 2015-04-10 14:41, Pete Brunet wrote:
> I should have cross posted to build-dev.  There is one make change to
> remove a properties file which is no longer needed.

Looks good to me.

/Magnus
>
> On 4/3/15 7:36 PM, Mandy Chung wrote:
>> On 4/3/2015 1:59 PM, Pete Brunet wrote:
>>> Due to the recent push of JDK-8076182 (Open source Java Access
>>> Bridge) which exposed some files that were in closed the webrev needs
>>> a full re-review.  I've also made the changes requested by Mandy.
>>>
>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/
>>>
>> Looks okay.   The copyright header in the new jdk.accessibility files
>> need fixing.
>>
>> Thanks
>> Mandy



From philip.race at oracle.com  Fri Apr 10 22:39:22 2015
From: philip.race at oracle.com (Phil Race)
Date: Fri, 10 Apr 2015 15:39:22 -0700
Subject: jdk9 windows build failure
Message-ID: <5528511A.7090003@oracle.com>

For some time (a couple of weeks) I have run into the following error 
whenever I try to build on Windows on my system
I've been using forever ..  I have worked around it by doing builds 
using JPRT but its getting annoying.
Does anyone have a clue what I am doing wrong. This happens on brand new 
clean forests etc.

make[3]: *** No rule to make target 
`/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
needed by 
`/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'. 
Stop.
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [jdk.xml.bind-java] Error 1
make[2]: *** Waiting for unfinished jobs....
make[3]: *** No rule to make target 
`/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
needed by 
`/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'. 
Stop.
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [java.xml.ws-java] Error 1

-phil.


From martijnverburg at gmail.com  Sun Apr 12 15:01:36 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Sun, 12 Apr 2015 16:01:36 +0100
Subject: BSD variables not declared? (jdk8 & jdk 9 builds)
Message-ID: <CAP7YuAROCv3p+=7wQ6Rfsrxm3yCb0ZvzUCzbZoFji2oM0Ht41A@mail.gmail.com>

Hi all,

On Mac OS X 10.10.2 using gcc 4.8 run make clean images

When compiling either jdk8 or jdk9 from scratch I get the following BSD
undefined errors:

Compiling
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1150:7:
error: "__FreeBSD__" is not defined [-Werror=undef]
 #elif __FreeBSD__
       ^
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1152:7:
error: "__OpenBSD__" is not defined [-Werror=undef]
 #elif __OpenBSD__
       ^
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1154:7:
error: "__NetBSD__" is not defined [-Werror=undef]
 #elif __NetBSD__
       ^



Cheers,
Martijn


From erik.joelsson at oracle.com  Mon Apr 13 06:07:03 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 13 Apr 2015 08:07:03 +0200
Subject: RFR: JDK-8077563: 9-dev 1-prebuild fail: "configure: error: write
	failure creating /config.status"
Message-ID: <552B5D07.3030908@oracle.com>

Hello,

Please review this fix for configure when running from a custom output 
directory. In JDK-8073634, I messed up only defined 
CONFIGURESUPPORT_OUTPUTDIR when --with-conf-name was used or the default 
value for it was used, not when defining it by running configure from a 
new directory.

The fix is pretty simple, just move the definition of 
CONFIGURESUPPORT_OUTPUTDIR a bit further down when OUTPUT_DIR is always 
properly defined first.

Bug: https://bugs.openjdk.java.net/browse/JDK-8077563
Patch:
diff -r 9fa2185bee17 common/autoconf/basics.m4
--- a/common/autoconf/basics.m4
+++ b/common/autoconf/basics.m4
@@ -658,8 +658,6 @@
      fi
      OUTPUT_ROOT="$SRC_ROOT/build/${CONF_NAME}"
      $MKDIR -p "$OUTPUT_ROOT"
-    CONFIGURESUPPORT_OUTPUTDIR="$OUTPUT_ROOT/configure-support"
-    $MKDIR -p "$CONFIGURESUPPORT_OUTPUTDIR"
      if test ! -d "$OUTPUT_ROOT"; then
        AC_MSG_ERROR([Could not create build directory $OUTPUT_ROOT])
      fi
@@ -702,6 +700,9 @@

    BASIC_FIXUP_PATH(OUTPUT_ROOT)

+  CONFIGURESUPPORT_OUTPUTDIR="$OUTPUT_ROOT/configure-support"
+  $MKDIR -p "$CONFIGURESUPPORT_OUTPUTDIR"
+
    AC_SUBST(SPEC, $OUTPUT_ROOT/spec.gmk)
    AC_SUBST(CONF_NAME, $CONF_NAME)
    AC_SUBST(OUTPUT_ROOT, $OUTPUT_ROOT)

/Erik


From david.holmes at oracle.com  Mon Apr 13 06:15:09 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 13 Apr 2015 16:15:09 +1000
Subject: RFR: JDK-8077563: 9-dev 1-prebuild fail: "configure: error: write
	failure creating /config.status"
In-Reply-To: <552B5D07.3030908@oracle.com>
References: <552B5D07.3030908@oracle.com>
Message-ID: <552B5EED.10302@oracle.com>

On 13/04/2015 4:07 PM, Erik Joelsson wrote:
> Hello,
>
> Please review this fix for configure when running from a custom output
> directory. In JDK-8073634, I messed up only defined
> CONFIGURESUPPORT_OUTPUTDIR when --with-conf-name was used or the default
> value for it was used, not when defining it by running configure from a
> new directory.
>
> The fix is pretty simple, just move the definition of
> CONFIGURESUPPORT_OUTPUTDIR a bit further down when OUTPUT_DIR is always
> properly defined first.

Yep that'll work too :)

Reviewed.

Thanks,
David

> Bug: https://bugs.openjdk.java.net/browse/JDK-8077563
> Patch:
> diff -r 9fa2185bee17 common/autoconf/basics.m4
> --- a/common/autoconf/basics.m4
> +++ b/common/autoconf/basics.m4
> @@ -658,8 +658,6 @@
>       fi
>       OUTPUT_ROOT="$SRC_ROOT/build/${CONF_NAME}"
>       $MKDIR -p "$OUTPUT_ROOT"
> -    CONFIGURESUPPORT_OUTPUTDIR="$OUTPUT_ROOT/configure-support"
> -    $MKDIR -p "$CONFIGURESUPPORT_OUTPUTDIR"
>       if test ! -d "$OUTPUT_ROOT"; then
>         AC_MSG_ERROR([Could not create build directory $OUTPUT_ROOT])
>       fi
> @@ -702,6 +700,9 @@
>
>     BASIC_FIXUP_PATH(OUTPUT_ROOT)
>
> +  CONFIGURESUPPORT_OUTPUTDIR="$OUTPUT_ROOT/configure-support"
> +  $MKDIR -p "$CONFIGURESUPPORT_OUTPUTDIR"
> +
>     AC_SUBST(SPEC, $OUTPUT_ROOT/spec.gmk)
>     AC_SUBST(CONF_NAME, $CONF_NAME)
>     AC_SUBST(OUTPUT_ROOT, $OUTPUT_ROOT)
>
> /Erik


From erik.joelsson at oracle.com  Mon Apr 13 06:34:14 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 13 Apr 2015 08:34:14 +0200
Subject: jdk9 windows build failure
In-Reply-To: <5528511A.7090003@oracle.com>
References: <5528511A.7090003@oracle.com>
Message-ID: <552B6366.7000306@oracle.com>

That looks weird. What does your 
/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/make-support/module-deps.gmk 
look like? What happens if you do "make java.xml.bind-java"? Exactly how 
did you run make to have this happen?

/Erik

On 2015-04-11 00:39, Phil Race wrote:
> For some time (a couple of weeks) I have run into the following error 
> whenever I try to build on Windows on my system
> I've been using forever ..  I have worked around it by doing builds 
> using JPRT but its getting annoying.
> Does anyone have a clue what I am doing wrong. This happens on brand 
> new clean forests etc.
>
> make[3]: *** No rule to make target 
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
> needed by 
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'. 
> Stop.
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [jdk.xml.bind-java] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[3]: *** No rule to make target 
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
> needed by 
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'. 
> Stop.
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [java.xml.ws-java] Error 1
>
> -phil.



From david.holmes at oracle.com  Mon Apr 13 06:52:39 2015
From: david.holmes at oracle.com (David Holmes)
Date: Mon, 13 Apr 2015 16:52:39 +1000
Subject: Implicit make target for BUILD_GENMODULESLIST ?
Message-ID: <552B67B7.9080004@oracle.com>

If I create a new configuration and then run make for a non-existent target:

make not_a_target

It still shows:

Compiling 5 files for BUILD_GENMODULESLIST

Why? If I don't give a valid make target then nothing should happen.

David


From volker.simonis at gmail.com  Mon Apr 13 09:58:52 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 13 Apr 2015 11:58:52 +0200
Subject: jdk9 windows build failure
In-Reply-To: <5528511A.7090003@oracle.com>
References: <5528511A.7090003@oracle.com>
Message-ID: <CA+3eh12S+0zLKnUcn_aerHdX0KK-tc46hs4rK2g=+sgps4hbCw@mail.gmail.com>

Hi Phil,

are you sure this is the first error?

Can you start a new, clean build with only one build job and post
both, the configure line and output along with the build log (at least
LOG=debug).

Have you changed you Cygwin version or are you using a new
disk/network share for your sources/output directory?

I recently had two Windows build problems:

 - wrong files permission. This could be solved by adding the 'noacl'
option to the list of default mount options in /etc/fstab of your
Cygwin installation.
 - I had  "multiple target patterns" failures which only appeared if
using Cygwin make version less than 4.1.

But both these problems can be at least partially related to our own,
modified build environment.

Regards,
Volker

On Sat, Apr 11, 2015 at 12:39 AM, Phil Race <philip.race at oracle.com> wrote:
> For some time (a couple of weeks) I have run into the following error
> whenever I try to build on Windows on my system
> I've been using forever ..  I have worked around it by doing builds using
> JPRT but its getting annoying.
> Does anyone have a clue what I am doing wrong. This happens on brand new
> clean forests etc.
>
> make[3]: *** No rule to make target
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch',
> needed by
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'.
> Stop.
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [jdk.xml.bind-java] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[3]: *** No rule to make target
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch',
> needed by
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'.
> Stop.
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [java.xml.ws-java] Error 1
>
> -phil.


From erik.joelsson at oracle.com  Mon Apr 13 13:25:26 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 13 Apr 2015 15:25:26 +0200
Subject: RFR: JDK-8077419: Launcher mapfile fails linking with SS12u4
Message-ID: <552BC3C6.2080409@oracle.com>

Hello,

When building JDK 9 with Solaris Studio 12u4, linking of unpack200 and 
the java launchers fails due to symbols not being exported. A typical 
error message looks like this:

Undefined first referenced
  symbol in file
__environ_lock 
/net/sthserver02/share/sundevtools/devtools/i586/devkit/SS12u4-Solaris11u1/SS12u4-slim/lib/compilers/amd64/crt1x.o 
(symbol has no version assigned)

The fix seems to be to add these symbols to the mapfiles.

I also noted that the format of the make dependency files generated by 
the compiler is slightly different which required a small adjustment to 
our rewriting logic for them to remove leading whitespace.

Bug: https://bugs.openjdk.java.net/browse/JDK-8077419
Webrev: http://cr.openjdk.java.net/~erikj/8077419/webrev.01/

/Erik


From erik.joelsson at oracle.com  Mon Apr 13 13:32:28 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 13 Apr 2015 15:32:28 +0200
Subject: Implicit make target for BUILD_GENMODULESLIST ?
In-Reply-To: <552B67B7.9080004@oracle.com>
References: <552B67B7.9080004@oracle.com>
Message-ID: <552BC56C.4060202@oracle.com>

Hello,

Previously that happened without anything showing. I thought that was 
wrong so when Magnus rewrote the bootstrapping logic, I encouraged him 
to have that show so that it was clear that something happened. Also, it 
makes it easier to debug if something goes wrong there.

The reason that is being built is that we need that tool to calculate 
the modules and their dependencies, which is used to calculate the valid 
make targets. We are hoping to be able to calculate this without the 
need for a java tool later in JDK 9, but for now, the information is in 
modules.xml so a java tool is just the simplest solution.

If you are curious as to how this happens, the logic is in 
make/common/Modules.gmk. That file both includes module-deps.gmk and 
provides a rule for how to build it. When make sees that, it will try to 
build it, then restart and include it. It won't know that you provided 
an invalid target until this has happened.

/Erik

On 2015-04-13 08:52, David Holmes wrote:
> If I create a new configuration and then run make for a non-existent 
> target:
>
> make not_a_target
>
> It still shows:
>
> Compiling 5 files for BUILD_GENMODULESLIST
>
> Why? If I don't give a valid make target then nothing should happen.
>
> David



From james.laskey at oracle.com  Mon Apr 13 14:22:32 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Mon, 13 Apr 2015 11:22:32 -0300
Subject: clang 6.1 inteference
Message-ID: <B65DCED8-BE81-49C7-9325-6C1FD666E13B@oracle.com>

Run into an issue after upgrade to clang 6.1

/Volumes/Elephant/Projects/sandbox/hotspot/src/share/vm/opto/chaitin.cpp:2098:8: error: 'this' pointer cannot be null in well-defined C++ code; pointer may be assumed to always convert to true [-Werror,-Wundefined-bool-conversion]
  if( !this ) {                 // Not got anything?
      ~^~~~
1 error generated.



Also note

diff -r 7611110f9367 make/bsd/makefiles/gcc.make
--- a/make/bsd/makefiles/gcc.make	Mon Apr 13 10:48:47 2015 -0300
+++ b/make/bsd/makefiles/gcc.make	Mon Apr 13 11:20:15 2015 -0300
@@ -325,10 +325,13 @@
   else ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 1), 1)
     OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT)
     OPT_CFLAGS/unsafe.o += -O1
-  # Clang 6.0 
-  else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 0), 1) 
-    OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT) 
-    OPT_CFLAGS/unsafe.o += -O1 
+  # Clang 6.0
+  else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 0), 1)
+    OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT)
+    OPT_CFLAGS/unsafe.o += -O1
+  else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 1), 1)
+    OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT)
+    OPT_CFLAGS/unsafe.o += -O1
   else
     $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)")
   endif





From chris.hegarty at oracle.com  Mon Apr 13 14:34:14 2015
From: chris.hegarty at oracle.com (Chris Hegarty)
Date: Mon, 13 Apr 2015 15:34:14 +0100
Subject: clang 6.1 inteference
In-Reply-To: <B65DCED8-BE81-49C7-9325-6C1FD666E13B@oracle.com>
References: <B65DCED8-BE81-49C7-9325-6C1FD666E13B@oracle.com>
Message-ID: <552BD3E6.2090502@oracle.com>

Is this another sighting of 
https://bugs.openjdk.java.net/browse/JDK-8077364 ?

-Chris.

On 13/04/15 15:22, Jim Laskey (Oracle) wrote:
> Run into an issue after upgrade to clang 6.1
>
> /Volumes/Elephant/Projects/sandbox/hotspot/src/share/vm/opto/chaitin.cpp:2098:8: error: 'this' pointer cannot be null in well-defined C++ code; pointer may be assumed to always convert to true [-Werror,-Wundefined-bool-conversion]
>    if( !this ) {                 // Not got anything?
>        ~^~~~
> 1 error generated.
>
>
>
> Also note
>
> diff -r 7611110f9367 make/bsd/makefiles/gcc.make
> --- a/make/bsd/makefiles/gcc.make	Mon Apr 13 10:48:47 2015 -0300
> +++ b/make/bsd/makefiles/gcc.make	Mon Apr 13 11:20:15 2015 -0300
> @@ -325,10 +325,13 @@
>     else ifeq ($(shell expr $(CC_VER_MAJOR) = 5 \& $(CC_VER_MINOR) = 1), 1)
>       OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT)
>       OPT_CFLAGS/unsafe.o += -O1
> -  # Clang 6.0
> -  else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 0), 1)
> -    OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT)
> -    OPT_CFLAGS/unsafe.o += -O1
> +  # Clang 6.0
> +  else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 0), 1)
> +    OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT)
> +    OPT_CFLAGS/unsafe.o += -O1
> +  else ifeq ($(shell expr $(CC_VER_MAJOR) = 6 \& $(CC_VER_MINOR) = 1), 1)
> +    OPT_CFLAGS/loopTransform.o += $(OPT_CFLAGS/NOOPT)
> +    OPT_CFLAGS/unsafe.o += -O1
>     else
>       $(error "Update compiler workarounds for Clang $(CC_VER_MAJOR).$(CC_VER_MINOR)")
>     endif
>
>
>


From tim.bell at oracle.com  Mon Apr 13 14:38:06 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 13 Apr 2015 07:38:06 -0700
Subject: RFR: JDK-8077563: 9-dev 1-prebuild fail: "configure: error: write
	failure creating /config.status"
In-Reply-To: <552B5EED.10302@oracle.com>
References: <552B5D07.3030908@oracle.com> <552B5EED.10302@oracle.com>
Message-ID: <552BD4CE.4020705@oracle.com>

Erik:

>> Please review this fix for configure when running from a custom output
>> directory. In JDK-8073634, I messed up only defined
>> CONFIGURESUPPORT_OUTPUTDIR when --with-conf-name was used or the default
>> value for it was used, not when defining it by running configure from a
>> new directory.
>>
>> The fix is pretty simple, just move the definition of
>> CONFIGURESUPPORT_OUTPUTDIR a bit further down when OUTPUT_DIR is always
>> properly defined first.
>
> Yep that'll work too :)
>
> Reviewed.
>
> Thanks,
> David

Looks good to me as well.

/Tim

>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077563
>> Patch:
>> diff -r 9fa2185bee17 common/autoconf/basics.m4
>> --- a/common/autoconf/basics.m4
>> +++ b/common/autoconf/basics.m4
>> @@ -658,8 +658,6 @@
>>       fi
>>       OUTPUT_ROOT="$SRC_ROOT/build/${CONF_NAME}"
>>       $MKDIR -p "$OUTPUT_ROOT"
>> -    CONFIGURESUPPORT_OUTPUTDIR="$OUTPUT_ROOT/configure-support"
>> -    $MKDIR -p "$CONFIGURESUPPORT_OUTPUTDIR"
>>       if test ! -d "$OUTPUT_ROOT"; then
>>         AC_MSG_ERROR([Could not create build directory $OUTPUT_ROOT])
>>       fi
>> @@ -702,6 +700,9 @@
>>
>>     BASIC_FIXUP_PATH(OUTPUT_ROOT)
>>
>> +  CONFIGURESUPPORT_OUTPUTDIR="$OUTPUT_ROOT/configure-support"
>> +  $MKDIR -p "$CONFIGURESUPPORT_OUTPUTDIR"
>> +
>>     AC_SUBST(SPEC, $OUTPUT_ROOT/spec.gmk)
>>     AC_SUBST(CONF_NAME, $CONF_NAME)
>>     AC_SUBST(OUTPUT_ROOT, $OUTPUT_ROOT)
>>
>> /Erik



From tim.bell at oracle.com  Mon Apr 13 14:44:31 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Mon, 13 Apr 2015 07:44:31 -0700
Subject: RFR: JDK-8077419: Launcher mapfile fails linking with SS12u4
In-Reply-To: <552BC3C6.2080409@oracle.com>
References: <552BC3C6.2080409@oracle.com>
Message-ID: <552BD64F.6000702@oracle.com>

Erik:

> When building JDK 9 with Solaris Studio 12u4, linking of unpack200 and 
> the java launchers fails due to symbols not being exported. A typical 
> error message looks like this:
>
> Undefined first referenced
>  symbol in file
> __environ_lock 
> /net/sthserver02/share/sundevtools/devtools/i586/devkit/SS12u4-Solaris11u1/SS12u4-slim/lib/compilers/amd64/crt1x.o 
> (symbol has no version assigned)
>
> The fix seems to be to add these symbols to the mapfiles.
>
> I also noted that the format of the make dependency files generated by 
> the compiler is slightly different which required a small adjustment 
> to our rewriting logic for them to remove leading whitespace.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8077419
> Webrev: http://cr.openjdk.java.net/~erikj/8077419/webrev.01/

Looks good to me.

/Tim



From david.holmes at oracle.com  Tue Apr 14 01:44:50 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 14 Apr 2015 11:44:50 +1000
Subject: RFR: JDK-8077419: Launcher mapfile fails linking with SS12u4
In-Reply-To: <552BC3C6.2080409@oracle.com>
References: <552BC3C6.2080409@oracle.com>
Message-ID: <552C7112.4030004@oracle.com>

Hi Erik,

On 13/04/2015 11:25 PM, Erik Joelsson wrote:
> Hello,
>
> When building JDK 9 with Solaris Studio 12u4, linking of unpack200 and
> the java launchers fails due to symbols not being exported. A typical
> error message looks like this:
>
> Undefined first referenced
>   symbol in file
> __environ_lock
> /net/sthserver02/share/sundevtools/devtools/i586/devkit/SS12u4-Solaris11u1/SS12u4-slim/lib/compilers/amd64/crt1x.o
> (symbol has no version assigned)
>
> The fix seems to be to add these symbols to the mapfiles.

I'm perplexed - what are these symbols and why are we exporting them ?? 
I see we already had __environ_lock on x86, but I can't actually find 
these in our source code (environ_lock, longdouble_used).

David

> I also noted that the format of the make dependency files generated by
> the compiler is slightly different which required a small adjustment to
> our rewriting logic for them to remove leading whitespace.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8077419
> Webrev: http://cr.openjdk.java.net/~erikj/8077419/webrev.01/
>
> /Erik


From magnus.ihse.bursie at oracle.com  Tue Apr 14 07:24:16 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 14 Apr 2015 09:24:16 +0200
Subject: BSD variables not declared? (jdk8 & jdk 9 builds)
In-Reply-To: <CAP7YuAROCv3p+=7wQ6Rfsrxm3yCb0ZvzUCzbZoFji2oM0Ht41A@mail.gmail.com>
References: <CAP7YuAROCv3p+=7wQ6Rfsrxm3yCb0ZvzUCzbZoFji2oM0Ht41A@mail.gmail.com>
Message-ID: <552CC0A0.8090206@oracle.com>

On 2015-04-12 17:01, Martijn Verburg wrote:
> Hi all,
>
> On Mac OS X 10.10.2 using gcc 4.8 run make clean images
>
> When compiling either jdk8 or jdk9 from scratch I get the following BSD
> undefined errors:
>
> Compiling
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1150:7:
> error: "__FreeBSD__" is not defined [-Werror=undef]
>   #elif __FreeBSD__
>         ^
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1152:7:
> error: "__OpenBSD__" is not defined [-Werror=undef]
>   #elif __OpenBSD__
>         ^
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1154:7:
> error: "__NetBSD__" is not defined [-Werror=undef]
>   #elif __NetBSD__

That sounds strange. Why would an undefined preprocessor variable 
trigger an error? I have never heard about this before.

Since it is in hotspot code, maybe you can get a better response by 
asking on a hotspot list.

/Magnus


From magnus.ihse.bursie at oracle.com  Tue Apr 14 07:29:22 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 14 Apr 2015 09:29:22 +0200
Subject: jdk9 windows build failure
In-Reply-To: <5528511A.7090003@oracle.com>
References: <5528511A.7090003@oracle.com>
Message-ID: <552CC1D2.6030908@oracle.com>

On 2015-04-11 00:39, Phil Race wrote:
> For some time (a couple of weeks) I have run into the following error 
> whenever I try to build on Windows on my system
> I've been using forever ..  I have worked around it by doing builds 
> using JPRT but its getting annoying.
> Does anyone have a clue what I am doing wrong. This happens on brand 
> new clean forests etc.
>
> make[3]: *** No rule to make target 
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
> needed by 
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'. 
> Stop.
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [jdk.xml.bind-java] Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[3]: *** No rule to make target 
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
> needed by 
> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'. 
> Stop.
> make[3]: *** Waiting for unfinished jobs....
> make[2]: *** [java.xml.ws-java] Error 1

It sounds like you have tested the three-stage more effective 
sledgehammer technique:
1) make clean
2) make dist-clean
3) make a new clone from hg.openjdk.java.net

If you say this happens recently, there might have been a change 
(backported to jdk8, as well, apparently) that triggered this. What 
happens if you update the forest not at the tip, but at some point in 
time some months ago, before the symptoms started to appear? Be sure to 
do a make clean or make dist-clean before building after going back in 
time, just to be sure.

/Magnus


From erik.joelsson at oracle.com  Tue Apr 14 07:41:50 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 14 Apr 2015 09:41:50 +0200
Subject: RFR: JDK-8077419: Launcher mapfile fails linking with SS12u4
In-Reply-To: <552C7112.4030004@oracle.com>
References: <552BC3C6.2080409@oracle.com> <552C7112.4030004@oracle.com>
Message-ID: <552CC4BE.8000604@oracle.com>


On 2015-04-14 03:44, David Holmes wrote:
> Hi Erik,
>
> On 13/04/2015 11:25 PM, Erik Joelsson wrote:
>> Hello,
>>
>> When building JDK 9 with Solaris Studio 12u4, linking of unpack200 and
>> the java launchers fails due to symbols not being exported. A typical
>> error message looks like this:
>>
>> Undefined first referenced
>>   symbol in file
>> __environ_lock
>> /net/sthserver02/share/sundevtools/devtools/i586/devkit/SS12u4-Solaris11u1/SS12u4-slim/lib/compilers/amd64/crt1x.o 
>>
>> (symbol has no version assigned)
>>
>> The fix seems to be to add these symbols to the mapfiles.
>
> I'm perplexed - what are these symbols and why are we exporting them 
> ?? I see we already had __environ_lock on x86, but I can't actually 
> find these in our source code (environ_lock, longdouble_used).
>
I don't know. I suspect that these are implicitly created by the 
compiler and in SS12u4, the implicitly linked lib/obj files suddenly 
need access to them. Perhaps we should try to ask the SS compiler team 
for clarification? My googling couldn't find a better answer at least.

/Erik

> David
>
>> I also noted that the format of the make dependency files generated by
>> the compiler is slightly different which required a small adjustment to
>> our rewriting logic for them to remove leading whitespace.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077419
>> Webrev: http://cr.openjdk.java.net/~erikj/8077419/webrev.01/
>>
>> /Erik



From david.holmes at oracle.com  Tue Apr 14 07:42:53 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 14 Apr 2015 17:42:53 +1000
Subject: BSD variables not declared? (jdk8 & jdk 9 builds)
In-Reply-To: <552CC0A0.8090206@oracle.com>
References: <CAP7YuAROCv3p+=7wQ6Rfsrxm3yCb0ZvzUCzbZoFji2oM0Ht41A@mail.gmail.com>
	<552CC0A0.8090206@oracle.com>
Message-ID: <552CC4FD.4010904@oracle.com>

On 14/04/2015 5:24 PM, Magnus Ihse Bursie wrote:
> On 2015-04-12 17:01, Martijn Verburg wrote:
>> Hi all,
>>
>> On Mac OS X 10.10.2 using gcc 4.8 run make clean images
>>
>> When compiling either jdk8 or jdk9 from scratch I get the following BSD
>> undefined errors:
>>
>> Compiling
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp
>>
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1150:7:
>>
>> error: "__FreeBSD__" is not defined [-Werror=undef]
>>   #elif __FreeBSD__
>>         ^
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1152:7:
>>
>> error: "__OpenBSD__" is not defined [-Werror=undef]
>>   #elif __OpenBSD__
>>         ^
>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1154:7:
>>
>> error: "__NetBSD__" is not defined [-Werror=undef]
>>   #elif __NetBSD__
>
> That sounds strange. Why would an undefined preprocessor variable
> trigger an error? I have never heard about this before.

"-Wundef option causes GCC to warn whenever it encounters an identifier 
which is not a macro in an ?#if?. "

Hence we should be using

#elif defined(__FreeBSD__)

etc in this context. It may be the compiler normally doesn't look at the 
erroneous else cases, but this compiler does (or else __APPLE__ is not 
defined and so we hit these else cases where we don't normally.) ??

> Since it is in hotspot code, maybe you can get a better response by
> asking on a hotspot list.

Yes looks like a hotspot issue. I filed:

https://bugs.openjdk.java.net/browse/JDK-8077674

Follow ups on hotspot-runtime-dev please.

David

> /Magnus


From prasanta.sadhukhan at oracle.com  Tue Apr 14 07:54:25 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Tue, 14 Apr 2015 13:24:25 +0530
Subject: jdk9 windows build failure
In-Reply-To: <CA+3eh12S+0zLKnUcn_aerHdX0KK-tc46hs4rK2g=+sgps4hbCw@mail.gmail.com>
References: <5528511A.7090003@oracle.com>
	<CA+3eh12S+0zLKnUcn_aerHdX0KK-tc46hs4rK2g=+sgps4hbCw@mail.gmail.com>
Message-ID: <552CC7B1.7040307@oracle.com>

Hi All,

I also faced this problem when I update my forest through "sh 
get_source.sh" and run "configure", "make clean" followed by "make"

    Creating library jvm.lib and object jvm.exp
LINK : fatal error LNK1123: failure during conversion to COFF: file 
invalid or corrupt
NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : 
return code '0x463'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual 
Studio 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
Stop.
make[5]: *** [generic_build2] Error 2
Makefile:230: recipe for target 'generic_build2' failed
Makefile:177: recipe for target 'product' failed
make[4]: *** [product] Error 2
HotspotWrapper.gmk:44: recipe for target 
'/cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp' 
failed
make[3]: *** 
[/cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp] 
Error 1
make[2]: *** [hotspot] Error 1
make/Main.gmk:193: recipe for target 'hotspot' failed
make[2]: *** Waiting for unfinished jobs....

Regards
Prasanta
On 4/13/2015 3:28 PM, Volker Simonis wrote:
> Hi Phil,
>
> are you sure this is the first error?
>
> Can you start a new, clean build with only one build job and post
> both, the configure line and output along with the build log (at least
> LOG=debug).
>
> Have you changed you Cygwin version or are you using a new
> disk/network share for your sources/output directory?
>
> I recently had two Windows build problems:
>
>   - wrong files permission. This could be solved by adding the 'noacl'
> option to the list of default mount options in /etc/fstab of your
> Cygwin installation.
>   - I had  "multiple target patterns" failures which only appeared if
> using Cygwin make version less than 4.1.
>
> But both these problems can be at least partially related to our own,
> modified build environment.
>
> Regards,
> Volker
>
> On Sat, Apr 11, 2015 at 12:39 AM, Phil Race <philip.race at oracle.com> wrote:
>> For some time (a couple of weeks) I have run into the following error
>> whenever I try to build on Windows on my system
>> I've been using forever ..  I have worked around it by doing builds using
>> JPRT but its getting annoying.
>> Does anyone have a clue what I am doing wrong. This happens on brand new
>> clean forests etc.
>>
>> make[3]: *** No rule to make target
>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch',
>> needed by
>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'.
>> Stop.
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [jdk.xml.bind-java] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> make[3]: *** No rule to make target
>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch',
>> needed by
>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'.
>> Stop.
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [java.xml.ws-java] Error 1
>>
>> -phil.

-------------- next part --------------
Creating data for first make execution in new configuration...
Done
Building target(s) 'default' in configuration 'windows-x86-normal-server-release'
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Compiling 5 properties into resource bundles for jdk.dev
Parsing 1 properties into enum-like class for jdk.compiler
Compiling 10 properties into resource bundles for jdk.javadoc
Compiling 20 properties into resource bundles for jdk.compiler

Compiling 819 files for BUILD_INTERIM_LANGTOOLS

	cd windows_i486_compiler2
	nmake -nologo -f C:\jdk9\client\hotspot\make\windows\makefiles\top.make BUILD_FLAVOR=product ARCH=x86
nmake in ./generated
	cd generated && "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f C:\jdk9\client\hotspot\make\windows\makefiles\generated.make  DIR=.\generated BUILD_FLAVOR=product
	 mkdir -p ../generated/saclasses
...Building sa-jdi.jar into ../generated/saclasses
...C:\jdk1.8.0_31\bin\javac -g -encoding ascii -source 8 -target 8 -classpath C:\jdk1.8.0_31/lib/tools.jar -d ../generated/saclasses ....
	"C:\jdk1.8.0_31\bin\rmic" -classpath ../generated/saclasses -d ../generated/saclasses sun.jvm.hotspot.debugger.remote.RemoteDebuggerServer
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
	 echo sun.jvm.hotspot.runtime.VM.saBuildVersion=1.9.0-internal-prsadhuk_2015_04_13_15_44-b00> ../generated/saclasses/sa.properties
	 rm -f ../generated/saclasses/sun/jvm/hotspot/utilities/soql/sa.js
	 cp C:\jdk9\client\hotspot/agent/src/share/classes/sun/jvm/hotspot/utilities/soql/sa.js ../generated/saclasses/sun/jvm/hotspot/utilities/soql
	 rm -rf ../generated/saclasses/sun/jvm/hotspot/ui/resources
	 mkdir ../generated/saclasses/sun/jvm/hotspot/ui/resources
	 cp C:\jdk9\client\hotspot/agent/src/share/classes/sun/jvm/hotspot/ui/resources/*.png ../generated/saclasses/sun/jvm/hotspot/ui/resources
	 cp -r C:\jdk9\client\hotspot/agent/src/share/classes/images/* ../generated/saclasses
	"C:\jdk1.8.0_31\bin\jar" cf ../generated/sa-jdi.jar -C ../generated/saclasses .
Creating buildtools/interim_langtools.jar
	"C:\jdk1.8.0_31\bin\jar" uf ../generated/sa-jdi.jar -C C:\jdk9\client\hotspot/agent/src/share/classes META-INF/services/com.sun.jdi.connect.Connector
	rm -f x86_32.ad
	cat  C:\jdk9\client\hotspot/src/cpu/x86/vm/x86_32.ad  C:\jdk9\client\hotspot/src/cpu/x86/vm/x86.ad >x86_32.ad
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /D _CRT_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_DEPRECATE /EHsc /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB  /I "..\generated"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /c C:\jdk9\client\hotspot\src\share\vm\adlc\main.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\adlparse.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\archDesc.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\arena.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\dfa.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\dict2.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\filebuff.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\forms.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\formsopt.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\formssel.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\output_c.cpp C:\jdk9\client\hotspot\src\share\vm\adlc\output_h.cpp 
main.cpp
adlparse.cpp
archDesc.cpp
arena.cpp
dfa.cpp
dict2.cpp
filebuff.cpp
Compiling 23 files for BUILD_INTERIM_JIMAGE
forms.cpp
formsopt.cpp
formssel.cpp
Compiling 198 files for BUILD_INTERIM_RMIC
output_c.cpp
output_h.cpp
Compiling 141 files for BUILD_IDLJ
Compiling 161 files for BUILD_TOOLS_JDK
Compiling 6 files for BUILD_TOOLS_CORBA
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /D _CRT_SECURE_NO_WARNINGS /D _CRT_SECURE_NO_DEPRECATE /EHsc /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB  /I "..\generated"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /c C:\jdk9\client\hotspot\src\share\vm\opto\opcodes.cpp 
opcodes.cpp
	C:\progra~2\micros~1.0\vc\bin\link.exe /SAFESEH /manifest  kernel32.lib user32.lib gdi32.lib winspool.lib  comdlg32.lib advapi32.lib shell32.lib ole32.lib oleaut32.lib  uuid.lib Wsock32.lib winmm.lib version.lib /nologo /machine:I386 /opt:REF  /opt:ICF,8 /map /debug psapi.lib /subsystem:console /out:adlc.exe main.obj adlparse.obj archDesc.obj arena.obj dfa.obj dict2.obj filebuff.obj forms.obj formsopt.obj formssel.obj opcodes.obj output_c.obj output_h.obj
	C:\progra~2\mia713~1\windows\v7.0a\bin\mt.exe /manifest adlc.exe.manifest /outputresource:adlc.exe;#1
Microsoft (R) Manifest Tool version 5.2.3790.2076

Copyright (c) Microsoft Corporation 2005. 

All rights reserved.

	rm -f  ad_x86_32.cpp  ad_x86_32.hpp  ad_x86_32_clone.cpp  ad_x86_32_expand.cpp  ad_x86_32_format.cpp  ad_x86_32_gen.cpp  ad_x86_32_misc.cpp  ad_x86_32_peephole.cpp  ad_x86_32_pipeline.cpp  adGlobals_x86_32.hpp  dfa_x86_32.cpp
	if exist adfiles rmdir /s /q adfiles
	mkdir adfiles
	adlc -q -T -U_LP64 x86_32.ad
	mv  ad_x86_32.cpp  ad_x86_32.hpp  ad_x86_32_clone.cpp  ad_x86_32_expand.cpp  ad_x86_32_format.cpp  ad_x86_32_gen.cpp  ad_x86_32_misc.cpp  ad_x86_32_peephole.cpp  ad_x86_32_pipeline.cpp  adGlobals_x86_32.hpp  dfa_x86_32.cpp adfiles/
	"C:\jdk1.8.0_31\bin\javac" -g -encoding ascii -source 8 -target 8 -d jvmtifiles C:\jdk9\client\hotspot/src/share/vm/prims/jvmtiGen.java
Generating jvmtifiles/jvmtiEnv.hpp
Generating jvmtifiles/jvmtiEnter.cpp
Creating sun/util/locale/provider/EnLocaleDataMetaInfo.java from 424 found resources.
Generating jvmtifiles/jvmtiEnterTrace.cpp
Generating jvmtifiles/jvmtiEnvRecommended.cpp
Generating jvmtifiles/bytecodeInterpreterWithChecks.cpp
Generating jvmtifiles/jvmti.h
Generating AltSrc tracefiles/traceEventClasses.hpp
Generating tracefiles/traceEventIds.hpp
Generating tracefiles/traceTypes.hpp
Generating AltSrc tracefiles/traceRequestables.hpp
Generating AltSrc tracefiles/traceEventControl.hpp
Generating AltSrc tracefiles/traceProducer.cpp
Generating sun/misc/Version.java
Compiling 11 properties into resource bundles for java.logging
Creating genSocketOptionRegistry.exe from 1 file(s)
Generating buffer classes
Generating exceptions classes
Compiling 11 properties into resource bundles for java.base
Compiling 22 properties into resource bundles for java.base
Compiling 4 files for BUILD_BREAKITERATOR
Generating blacklisted certs
Generating java.security
Creating support/jce/policy/unlimited/US_export_policy.jar
Generating HTML DTD file
Creating support/jce/policy/limited/local_policy.jar
Compiling 11 properties into resource bundles for java.management
Creating support/jce/policy/unlimited/local_policy.jar
Compiling 1 properties into resource bundles for jdk.dev
Compiling 11 properties into resource bundles for jdk.jartool
Compiling 1687 files for BUILD_INTERIM_CORBA
Creating sun/util/resources/provider/NonEnLocaleDataMetaInfo.java from 424 found resources.
nmake in ./product
	cd product && "C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE" -NOLOGO -f C:\jdk9\client\hotspot\make\windows\makefiles\product.make  DIR=.\product BUILD_FLAVOR=product
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yc"precompiled.hpp" /c ../generated/_build_pch_file.cpp
_build_pch_file.cpp
Compiling 209 properties into resource bundles for jdk.localedata
Creating buildtools/interim_corba.jar
Compiling 1 properties into resource bundles for jdk.snmp
Microsoft (R) Incremental Linker Version 10.00.30319.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Microsoft (R) Windows (R) Resource Compiler Version 6.1.7600.16385

Copyright (C) Microsoft Corporation.  All rights reserved.


	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /D DONT_USE_PRECOMPILED_HEADER /c C:\jdk9\client\hotspot\src\share\vm\interpreter\bytecodeInterpreter.cpp
bytecodeInterpreter.cpp
Generating Nimbus source files
Compiling 100 properties into resource bundles for java.desktop
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /D DONT_USE_PRECOMPILED_HEADER /c C:\jdk9\client\hotspot\src\os\windows\vm\osThread_windows.cpp
osThread_windows.cpp
Generating beaninfo
Compiling 2749 files for java.base
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /D DONT_USE_PRECOMPILED_HEADER /c C:\jdk9\client\hotspot\src\os\windows\vm\os_windows.cpp
os_windows.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /D DONT_USE_PRECOMPILED_HEADER /c C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm\os_windows_x86.cpp
os_windows_x86.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /D DONT_USE_PRECOMPILED_HEADER /c ..\generated\jvmtifiles\bytecodeInterpreterWithChecks.cpp
bytecodeInterpreterWithChecks.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /D DONT_USE_PRECOMPILED_HEADER /c C:\jdk9\client\hotspot\src\share\vm\opto\opcodes.cpp
opcodes.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\classfile\classLoaderExt.cpp C:\jdk9\client\hotspot\src\closed\share\vm\classfile\sharedClassUtil.cpp C:\jdk9\client\hotspot\src\closed\share\vm\classfile\systemDictionaryShared.cpp 
classLoaderExt.cpp
sharedClassUtil.cpp
systemDictionaryShared.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\gc_interface\collectedHeap_ext.cpp 
collectedHeap_ext.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfr.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrActivator.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrAllocation.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrbackend.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrBufferedCheckpoints.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrBufferThread.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrCallbacks.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrCheckpointWriter.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrConstantPools.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrDcmds.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrEventWriter.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrExport.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrLogging.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrMessages.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrOptions.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrOSInterface.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrProducers.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrRepository.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrRequestables.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrRequests.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrSamples.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrStackTraces.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrStatistics.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrStreamWriter.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrTypeIDs.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\jfrVMOperations.cpp 
jfr.cpp
jfrActivator.cpp
jfrAllocation.cpp
jfrbackend.cpp
jfrBufferedCheckpoints.cpp
jfrBufferThread.cpp
jfrCallbacks.cpp
jfrCheckpointWriter.cpp
jfrConstantPools.cpp
jfrDcmds.cpp
jfrEventWriter.cpp
jfrExport.cpp
jfrLogging.cpp
jfrMessages.cpp
jfrOptions.cpp
jfrOSInterface.cpp
jfrProducers.cpp
jfrRepository.cpp
jfrRequestables.cpp
jfrRequests.cpp
jfrSamples.cpp
jfrStackTraces.cpp
jfrStatistics.cpp
jfrStreamWriter.cpp
jfrTypeIDs.cpp
jfrVMOperations.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\prims\cdsoffsets.cpp C:\jdk9\client\hotspot\src\closed\share\vm\prims\jvm_ext.cpp C:\jdk9\client\hotspot\src\closed\share\vm\prims\whitebox_ext.cpp 
cdsoffsets.cpp
jvm_ext.cpp
whitebox_ext.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\runtime\arguments_ext.cpp C:\jdk9\client\hotspot\src\closed\share\vm\runtime\os_ext.cpp C:\jdk9\client\hotspot\src\closed\share\vm\runtime\thread_ext.cpp 
arguments_ext.cpp
os_ext.cpp
thread_ext.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\services\allocationContextService.cpp C:\jdk9\client\hotspot\src\closed\share\vm\services\diagnosticCommand_ext.cpp C:\jdk9\client\hotspot\src\closed\share\vm\services\management_ext.cpp 
allocationContextService.cpp
diagnosticCommand_ext.cpp
management_ext.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\utilities\errorReporter.cpp C:\jdk9\client\hotspot\src\closed\share\vm\utilities\errorReporterHelper.cpp C:\jdk9\client\hotspot\src\closed\share\vm\utilities\streamwriter.cpp C:\jdk9\client\hotspot\src\closed\share\vm\utilities\ticks.cpp C:\jdk9\client\hotspot\src\closed\share\vm\utilities\timingconv.cpp 
errorReporter.cpp
errorReporterHelper.cpp
streamwriter.cpp
ticks.cpp
timingconv.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\asm\assembler.cpp C:\jdk9\client\hotspot\src\share\vm\asm\codeBuffer.cpp C:\jdk9\client\hotspot\src\share\vm\asm\register.cpp 
assembler.cpp
codeBuffer.cpp
register.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\ci\bcEscapeAnalyzer.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciArray.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciArrayKlass.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciBaseObject.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciCallSite.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciConstant.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciConstantPoolCache.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciEnv.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciExceptionHandler.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciField.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciFlags.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciInstance.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciInstanceKlass.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciKlass.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciMemberName.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciMetadata.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciMethod.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciMethodBlocks.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciMethodData.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciMethodHandle.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciNullObject.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciObjArray.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciObjArrayKlass.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciObject.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciObjectFactory.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciReplay.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciSignature.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciStreams.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciSymbol.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciType.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciTypeArray.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciTypeArrayKlass.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciTypeFlow.cpp C:\jdk9\client\hotspot\src\share\vm\ci\ciUtilities.cpp 
bcEscapeAnalyzer.cpp
ciArray.cpp
ciArrayKlass.cpp
ciBaseObject.cpp
ciCallSite.cpp
ciConstant.cpp
ciConstantPoolCache.cpp
ciEnv.cpp
ciExceptionHandler.cpp
ciField.cpp
ciFlags.cpp
ciInstance.cpp
ciInstanceKlass.cpp
ciKlass.cpp
ciMemberName.cpp
ciMetadata.cpp
ciMethod.cpp
ciMethodBlocks.cpp
ciMethodData.cpp
ciMethodHandle.cpp
ciNullObject.cpp
ciObjArray.cpp
ciObjArrayKlass.cpp
ciObject.cpp
ciObjectFactory.cpp
ciReplay.cpp
ciSignature.cpp
ciStreams.cpp
ciSymbol.cpp
ciType.cpp
ciTypeArray.cpp
ciTypeArrayKlass.cpp
ciTypeFlow.cpp
ciUtilities.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\classfile\altHashing.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\bytecodeAssembler.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\classFileError.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\classFileParser.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\classFileStream.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\classLoader.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\classLoaderData.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\classLoaderStats.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\compactHashtable.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\defaultMethods.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\dictionary.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\imageFile.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\javaAssertions.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\javaClasses.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\loaderConstraints.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\metadataOnStackMark.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\placeholders.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\resolutionErrors.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\sharedPathsMiscInfo.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\stackMapFrame.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\stackMapTable.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\stringTable.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\symbolTable.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\systemDictionary.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\verificationType.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\verifier.cpp C:\jdk9\client\hotspot\src\share\vm\classfile\vmSymbols.cpp 
altHashing.cpp
bytecodeAssembler.cpp
classFileError.cpp
classFileParser.cpp
classFileStream.cpp
classLoader.cpp
classLoaderData.cpp
classLoaderStats.cpp
compactHashtable.cpp
defaultMethods.cpp
dictionary.cpp
imageFile.cpp
javaAssertions.cpp
javaClasses.cpp
loaderConstraints.cpp
metadataOnStackMark.cpp
placeholders.cpp
resolutionErrors.cpp
sharedPathsMiscInfo.cpp
stackMapFrame.cpp
stackMapTable.cpp
stringTable.cpp
symbolTable.cpp
systemDictionary.cpp
verificationType.cpp
verifier.cpp
vmSymbols.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\code\codeBlob.cpp C:\jdk9\client\hotspot\src\share\vm\code\codeCache.cpp C:\jdk9\client\hotspot\src\share\vm\code\compiledIC.cpp C:\jdk9\client\hotspot\src\share\vm\code\compressedStream.cpp C:\jdk9\client\hotspot\src\share\vm\code\debugInfo.cpp C:\jdk9\client\hotspot\src\share\vm\code\debugInfoRec.cpp C:\jdk9\client\hotspot\src\share\vm\code\dependencies.cpp C:\jdk9\client\hotspot\src\share\vm\code\exceptionHandlerTable.cpp C:\jdk9\client\hotspot\src\share\vm\code\icBuffer.cpp C:\jdk9\client\hotspot\src\share\vm\code\location.cpp C:\jdk9\client\hotspot\src\share\vm\code\nmethod.cpp C:\jdk9\client\hotspot\src\share\vm\code\oopRecorder.cpp C:\jdk9\client\hotspot\src\share\vm\code\pcDesc.cpp C:\jdk9\client\hotspot\src\share\vm\code\relocInfo.cpp C:\jdk9\client\hotspot\src\share\vm\code\scopeDesc.cpp C:\jdk9\client\hotspot\src\share\vm\code\stubs.cpp C:\jdk9\client\hotspot\src\share\vm\code\vmreg.cpp C:\jdk9\client\hotspot\src\share\vm\code\vtableStubs.cpp 
codeBlob.cpp
codeCache.cpp
compiledIC.cpp
compressedStream.cpp
debugInfo.cpp
debugInfoRec.cpp
dependencies.cpp
exceptionHandlerTable.cpp
icBuffer.cpp
location.cpp
nmethod.cpp
oopRecorder.cpp
pcDesc.cpp
relocInfo.cpp
scopeDesc.cpp
stubs.cpp
vmreg.cpp
vtableStubs.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\compiler\abstractCompiler.cpp C:\jdk9\client\hotspot\src\share\vm\compiler\compileBroker.cpp C:\jdk9\client\hotspot\src\share\vm\compiler\compileLog.cpp C:\jdk9\client\hotspot\src\share\vm\compiler\compilerOracle.cpp C:\jdk9\client\hotspot\src\share\vm\compiler\disassembler.cpp C:\jdk9\client\hotspot\src\share\vm\compiler\methodLiveness.cpp C:\jdk9\client\hotspot\src\share\vm\compiler\oopMap.cpp 
abstractCompiler.cpp
compileBroker.cpp
compileLog.cpp
compilerOracle.cpp
disassembler.cpp
methodLiveness.cpp
oopMap.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\gc_interface\allocTracer.cpp C:\jdk9\client\hotspot\src\share\vm\gc_interface\collectedHeap.cpp C:\jdk9\client\hotspot\src\share\vm\gc_interface\gcCause.cpp 
allocTracer.cpp
collectedHeap.cpp
gcCause.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\interpreter\bytecode.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\bytecodeHistogram.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\bytecodes.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\bytecodeStream.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\bytecodeTracer.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\cppInterpreter.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\interpreter.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\interpreterRuntime.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\invocationCounter.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\linkResolver.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\oopMapCache.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\rewriter.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\templateInterpreter.cpp C:\jdk9\client\hotspot\src\share\vm\interpreter\templateTable.cpp 
bytecode.cpp
bytecodeHistogram.cpp
bytecodes.cpp
bytecodeStream.cpp
bytecodeTracer.cpp
cppInterpreter.cpp
interpreter.cpp
interpreterRuntime.cpp
invocationCounter.cpp
linkResolver.cpp
oopMapCache.cpp
rewriter.cpp
templateInterpreter.cpp
templateTable.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\memory\allocation.cpp C:\jdk9\client\hotspot\src\share\vm\memory\barrierSet.cpp C:\jdk9\client\hotspot\src\share\vm\memory\binaryTreeDictionary.cpp C:\jdk9\client\hotspot\src\share\vm\memory\blockOffsetTable.cpp C:\jdk9\client\hotspot\src\share\vm\memory\cardGeneration.cpp C:\jdk9\client\hotspot\src\share\vm\memory\cardTableModRefBS.cpp C:\jdk9\client\hotspot\src\share\vm\memory\cardTableRS.cpp C:\jdk9\client\hotspot\src\share\vm\memory\collectorPolicy.cpp C:\jdk9\client\hotspot\src\share\vm\memory\defNewGeneration.cpp C:\jdk9\client\hotspot\src\share\vm\memory\filemap.cpp C:\jdk9\client\hotspot\src\share\vm\memory\freeBlockDictionary.cpp C:\jdk9\client\hotspot\src\share\vm\memory\freeList.cpp C:\jdk9\client\hotspot\src\share\vm\memory\gcLocker.cpp C:\jdk9\client\hotspot\src\share\vm\memory\genCollectedHeap.cpp C:\jdk9\client\hotspot\src\share\vm\memory\generation.cpp C:\jdk9\client\hotspot\src\share\vm\memory\generationSpec.cpp C:\jdk9\client\hotspot\src\share\vm\memory\genMarkSweep.cpp C:\jdk9\client\hotspot\src\share\vm\memory\genRemSet.cpp C:\jdk9\client\hotspot\src\share\vm\memory\guardedMemory.cpp C:\jdk9\client\hotspot\src\share\vm\memory\heap.cpp C:\jdk9\client\hotspot\src\share\vm\memory\heapInspection.cpp C:\jdk9\client\hotspot\src\share\vm\memory\iterator.cpp C:\jdk9\client\hotspot\src\share\vm\memory\memRegion.cpp C:\jdk9\client\hotspot\src\share\vm\memory\metachunk.cpp C:\jdk9\client\hotspot\src\share\vm\memory\metaspace.cpp C:\jdk9\client\hotspot\src\share\vm\memory\metaspaceCounters.cpp C:\jdk9\client\hotspot\src\share\vm\memory\metaspaceShared.cpp C:\jdk9\client\hotspot\src\share\vm\memory\metaspaceTracer.cpp C:\jdk9\client\hotspot\src\share\vm\memory\oopFactory.cpp C:\jdk9\client\hotspot\src\share\vm\memory\referencePolicy.cpp C:\jdk9\client\hotspot\src\share\vm\memory\referenceProcessor.cpp C:\jdk9\client\hotspot\src\share\vm\memory\resourceArea.cpp C:\jdk9\client\hotspot\src\share\vm\memory\sharedHeap.cpp C:\jdk9\client\hotspot\src\share\vm\memory\space.cpp C:\jdk9\client\hotspot\src\share\vm\memory\tenuredGeneration.cpp C:\jdk9\client\hotspot\src\share\vm\memory\threadLocalAllocBuffer.cpp C:\jdk9\client\hotspot\src\share\vm\memory\universe.cpp 
allocation.cpp
barrierSet.cpp
binaryTreeDictionary.cpp
blockOffsetTable.cpp
cardGeneration.cpp
cardTableModRefBS.cpp
cardTableRS.cpp
collectorPolicy.cpp
defNewGeneration.cpp
filemap.cpp
freeBlockDictionary.cpp
freeList.cpp
gcLocker.cpp
genCollectedHeap.cpp
generation.cpp
generationSpec.cpp
genMarkSweep.cpp
genRemSet.cpp
guardedMemory.cpp
heap.cpp
heapInspection.cpp
iterator.cpp
memRegion.cpp
metachunk.cpp
metaspace.cpp
metaspaceCounters.cpp
metaspaceShared.cpp
metaspaceTracer.cpp
oopFactory.cpp
referencePolicy.cpp
referenceProcessor.cpp
resourceArea.cpp
sharedHeap.cpp
space.cpp
tenuredGeneration.cpp
threadLocalAllocBuffer.cpp
universe.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\oops\annotations.cpp C:\jdk9\client\hotspot\src\share\vm\oops\arrayKlass.cpp C:\jdk9\client\hotspot\src\share\vm\oops\arrayOop.cpp C:\jdk9\client\hotspot\src\share\vm\oops\compiledICHolder.cpp C:\jdk9\client\hotspot\src\share\vm\oops\constantPool.cpp C:\jdk9\client\hotspot\src\share\vm\oops\constMethod.cpp C:\jdk9\client\hotspot\src\share\vm\oops\cpCache.cpp C:\jdk9\client\hotspot\src\share\vm\oops\generateOopMap.cpp C:\jdk9\client\hotspot\src\share\vm\oops\instanceClassLoaderKlass.cpp C:\jdk9\client\hotspot\src\share\vm\oops\instanceKlass.cpp C:\jdk9\client\hotspot\src\share\vm\oops\instanceMirrorKlass.cpp C:\jdk9\client\hotspot\src\share\vm\oops\instanceOop.cpp C:\jdk9\client\hotspot\src\share\vm\oops\instanceRefKlass.cpp C:\jdk9\client\hotspot\src\share\vm\oops\klass.cpp C:\jdk9\client\hotspot\src\share\vm\oops\klassVtable.cpp C:\jdk9\client\hotspot\src\share\vm\oops\markOop.cpp C:\jdk9\client\hotspot\src\share\vm\oops\metadata.cpp C:\jdk9\client\hotspot\src\share\vm\oops\method.cpp C:\jdk9\client\hotspot\src\share\vm\oops\methodCounters.cpp C:\jdk9\client\hotspot\src\share\vm\oops\methodData.cpp C:\jdk9\client\hotspot\src\share\vm\oops\objArrayKlass.cpp C:\jdk9\client\hotspot\src\share\vm\oops\objArrayOop.cpp C:\jdk9\client\hotspot\src\share\vm\oops\oop.cpp C:\jdk9\client\hotspot\src\share\vm\oops\oopsHierarchy.cpp C:\jdk9\client\hotspot\src\share\vm\oops\symbol.cpp C:\jdk9\client\hotspot\src\share\vm\oops\typeArrayKlass.cpp C:\jdk9\client\hotspot\src\share\vm\oops\typeArrayOop.cpp 
annotations.cpp
arrayKlass.cpp
arrayOop.cpp
compiledICHolder.cpp
constantPool.cpp
constMethod.cpp
cpCache.cpp
generateOopMap.cpp
instanceClassLoaderKlass.cpp
instanceKlass.cpp
instanceMirrorKlass.cpp
instanceOop.cpp
instanceRefKlass.cpp
klass.cpp
klassVtable.cpp
markOop.cpp
metadata.cpp
method.cpp
methodCounters.cpp
methodData.cpp
objArrayKlass.cpp
objArrayOop.cpp
oop.cpp
oopsHierarchy.cpp
symbol.cpp
typeArrayKlass.cpp
typeArrayOop.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\prims\evmCompat.cpp C:\jdk9\client\hotspot\src\share\vm\prims\forte.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jni.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jniCheck.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jniFastGetField.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvm.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiClassFileReconstituter.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiCodeBlobEvents.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiEnv.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiEnvBase.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiEnvThreadState.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiEventController.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiExport.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiExtensions.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiGetLoadedClasses.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiImpl.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiManageCapabilities.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiRawMonitor.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiRedefineClasses.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiTagMap.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiThreadState.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiTrace.cpp C:\jdk9\client\hotspot\src\share\vm\prims\jvmtiUtil.cpp C:\jdk9\client\hotspot\src\share\vm\prims\methodComparator.cpp C:\jdk9\client\hotspot\src\share\vm\prims\methodHandles.cpp C:\jdk9\client\hotspot\src\share\vm\prims\nativeLookup.cpp C:\jdk9\client\hotspot\src\share\vm\prims\perf.cpp C:\jdk9\client\hotspot\src\share\vm\prims\privilegedStack.cpp C:\jdk9\client\hotspot\src\share\vm\prims\unsafe.cpp C:\jdk9\client\hotspot\src\share\vm\prims\whitebox.cpp 
evmCompat.cpp
forte.cpp
jni.cpp
jniCheck.cpp
jniFastGetField.cpp
jvm.cpp
jvmtiClassFileReconstituter.cpp
jvmtiCodeBlobEvents.cpp
jvmtiEnv.cpp
jvmtiEnvBase.cpp
jvmtiEnvThreadState.cpp
jvmtiEventController.cpp
jvmtiExport.cpp
jvmtiExtensions.cpp
jvmtiGetLoadedClasses.cpp
jvmtiImpl.cpp
jvmtiManageCapabilities.cpp
jvmtiRawMonitor.cpp
jvmtiRedefineClasses.cpp
jvmtiTagMap.cpp
jvmtiThreadState.cpp
jvmtiTrace.cpp
jvmtiUtil.cpp
methodComparator.cpp
methodHandles.cpp
nativeLookup.cpp
perf.cpp
privilegedStack.cpp
unsafe.cpp
whitebox.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\runtime\advancedThresholdPolicy.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\arguments.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\atomic.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\basicLock.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\biasedLocking.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\compilationPolicy.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\deoptimization.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\fieldDescriptor.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\fieldType.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\fprofiler.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\frame.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\globals.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\handles.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\icache.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\init.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\interfaceSupport.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\java.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\javaCalls.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\jniHandles.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\jniPeriodicChecker.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\memprofiler.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\monitorChunk.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\mutex.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\mutexLocker.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\objectMonitor.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\orderAccess.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\os.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\osThread.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\park.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\perfData.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\perfMemory.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\reflection.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\reflectionUtils.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\relocator.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\rframe.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\safepoint.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\serviceThread.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\sharedRuntime.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\sharedRuntimeTrans.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\sharedRuntimeTrig.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\signature.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\simpleThresholdPolicy.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\stackValue.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\stackValueCollection.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\statSampler.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\stubCodeGenerator.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\stubRoutines.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\sweeper.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\synchronizer.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\task.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\thread.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\threadLocalStorage.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\timer.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\unhandledOops.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\vframe.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\vframeArray.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\vframe_hp.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\virtualspace.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\vmStructs.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\vmThread.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\vm_operations.cpp C:\jdk9\client\hotspot\src\share\vm\runtime\vm_version.cpp 
advancedThresholdPolicy.cpp
arguments.cpp
atomic.cpp
basicLock.cpp
biasedLocking.cpp
compilationPolicy.cpp
deoptimization.cpp
fieldDescriptor.cpp
fieldType.cpp
fprofiler.cpp
frame.cpp
globals.cpp
handles.cpp
icache.cpp
init.cpp
interfaceSupport.cpp
java.cpp
javaCalls.cpp
jniHandles.cpp
jniPeriodicChecker.cpp
memprofiler.cpp
monitorChunk.cpp
mutex.cpp
mutexLocker.cpp
objectMonitor.cpp
orderAccess.cpp
os.cpp
osThread.cpp
park.cpp
perfData.cpp
perfMemory.cpp
reflection.cpp
reflectionUtils.cpp
relocator.cpp
rframe.cpp
safepoint.cpp
serviceThread.cpp
sharedRuntime.cpp
sharedRuntimeTrans.cpp
sharedRuntimeTrig.cpp
signature.cpp
simpleThresholdPolicy.cpp
stackValue.cpp
stackValueCollection.cpp
statSampler.cpp
stubCodeGenerator.cpp
stubRoutines.cpp
sweeper.cpp
synchronizer.cpp
task.cpp
thread.cpp
threadLocalStorage.cpp
timer.cpp
unhandledOops.cpp
vframe.cpp
vframeArray.cpp
vframe_hp.cpp
virtualspace.cpp
vmStructs.cpp
vmThread.cpp
vm_operations.cpp
vm_version.cpp
Compiling 16 files for java.datatransfer
Compiling 130 files for jdk.charsets
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\services\attachListener.cpp C:\jdk9\client\hotspot\src\share\vm\services\classLoadingService.cpp C:\jdk9\client\hotspot\src\share\vm\services\diagnosticArgument.cpp C:\jdk9\client\hotspot\src\share\vm\services\diagnosticCommand.cpp C:\jdk9\client\hotspot\src\share\vm\services\diagnosticFramework.cpp C:\jdk9\client\hotspot\src\share\vm\services\dtraceAttacher.cpp C:\jdk9\client\hotspot\src\share\vm\services\g1MemoryPool.cpp C:\jdk9\client\hotspot\src\share\vm\services\gcNotifier.cpp C:\jdk9\client\hotspot\src\share\vm\services\heapDumper.cpp C:\jdk9\client\hotspot\src\share\vm\services\lowMemoryDetector.cpp C:\jdk9\client\hotspot\src\share\vm\services\mallocSiteTable.cpp C:\jdk9\client\hotspot\src\share\vm\services\mallocTracker.cpp C:\jdk9\client\hotspot\src\share\vm\services\management.cpp C:\jdk9\client\hotspot\src\share\vm\services\memBaseline.cpp C:\jdk9\client\hotspot\src\share\vm\services\memoryManager.cpp C:\jdk9\client\hotspot\src\share\vm\services\memoryPool.cpp C:\jdk9\client\hotspot\src\share\vm\services\memoryService.cpp C:\jdk9\client\hotspot\src\share\vm\services\memReporter.cpp C:\jdk9\client\hotspot\src\share\vm\services\memTracker.cpp C:\jdk9\client\hotspot\src\share\vm\services\nmtCommon.cpp C:\jdk9\client\hotspot\src\share\vm\services\nmtDCmd.cpp C:\jdk9\client\hotspot\src\share\vm\services\psMemoryPool.cpp C:\jdk9\client\hotspot\src\share\vm\services\runtimeService.cpp C:\jdk9\client\hotspot\src\share\vm\services\threadService.cpp C:\jdk9\client\hotspot\src\share\vm\services\virtualMemoryTracker.cpp C:\jdk9\client\hotspot\src\share\vm\services\writeableFlags.cpp 
attachListener.cpp
classLoadingService.cpp
diagnosticArgument.cpp
diagnosticCommand.cpp
diagnosticFramework.cpp
dtraceAttacher.cpp
g1MemoryPool.cpp
gcNotifier.cpp
heapDumper.cpp
lowMemoryDetector.cpp
mallocSiteTable.cpp
mallocTracker.cpp
management.cpp
memBaseline.cpp
Compiling 32 files for java.logging
memoryManager.cpp
memoryPool.cpp
memoryService.cpp
Compiling 5 files for java.annotations.common
memReporter.cpp
memTracker.cpp
nmtCommon.cpp
nmtDCmd.cpp
psMemoryPool.cpp
runtimeService.cpp
threadService.cpp
virtualMemoryTracker.cpp
writeableFlags.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\utilities\accessFlags.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\array.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\bitMap.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\chunkedList.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\constantTag.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\copy.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\debug.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\decoder.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\decoder_elf.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\elfFile.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\elfFuncDescTable.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\elfStringTable.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\elfSymbolTable.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\events.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\exceptions.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\globalDefinitions.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\growableArray.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\hashtable.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\histogram.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\intHisto.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\linkedlist.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\nativeCallStack.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\numberSeq.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\ostream.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\preserveException.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\quickSort.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\sizes.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\stringUtils.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\taskqueue.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\utf8.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\vmError.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\workgroup.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\xmlstream.cpp C:\jdk9\client\hotspot\src\share\vm\utilities\yieldingWorkgroup.cpp 
accessFlags.cpp
array.cpp
bitMap.cpp
chunkedList.cpp
constantTag.cpp
copy.cpp
debug.cpp
decoder.cpp
decoder_elf.cpp
elfFile.cpp
elfFuncDescTable.cpp
elfStringTable.cpp
elfSymbolTable.cpp
events.cpp
exceptions.cpp
globalDefinitions.cpp
growableArray.cpp
hashtable.cpp
histogram.cpp
intHisto.cpp
linkedlist.cpp
nativeCallStack.cpp
numberSeq.cpp
ostream.cpp
Compiling 7 files for java.instrument
preserveException.cpp
quickSort.cpp
sizes.cpp
stringUtils.cpp
taskqueue.cpp
utf8.cpp
vmError.cpp
workgroup.cpp
xmlstream.cpp
yieldingWorkgroup.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\gc_implementation\shared\gcConfiguration.cpp C:\jdk9\client\hotspot\src\closed\share\vm\gc_implementation\shared\objectCountEventSender.cpp 
gcConfiguration.cpp
objectCountEventSender.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\adaptiveSizePolicy.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\ageTable.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\allocationStats.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\collectorCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\concurrentGCThread.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\cSpaceCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gcAdaptivePolicyCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gcId.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gcPolicyCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gcStats.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gcTimer.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gcTrace.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gcTraceSend.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gcTraceTime.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gcUtil.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\generationCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\gSpaceCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\hSpaceCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\immutableSpace.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\markSweep.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\mutableNUMASpace.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\mutableSpace.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\parGCAllocBuffer.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\spaceCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\spaceDecorator.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\suspendibleThreadSet.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\shared\vmGCOperations.cpp 
adaptiveSizePolicy.cpp
ageTable.cpp
allocationStats.cpp
collectorCounters.cpp
concurrentGCThread.cpp
cSpaceCounters.cpp
gcAdaptivePolicyCounters.cpp
gcId.cpp
Compiling 13 files for java.scripting
gcPolicyCounters.cpp
gcStats.cpp
gcTimer.cpp
gcTrace.cpp
gcTraceSend.cpp
gcTraceTime.cpp
gcUtil.cpp
generationCounters.cpp
gSpaceCounters.cpp
hSpaceCounters.cpp
immutableSpace.cpp
markSweep.cpp
mutableNUMASpace.cpp
mutableSpace.cpp
parGCAllocBuffer.cpp
Compiling 20 files for java.smartcardio
spaceCounters.cpp
spaceDecorator.cpp
suspendibleThreadSet.cpp
vmGCOperations.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\os\windows\vm\errorReporterHelper_windows.cpp C:\jdk9\client\hotspot\src\closed\os\windows\vm\fileio_windows.cpp C:\jdk9\client\hotspot\src\closed\os\windows\vm\os_perf_windows.cpp C:\jdk9\client\hotspot\src\closed\os\windows\vm\pdh_interface.cpp C:\jdk9\client\hotspot\src\closed\os\windows\vm\stringutil_windows.cpp 
errorReporterHelper_windows.cpp
fileio_windows.cpp
os_perf_windows.cpp
pdh_interface.cpp
stringutil_windows.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\os\windows\vm\attachListener_windows.cpp C:\jdk9\client\hotspot\src\os\windows\vm\decoder_windows.cpp C:\jdk9\client\hotspot\src\os\windows\vm\jvm_windows.cpp C:\jdk9\client\hotspot\src\os\windows\vm\mutex_windows.cpp C:\jdk9\client\hotspot\src\os\windows\vm\perfMemory_windows.cpp C:\jdk9\client\hotspot\src\os\windows\vm\stubRoutines_windows.cpp C:\jdk9\client\hotspot\src\os\windows\vm\threadCritical_windows.cpp C:\jdk9\client\hotspot\src\os\windows\vm\vmError_windows.cpp 
attachListener_windows.cpp
decoder_windows.cpp
jvm_windows.cpp
mutex_windows.cpp
Compiling 43 files for jdk.httpserver
perfMemory_windows.cpp
stubRoutines_windows.cpp
threadCritical_windows.cpp
vmError_windows.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\cpu\x86\vm\os_x86.cpp C:\jdk9\client\hotspot\src\closed\cpu\x86\vm\vm_version_ext_x86.cpp 
os_x86.cpp
vm_version_ext_x86.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\cpu\x86\vm\assembler_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\bytecodeInterpreter_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\c1_CodeStubs_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\c1_FpuStackSim_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\c1_FrameMap_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\c1_LinearScan_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\c1_LIRAssembler_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\c1_LIRGenerator_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\c1_MacroAssembler_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\c1_Runtime1_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\c2_init_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\compiledIC_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\cppInterpreter_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\debug_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\depChecker_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\frame_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\icache_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\icBuffer_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\interpreterGenerator_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\interpreterRT_x86_32.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\interpreter_x86_32.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\interp_masm_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\jniFastGetField_x86_32.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\macroAssembler_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\metaspaceShared_x86_32.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\methodHandles_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\nativeInst_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\register_definitions_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\register_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\relocInfo_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\rtmLocking.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\runtime_x86_32.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\sharedRuntime_x86_32.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\stubGenerator_x86_32.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\stubRoutines_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\stubRoutines_x86_32.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\templateInterpreter_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\templateInterpreter_x86_32.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\templateTable_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\vmreg_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\vm_version_x86.cpp C:\jdk9\client\hotspot\src\cpu\x86\vm\vtableStubs_x86_32.cpp 
assembler_x86.cpp
bytecodeInterpreter_x86.cpp
c1_CodeStubs_x86.cpp
c1_FpuStackSim_x86.cpp
c1_FrameMap_x86.cpp
c1_LinearScan_x86.cpp
c1_LIRAssembler_x86.cpp
c1_LIRGenerator_x86.cpp
Compiling 8 files for jdk.crypto.ec
c1_MacroAssembler_x86.cpp
c1_Runtime1_x86.cpp
c2_init_x86.cpp
compiledIC_x86.cpp
cppInterpreter_x86.cpp
debug_x86.cpp
depChecker_x86.cpp
frame_x86.cpp
icache_x86.cpp
icBuffer_x86.cpp
interpreterGenerator_x86.cpp
interpreterRT_x86_32.cpp
interpreter_x86_32.cpp
interp_masm_x86.cpp
Compiling 10 files for jdk.crypto.mscapi
jniFastGetField_x86_32.cpp
macroAssembler_x86.cpp
Compiling 1 files for jdk.hprof.agent
metaspaceShared_x86_32.cpp
methodHandles_x86.cpp
nativeInst_x86.cpp
register_definitions_x86.cpp
register_x86.cpp
relocInfo_x86.cpp
rtmLocking.cpp
runtime_x86_32.cpp
sharedRuntime_x86_32.cpp
stubGenerator_x86_32.cpp
stubRoutines_x86.cpp
stubRoutines_x86_32.cpp
templateInterpreter_x86.cpp
templateInterpreter_x86_32.cpp
templateTable_x86.cpp
vmreg_x86.cpp
vm_version_x86.cpp
vtableStubs_x86_32.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm\assembler_windows_x86.cpp C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm\threadLS_windows_x86.cpp C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm\thread_windows_x86.cpp C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm\vm_version_windows_x86.cpp 
assembler_windows_x86.cpp
threadLS_windows_x86.cpp
thread_windows_x86.cpp
vm_version_windows_x86.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c ..\generated\jvmtifiles\jvmtiEnter.cpp ..\generated\jvmtifiles\jvmtiEnterTrace.cpp 
Compiling 25 files for jdk.jartool
jvmtiEnter.cpp
jvmtiEnterTrace.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c ..\generated\tracefiles\traceProducer.cpp 
traceProducer.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\jfr\buffers\jfrBufferControl.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\buffers\jfrBuffers.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\buffers\jfrGlobalTraceBuffer.cpp C:\jdk9\client\hotspot\src\closed\share\vm\jfr\buffers\jfrThreadLocalTraceBuffer.cpp 
jfrBufferControl.cpp
jfrBuffers.cpp
jfrGlobalTraceBuffer.cpp
jfrThreadLocalTraceBuffer.cpp
Compiling 1569 files for jdk.localedata
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\prims\wbtestmethods\parserTests.cpp 
parserTests.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\closed\share\vm\gc_implementation\g1\g1AllocationContext.cpp C:\jdk9\client\hotspot\src\closed\share\vm\gc_implementation\g1\g1Allocator_ext.cpp C:\jdk9\client\hotspot\src\closed\share\vm\gc_implementation\g1\g1CollectedHeap_ext.cpp C:\jdk9\client\hotspot\src\closed\share\vm\gc_implementation\g1\g1CollectorPolicy_ext.cpp C:\jdk9\client\hotspot\src\closed\share\vm\gc_implementation\g1\g1MarkSweep_ext.cpp C:\jdk9\client\hotspot\src\closed\share\vm\gc_implementation\g1\g1ResManAllocator.cpp C:\jdk9\client\hotspot\src\closed\share\vm\gc_implementation\g1\g1ResManHeapRegion.cpp 
g1AllocationContext.cpp
g1Allocator_ext.cpp
g1CollectedHeap_ext.cpp
g1CollectorPolicy_ext.cpp
g1MarkSweep_ext.cpp
g1ResManAllocator.cpp
g1ResManHeapRegion.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\adaptiveFreeList.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\cmsCollectorPolicy.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\cmsLockVerifier.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\compactibleFreeListSpace.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\concurrentMarkSweepGeneration.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\concurrentMarkSweepThread.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\freeChunk.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\promotionInfo.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\concurrentMarkSweep\vmCMSOperations.cpp 
adaptiveFreeList.cpp
cmsCollectorPolicy.cpp
cmsLockVerifier.cpp
compactibleFreeListSpace.cpp
concurrentMarkSweepGeneration.cpp
concurrentMarkSweepThread.cpp
freeChunk.cpp
promotionInfo.cpp
vmCMSOperations.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\bufferingOopClosure.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\collectionSetChooser.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\concurrentG1Refine.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\concurrentG1RefineThread.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\concurrentMark.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\concurrentMarkThread.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\dirtyCardQueue.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1Allocator.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1AllocRegion.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1BiasedArray.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1BlockOffsetTable.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1CardCounts.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1CodeCacheRemSet.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1CollectedHeap.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1CollectorPolicy.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1ErgoVerbose.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1EvacFailure.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1GCPhaseTimes.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1HotCardCache.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1HRPrinter.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1Log.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1MarkSweep.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1MMUTracker.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1MonitoringSupport.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1OopClosures.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1PageBasedVirtualSpace.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1ParScanThreadState.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1RegionToSpaceMapper.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1RemSet.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1RemSetSummary.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1RootProcessor.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1SATBCardTableModRefBS.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1StringDedup.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1StringDedupQueue.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1StringDedupStat.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1StringDedupTable.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1StringDedupThread.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\g1_globals.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\heapRegion.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\heapRegionManager.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\heapRegionRemSet.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\heapRegionSet.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\heapRegionType.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\ptrQueue.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\satbQueue.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\sparsePRT.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\survRateGroup.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\g1\vm_operations_g1.cpp 
bufferingOopClosure.cpp
collectionSetChooser.cpp
concurrentG1Refine.cpp
concurrentG1RefineThread.cpp
concurrentMark.cpp
concurrentMarkThread.cpp
dirtyCardQueue.cpp
g1Allocator.cpp
g1AllocRegion.cpp
g1BiasedArray.cpp
g1BlockOffsetTable.cpp
g1CardCounts.cpp
g1CodeCacheRemSet.cpp
g1CollectedHeap.cpp
g1CollectorPolicy.cpp
g1ErgoVerbose.cpp
g1EvacFailure.cpp
g1GCPhaseTimes.cpp
g1HotCardCache.cpp
g1HRPrinter.cpp
g1Log.cpp
g1MarkSweep.cpp
g1MMUTracker.cpp
g1MonitoringSupport.cpp
g1OopClosures.cpp
g1PageBasedVirtualSpace.cpp
g1ParScanThreadState.cpp
g1RegionToSpaceMapper.cpp
g1RemSet.cpp
g1RemSetSummary.cpp
g1RootProcessor.cpp
g1SATBCardTableModRefBS.cpp
g1StringDedup.cpp
g1StringDedupQueue.cpp
g1StringDedupStat.cpp
g1StringDedupTable.cpp
g1StringDedupThread.cpp
g1_globals.cpp
heapRegion.cpp
heapRegionManager.cpp
Compiling 604 files for BUILD_NASHORN
heapRegionRemSet.cpp
heapRegionSet.cpp
heapRegionType.cpp
ptrQueue.cpp
satbQueue.cpp
sparsePRT.cpp
survRateGroup.cpp
vm_operations_g1.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\adjoiningGenerations.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\adjoiningVirtualSpaces.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\asPSOldGen.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\asPSYoungGen.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\cardTableExtension.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\gcTaskManager.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\gcTaskThread.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\generationSizer.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\objectStartArray.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\parallelScavengeHeap.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\parMarkBitMap.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\pcTasks.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psAdaptiveSizePolicy.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psCompactionManager.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psGCAdaptivePolicyCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psGenerationCounters.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psMarkSweep.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psMarkSweepDecorator.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psOldGen.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psParallelCompact.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psPromotionLAB.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psPromotionManager.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psScavenge.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psTasks.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psVirtualspace.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\psYoungGen.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parallelScavenge\vmPSOperations.cpp 
adjoiningGenerations.cpp
adjoiningVirtualSpaces.cpp
asPSOldGen.cpp
asPSYoungGen.cpp
cardTableExtension.cpp
gcTaskManager.cpp
gcTaskThread.cpp
generationSizer.cpp
objectStartArray.cpp
parallelScavengeHeap.cpp
parMarkBitMap.cpp
pcTasks.cpp
Compiling 24 files for jdk.sctp
psAdaptiveSizePolicy.cpp
psCompactionManager.cpp
psGCAdaptivePolicyCounters.cpp
psGenerationCounters.cpp
psMarkSweep.cpp
psMarkSweepDecorator.cpp
psOldGen.cpp
psParallelCompact.cpp
psPromotionLAB.cpp
psPromotionManager.cpp
psScavenge.cpp
psTasks.cpp
psVirtualspace.cpp
psYoungGen.cpp
Compiling 111 files for BUILD_NASGEN
vmPSOperations.cpp
Compiling 12 files for jdk.zipfs
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parNew\parCardTableModRefBS.cpp C:\jdk9\client\hotspot\src\share\vm\gc_implementation\parNew\parNewGeneration.cpp 
parCardTableModRefBS.cpp
parNewGeneration.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\c1\c1_Canonicalizer.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_CFGPrinter.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_Compilation.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_Compiler.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_Defs.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_FrameMap.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_globals.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_GraphBuilder.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_Instruction.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_InstructionPrinter.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_IR.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_LinearScan.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_LIR.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_LIRAssembler.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_LIRGenerator.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_Optimizer.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_RangeCheckElimination.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_Runtime1.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_ValueMap.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_ValueSet.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_ValueStack.cpp C:\jdk9\client\hotspot\src\share\vm\c1\c1_ValueType.cpp 
c1_Canonicalizer.cpp
c1_CFGPrinter.cpp
c1_Compilation.cpp
c1_Compiler.cpp
Running nasgen
c1_Defs.cpp
c1_FrameMap.cpp
c1_globals.cpp
c1_GraphBuilder.cpp
c1_Instruction.cpp
Compiling 114 files for java.compiler
Compiling 1908 files for java.xml
c1_InstructionPrinter.cpp
Creating version.properties
c1_IR.cpp
c1_LinearScan.cpp
c1_LIR.cpp
c1_LIRAssembler.cpp
c1_LIRGenerator.cpp
Compiling 29 files for java.security.sasl
c1_Optimizer.cpp
c1_RangeCheckElimination.cpp
c1_Runtime1.cpp
c1_ValueMap.cpp
c1_ValueSet.cpp
c1_ValueStack.cpp
c1_ValueType.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\opto\addnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\arraycopynode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\block.cpp C:\jdk9\client\hotspot\src\share\vm\opto\buildOopMap.cpp C:\jdk9\client\hotspot\src\share\vm\opto\bytecodeInfo.cpp C:\jdk9\client\hotspot\src\share\vm\opto\c2compiler.cpp C:\jdk9\client\hotspot\src\share\vm\opto\c2_globals.cpp C:\jdk9\client\hotspot\src\share\vm\opto\callGenerator.cpp C:\jdk9\client\hotspot\src\share\vm\opto\callnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\castnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\cfgnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\chaitin.cpp C:\jdk9\client\hotspot\src\share\vm\opto\classes.cpp C:\jdk9\client\hotspot\src\share\vm\opto\coalesce.cpp C:\jdk9\client\hotspot\src\share\vm\opto\compile.cpp C:\jdk9\client\hotspot\src\share\vm\opto\connode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\convertnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\countbitsnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\divnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\doCall.cpp C:\jdk9\client\hotspot\src\share\vm\opto\domgraph.cpp C:\jdk9\client\hotspot\src\share\vm\opto\escape.cpp C:\jdk9\client\hotspot\src\share\vm\opto\gcm.cpp C:\jdk9\client\hotspot\src\share\vm\opto\generateOptoStub.cpp C:\jdk9\client\hotspot\src\share\vm\opto\graphKit.cpp C:\jdk9\client\hotspot\src\share\vm\opto\idealGraphPrinter.cpp C:\jdk9\client\hotspot\src\share\vm\opto\idealKit.cpp C:\jdk9\client\hotspot\src\share\vm\opto\ifg.cpp C:\jdk9\client\hotspot\src\share\vm\opto\ifnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\indexSet.cpp C:\jdk9\client\hotspot\src\share\vm\opto\intrinsicnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\lcm.cpp C:\jdk9\client\hotspot\src\share\vm\opto\library_call.cpp C:\jdk9\client\hotspot\src\share\vm\opto\live.cpp C:\jdk9\client\hotspot\src\share\vm\opto\locknode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\loopnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\loopopts.cpp C:\jdk9\client\hotspot\src\share\vm\opto\loopPredicate.cpp C:\jdk9\client\hotspot\src\share\vm\opto\loopTransform.cpp C:\jdk9\client\hotspot\src\share\vm\opto\loopUnswitch.cpp C:\jdk9\client\hotspot\src\share\vm\opto\machnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\macro.cpp C:\jdk9\client\hotspot\src\share\vm\opto\macroArrayCopy.cpp C:\jdk9\client\hotspot\src\share\vm\opto\matcher.cpp C:\jdk9\client\hotspot\src\share\vm\opto\mathexactnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\memnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\movenode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\mulnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\multnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\narrowptrnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\node.cpp C:\jdk9\client\hotspot\src\share\vm\opto\opaquenode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\output.cpp C:\jdk9\client\hotspot\src\share\vm\opto\parse1.cpp C:\jdk9\client\hotspot\src\share\vm\opto\parse2.cpp C:\jdk9\client\hotspot\src\share\vm\opto\parse3.cpp C:\jdk9\client\hotspot\src\share\vm\opto\parseHelper.cpp C:\jdk9\client\hotspot\src\share\vm\opto\phase.cpp C:\jdk9\client\hotspot\src\share\vm\opto\phaseX.cpp C:\jdk9\client\hotspot\src\share\vm\opto\postaloc.cpp C:\jdk9\client\hotspot\src\share\vm\opto\regalloc.cpp C:\jdk9\client\hotspot\src\share\vm\opto\regmask.cpp C:\jdk9\client\hotspot\src\share\vm\opto\reg_split.cpp C:\jdk9\client\hotspot\src\share\vm\opto\replacednodes.cpp C:\jdk9\client\hotspot\src\share\vm\opto\rootnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\runtime.cpp C:\jdk9\client\hotspot\src\share\vm\opto\split_if.cpp C:\jdk9\client\hotspot\src\share\vm\opto\stringopts.cpp C:\jdk9\client\hotspot\src\share\vm\opto\subnode.cpp C:\jdk9\client\hotspot\src\share\vm\opto\superword.cpp C:\jdk9\client\hotspot\src\share\vm\opto\type.cpp C:\jdk9\client\hotspot\src\share\vm\opto\vectornode.cpp 
addnode.cpp
arraycopynode.cpp
block.cpp
buildOopMap.cpp
bytecodeInfo.cpp
c2compiler.cpp
c2_globals.cpp
callGenerator.cpp
callnode.cpp
castnode.cpp
cfgnode.cpp
chaitin.cpp
classes.cpp
coalesce.cpp
compile.cpp
connode.cpp
Compiling 133 files for java.rmi
convertnode.cpp
countbitsnode.cpp
divnode.cpp
doCall.cpp
Compiling 441 files for jdk.compiler
domgraph.cpp
escape.cpp
gcm.cpp
generateOptoStub.cpp
graphKit.cpp
idealGraphPrinter.cpp
idealKit.cpp
ifg.cpp
ifnode.cpp
indexSet.cpp
intrinsicnode.cpp
lcm.cpp
library_call.cpp
live.cpp
locknode.cpp
loopnode.cpp
loopopts.cpp
loopPredicate.cpp
loopTransform.cpp
loopUnswitch.cpp
machnode.cpp
macro.cpp
macroArrayCopy.cpp
matcher.cpp
mathexactnode.cpp
memnode.cpp
movenode.cpp
mulnode.cpp
multnode.cpp
narrowptrnode.cpp
node.cpp
opaquenode.cpp
output.cpp
parse1.cpp
parse2.cpp
parse3.cpp
parseHelper.cpp
phase.cpp
phaseX.cpp
postaloc.cpp
regalloc.cpp
regmask.cpp
reg_split.cpp
replacednodes.cpp
rootnode.cpp
runtime.cpp
split_if.cpp
stringopts.cpp
subnode.cpp
superword.cpp
type.cpp
vectornode.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c C:\jdk9\client\hotspot\src\share\vm\libadt\dict.cpp C:\jdk9\client\hotspot\src\share\vm\libadt\set.cpp C:\jdk9\client\hotspot\src\share\vm\libadt\vectset.cpp 
dict.cpp
set.cpp
vectset.cpp
	C:\progra~2\micros~1.0\vc\bin\cl.exe  /nologo /W3 /WX /Zi /D "IA32" /D "WIN32" /D "_WINDOWS" /D "VM_LITTLE_ENDIAN" /D TARGET_OS_FAMILY_windows /D TARGET_ARCH_x86 /D TARGET_ARCH_MODEL_x86_32 /D TARGET_OS_ARCH_windows_x86 /D TARGET_OS_ARCH_MODEL_windows_x86_32 /D TARGET_COMPILER_visCPP /MD /D _STATIC_CPPLIB /D _DISABLE_DEPRECATE_STATIC_CPPLIB /MP /O2 /Oy- /D "PRODUCT" /D "COMPILER1" /D "COMPILER2" /D "HOTSPOT_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "JDK_MAJOR_VERSION=\"1\"" /D "JDK_MINOR_VERSION=\"9\"" /D "JDK_MICRO_VERSION=\"0\"" /D "JDK_BUILD_NUMBER=\"0\"" /D "JRE_RELEASE_VERSION=\"1.9.0-internal-prsadhuk_2015_04_13_15_44-b00\"" /D "HOTSPOT_LIB_ARCH=\"i386\"" /D "HOTSPOT_BUILD_TARGET=\"product\"" /D "HOTSPOT_BUILD_USER=\"prsadhuk\"" /D "HOTSPOT_VM_DISTRO=\"Java HotSpot(TM)\"" /I "..\generated" /I "C:\jdk9\client\hotspot\src\closed\share\vm" /I "C:\jdk9\client\hotspot\src\closed\os\windows\vm" /I "C:\jdk9\client\hotspot\src\closed\cpu\x86\vm"  /I "C:\jdk9\client\hotspot\src\share\vm"  /I "C:\jdk9\client\hotspot\src\share\vm\precompiled"  /I "C:\jdk9\client\hotspot\src\share\vm\prims"  /I "C:\jdk9\client\hotspot\src\os\windows\vm"  /I "C:\jdk9\client\hotspot\src\os_cpu\windows_x86\vm"  /I "C:\jdk9\client\hotspot\src\cpu\x86\vm" /D "_JNI_IMPLEMENTATION_" /Fp"vm.pch" /Yu"precompiled.hpp" /c ..\generated\adfiles\ad_x86_32.cpp ..\generated\adfiles\ad_x86_32_clone.cpp ..\generated\adfiles\ad_x86_32_expand.cpp ..\generated\adfiles\ad_x86_32_format.cpp ..\generated\adfiles\ad_x86_32_gen.cpp ..\generated\adfiles\ad_x86_32_misc.cpp ..\generated\adfiles\ad_x86_32_peephole.cpp ..\generated\adfiles\ad_x86_32_pipeline.cpp ..\generated\adfiles\dfa_x86_32.cpp 
ad_x86_32.cpp
ad_x86_32_clone.cpp
ad_x86_32_expand.cpp
ad_x86_32_format.cpp
ad_x86_32_gen.cpp
ad_x86_32_misc.cpp
ad_x86_32_peephole.cpp
ad_x86_32_pipeline.cpp
dfa_x86_32.cpp
Compiling 66 files for jdk.crypto.pkcs11
	sh C:\jdk9\client\hotspot/make/windows/build_vm_def.sh 
Compiling 13 files for java.prefs
Compiling 3 files for java.transaction
Warning: generation and use of skeletons and static stubs for JRMP	
is deprecated. Skeletons are unnecessary, and static stubs have	
been superseded by dynamically generated stubs. Users are	
encouraged to migrate away from using rmic to generate skeletons and static	
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
Compiling 191 files for java.naming
Warning: generation and use of skeletons and static stubs for JRMP	
is deprecated. Skeletons are unnecessary, and static stubs have	
been superseded by dynamically generated stubs. Users are	
encouraged to migrate away from using rmic to generate skeletons and static	
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
Compiling 72 files for java.sql
Compiling 281 files for java.xml.crypto
Compiling 68 files for jdk.jvmstat
	C:\progra~2\micros~1.0\vc\bin\link.exe @C:\cygwin\tmp\nmF03B.tmp
   Creating library jvm.lib and object jvm.exp
LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return code '0x463'
Stop.
NMAKE : fatal error U1077: 'cd' : return code '0x2'
Stop.
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
Stop.
Makefile:230: recipe for target 'generic_build2' failed
make[5]: *** [generic_build2] Error 2
make[4]: *** [product] Error 2
Makefile:177: recipe for target 'product' failed
HotspotWrapper.gmk:44: recipe for target '/cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp' failed
make[3]: *** [/cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp] Error 1
make/Main.gmk:193: recipe for target 'hotspot' failed
make[2]: *** [hotspot] Error 1
make[2]: *** Waiting for unfinished jobs....
Compiling 90 files for jdk.dev
/cygdrive/c/jdk9/client/make/Init.gmk:213: recipe for target 'main' failed
make[1]: *** [main] Error 1
/cygdrive/c/jdk9/client/make/Init.gmk:143: recipe for target 'default' failed
make: *** [default] Error 2
-------------- next part --------------
Running custom generated-configure.sh
configure: Configuration created at Mon Apr 13 15:44:21 IST 2015.
configure: configure script generated at timestamp 1428017006.
checking for basename... /usr/bin/basename
checking for bash... /usr/bin/bash
checking for cat... /usr/bin/cat
checking for chmod... /usr/bin/chmod
checking for cmp... /usr/bin/cmp
checking for comm... /usr/bin/comm
checking for cp... /usr/bin/cp
checking for cut... /usr/bin/cut
checking for date... /usr/bin/date
checking for gdiff... no
checking for diff... /usr/bin/diff
checking for dirname... /usr/bin/dirname
checking for echo... /usr/bin/echo
checking for expr... /usr/bin/expr
checking for file... /usr/bin/file
checking for find... /usr/bin/find
checking for head... /usr/bin/head
checking for ln... /usr/bin/ln
checking for ls... /usr/bin/ls
checking for mkdir... /usr/bin/mkdir
checking for mktemp... /usr/bin/mktemp
checking for mv... /usr/bin/mv
checking for nawk... no
checking for gawk... /usr/bin/gawk
checking for printf... /usr/bin/printf
checking for rm... /usr/bin/rm
checking for sh... /usr/bin/sh
checking for sort... /usr/bin/sort
checking for tail... /usr/bin/tail
checking for tar... /usr/bin/tar
checking for tee... /usr/bin/tee
checking for touch... /usr/bin/touch
checking for tr... /usr/bin/tr
checking for uname... /usr/bin/uname
checking for uniq... /usr/bin/uniq
checking for wc... /usr/bin/wc
checking for which... /usr/bin/which
checking for xargs... /usr/bin/xargs
checking for gawk... gawk
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for a sed that does not truncate output... /usr/bin/sed
checking for cygpath... /usr/bin/cygpath
checking for greadlink... no
checking for readlink... /usr/bin/readlink
checking for df... /usr/bin/df
checking for SetFile... no
checking for cpio... /usr/bin/cpio
checking build system type... x86_64-pc-cygwin
checking host system type... x86_64-pc-cygwin
checking target system type... x86_64-pc-cygwin
checking openjdk-build os-cpu... windows-x86_64
checking openjdk-target os-cpu... windows-x86_64
checking compilation type... reduced
checking cygwin release... 1.7.34(0.285/5/3)
checking cygwin root directory as unix-style path... /cygdrive/c/cygwin
checking what kind of 'find' is first on the PATH... unix style
checking for top-level directory... /cygdrive/c/jdk9/client
checking for presence of closed sources... yes
checking if closed source is suppressed (openjdk-only)... no
checking which variant of the JDK to build... normal
checking which interpreter of the JVM to build... template
checking which variants of the JVM to build... server
checking which debug level to use... release
checking for parfait... not enabled
checking for sysroot... 
checking for toolchain path... 
checking for extra path... 
checking where to store configuration... in default location
checking what configuration name to use... windows-x86-normal-server-release
checking for apt-get... no
checking for yum... no
checking for port... no
checking for pkgutil... no
checking for pkgadd... no
checking for gmake... no
checking for make... /usr/bin/make
configure: Testing potential make at /usr/bin/make, found using make in PATH
configure: Using GNU make 3.81 (or later) at /usr/bin/make (version: GNU Make 4.1)
checking if make --output-sync is supported... yes
checking for output-sync value... none
checking if find supports -delete... yes
checking for unzip... /usr/bin/unzip
checking for zip... /usr/bin/zip
checking for ldd... /usr/bin/ldd
checking for otool... no
checking for greadelf... no
checking for readelf... /usr/bin/readelf
checking for hg... /usr/bin/hg
checking for stat... /usr/bin/stat
checking for time... no
checking if bash supports pipefail... yes
checking if bash supports errexit (-e)... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for 7z... no
checking for unzip... unzip
checking for wget... no
checking for lftp... no
checking for ftp... ftp
checking headful support... include support for both headful and headless
checking for javac... /cygdrive/c/jdk1.8.0_31/bin/javac
checking for java... /cygdrive/c/ProgramData/Oracle/Java/javapath/java
configure: Found potential Boot JDK using java(c) in PATH
checking for Boot JDK... /cygdrive/c/jdk1.8.0_31
checking Boot JDK version... java version "1.8.0_31"  Java(TM) SE Runtime Environment (build 1.8.0_31-b13)  Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)  
checking for java in Boot JDK... ok
checking for javac in Boot JDK... ok
checking for javah in Boot JDK... ok
checking for jar in Boot JDK... ok
checking for native2ascii in Boot JDK... ok
checking for jarsigner in Boot JDK... ok
configure: Using default toolchain microsoft (Microsoft Visual Studio)
checking for link... /usr/bin/link
checking if the first found link.exe is actually the Cygwin link tool... yes
configure: Found Visual Studio installation at /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/ using VS100COMNTOOLS variable
configure: Found Microsoft Visual Studio 2010
configure: Rewriting VS_ENV_CMD to "/cygdrive/c/progra~2/micros~1.0/vc/bin/vcvars32.bat"
configure: Trying to extract Visual Studio environment variables
Setting environment for using Microsoft Visual Studio 2010 x86 tools.
configure: Setting extracted environment variables
checking for Visual Studio variables... ok
configure: Rewriting ipath to "/cygdrive/c/progra~2/micros~1.0/vc/include"
configure: Rewriting ipath to "/cygdrive/c/progra~2/micros~1.0/vc/atlmfc/include"
configure: Rewriting ipath to "/cygdrive/c/progra~2/mia713~1/windows/v7.0a/include"
configure: Rewriting libpath to "/cygdrive/c/progra~2/micros~1.0/vc/lib"
configure: Rewriting libpath to "/cygdrive/c/progra~2/micros~1.0/vc/atlmfc/lib"
configure: Rewriting libpath to "/cygdrive/c/progra~2/mia713~1/windows/v7.0a/lib"
checking for cl... /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/cl
configure: Rewriting CC to "/cygdrive/c/progra~2/micros~1.0/vc/bin/cl"
checking resolved symbolic links for CC... /cygdrive/c/progra~2/micros~1.0/vc/bin/cl
checking if CC is disguised ccache... no, keeping CC
configure: Using microsoft C compiler version 16.00.30319.01 [Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86]
checking whether the C compiler works... yes
checking for C compiler default output file name... conftest.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... obj
checking whether we are using the GNU C compiler... no
checking whether /cygdrive/c/progra~2/micros~1.0/vc/bin/cl accepts -g... yes
checking for /cygdrive/c/progra~2/micros~1.0/vc/bin/cl option to accept ISO C89... none needed
checking for cl... /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/cl
configure: Rewriting CXX to "/cygdrive/c/progra~2/micros~1.0/vc/bin/cl"
checking resolved symbolic links for CXX... /cygdrive/c/progra~2/micros~1.0/vc/bin/cl
checking if CXX is disguised ccache... no, keeping CXX
configure: Using microsoft C++ compiler version 16.00.30319.01 [Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 16.00.30319.01 for 80x86]
checking whether we are using the GNU C++ compiler... no
checking whether /cygdrive/c/progra~2/micros~1.0/vc/bin/cl accepts -g... yes
checking how to run the C preprocessor... /cygdrive/c/progra~2/micros~1.0/vc/bin/cl -E
checking how to run the C++ preprocessor... /cygdrive/c/progra~2/micros~1.0/vc/bin/cl -E
checking for link... link
configure: Rewriting LD to "/cygdrive/c/progra~2/micros~1.0/vc/bin/link"
checking if the found link.exe is actually the Visual Studio linker... yes
checking for lib... lib
configure: Rewriting AR to "/cygdrive/c/progra~2/micros~1.0/vc/bin/lib"
checking for mt... mt
configure: Rewriting MT to "/cygdrive/c/progra~2/mia713~1/windows/v7.0a/bin/mt"
checking for rc... rc
configure: Rewriting RC to "/cygdrive/c/progra~2/mia713~1/windows/v7.0a/bin/rc"
checking for dumpbin... dumpbin
configure: Rewriting DUMPBIN to "/cygdrive/c/progra~2/micros~1.0/vc/bin/dumpbin"
checking for msbuild.exe... msbuild.exe
checking for gobjdump... no
checking for objdump... objdump
configure: Rewriting OBJDUMP to "/usr/bin/objdump"
checking for jtreg... no
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... no
checking for inttypes.h... no
checking for stdint.h... yes
checking for unistd.h... no
checking stdio.h usability... yes
checking stdio.h presence... yes
checking for stdio.h... yes
checking size of int *... 4
checking for target address size... 32 bits
checking whether byte ordering is bigendian... no
checking if compiler supports "-m32"... yes
checking if compiler supports "-m32"... yes
checking if we should generate debug symbols... true
checking if we should zip debug-info files... yes
checking if fixpath can be created... yes
checking if fixpath.exe works... yes
checking what is not needed on Windows?... alsa cups pulse x11
checking for which libjpeg to use... bundled
checking for which giflib to use... bundled
checking for which lcms to use... bundled
checking for which libpng to use... bundled
checking for compress in -lz... no
checking for which zlib to use... bundled
checking for cos in -lm... yes
checking for dlopen in -ldl... no
POSSIBLE_MSVC_DLL 
configure: Found msvcr100.dll at /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/redist/x86/Microsoft.VC100.CRT/msvcr100.dll using well-known location in VCINSTALLDIR
checking found msvcr100.dll architecture... ok
checking for msvcr100.dll... /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/redist/x86/Microsoft.VC100.CRT/msvcr100.dll
configure: Rewriting MSVCR_DLL to "/cygdrive/c/progra~2/micros~1.0/vc/redist/x86/micros~1.crt/msvcr100.dll"
checking if elliptic curve crypto implementation is present... yes
checking for number of cores... 4
checking for memory size... 8097 MB
checking for appropriate number of jobs to run in parallel... 4
checking flags for boot jdk java command ...  
checking flags for boot jdk java command for big workloads...  -Xms64M -Xmx1600M -XX:ThreadStackSize=1536
checking flags for boot jdk java command for small workloads...  -XX:+UseSerialGC -Xms32M -Xmx512M
checking whether to use sjavac... no
checking is ccache enabled... no
checking if build directory is on local disk... yes
checking Checking for deploy src... not found, cannot build deploy
checking Checking for install src... not found, cannot build installer
checking for ant... no
checking for ant.home using ant -diagnostics... no
configure: Ant is needed for deploy tests, set --with-ant-home=/path/to/ant-home
checking for JUnit... no, deploy tests cannot be run
checking for wix... no, needed for installer, set --with-wix=/path/to/wix
checking for lzma... no, needed for installer, set --with-lzma-path=/path/to/lzma
checking for UPX... no, needed for installer
checking for cscript... /cygdrive/c/windows/system32/cscript
checking for msicert... /cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/bin/msicert
configure: Rewriting MSICERT to "/cygdrive/c/progra~2/mia713~1/windows/v7.0a/bin/msicert"
checking for msitran... /cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/bin/msitran
configure: Rewriting MSITRAN to "/cygdrive/c/progra~2/mia713~1/windows/v7.0a/bin/msitran"
checking for midl... midl
configure: Rewriting MIDL to "/cygdrive/c/progra~2/mia713~1/windows/v7.0a/bin/midl"
checking for editbin... /cygdrive/c/Program Files (x86)/Microsoft Visual Studio 10.0/VC/BIN/editbin
configure: Rewriting EDITBIN to "/cygdrive/c/progra~2/micros~1.0/vc/bin/editbin"
checking for javafx zip dir... no, needed for installer, set --with-javafx-zip-dir=/path/to/javafx/zips
checking for jmc zip dir... no, JMC will not be bundled in installer build, set --with-jmc-zip-dir=/path/to/jmc/zips
checking for bsdiff... no, needed when building patches in installer
checking for jdk debug image dir... no
checking whether to explicitly enable tonga... no
checking if deploy should be built... no, missing dependency
configure: Cannot build installer without deploy
checking if installer should be built... no, missing dependency
checking for bundle date... 13_apr_2015 (generated)
checking whether to build JFR... yes (default)
checking whether to build commercial features... yes (default)
checking if crypto source is available... yes
configure: creating /cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/config.status
config.status: creating /cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/spec.gmk
config.status: creating /cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/hotspot-spec.gmk
config.status: creating /cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/bootcycle-spec.gmk
config.status: creating /cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/compare.sh
config.status: creating /cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/Makefile
config.status: creating /cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/custom-spec.gmk
config.status: creating /cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/install-spec.gmk

====================================================
The existing configuration has been successfully updated in
/cygdrive/c/jdk9/client/build/windows-x86-normal-server-release
using configure arguments '--with-target-bits=32'.

Configuration summary:
* Debug level:    release
* HS debug level: product
* JDK variant:    normal
* JVM variants:   server
* OpenJDK target: OS: windows, CPU architecture: x86, address length: 32

Tools summary:
* Environment:    cygwin version 1.7.34(0.285/5/3) (root at /cygdrive/c/cygwin)
* Boot JDK:       java version "1.8.0_31"  Java(TM) SE Runtime Environment (build 1.8.0_31-b13)  Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)   (at /cygdrive/c/jdk1.8.0_31)
* Toolchain:      microsoft (Microsoft Visual Studio 2010)
* C Compiler:     Version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)
* C++ Compiler:   Version 16.00.30319.01 (at /cygdrive/c/progra~2/micros~1.0/vc/bin/cl)

Build performance summary:
* Cores to use:   4
* Memory limit:   8097 MB

WARNING: The result of this configuration has overridden an older
configuration. You *should* run 'make clean' to make sure you get a
proper build. Failure to do so might result in strange build problems.


From martijnverburg at gmail.com  Tue Apr 14 08:05:40 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 14 Apr 2015 09:05:40 +0100
Subject: Build attempts to install /usr/local/jvm/ binary in an invalid
	location on Mac OS X
Message-ID: <CAP7YuATr=BtkQKzmLv0CUp7SQtPCFB92MdwELVVbePYxNGX6vg@mail.gmail.com>

Hi all,

Using Configuration:

using configure arguments '--with-boot-jdk=/Library/Java/JavaVirtualMachines
/jdk1.8.0_40.jdk/Contents/Home/ --with-tools-dir=/opt/local/bin/ --with-
toolchain-type=gcc --with-freetype-lib=/usr/X11/lib/ --with-freetype
-include=/usr/X11/include/freetype2/'.

-----

It attempts to install a binary at /usr/local/jvm/openjdk-1.9.0-internal.  /
usr/local/jvm doesn't exist on Mac OS X and can't be created (need sudo)

----


Compiling 5 files for BUILD_GENMODULESLIST
Building targets 'clean install' in configuration
'macosx-x86_64-normal-server-release'
Cleaning hotspot build artifacts ... done
Cleaning jdk build artifacts ... done
Cleaning bootcycle-build build artifacts ... done
Cleaning test build artifacts ... done
Cleaning buildtools build artifacts ... done
Cleaning support build artifacts ... done
Cleaning images build artifacts ... done
Cleaning make-support build artifacts ... done
Cleaning test-make build artifacts ... done
Cleaning bundles build artifacts ... done
Cleaned all build artifacts.
Compiling 5 files for BUILD_GENMODULESLIST
Installing jdk image into /usr/local/jvm/openjdk-1.9.0-internal
and creating 0 links from /usr/local/bin into the jdk.
mkdir: /usr/local/jvm/openjdk-1.9.0-internal: Permission denied
make[3]: *** [install] Error 1
make[2]: *** [install] Error 2
make[1]: *** [main] Error 2
make: *** [clean] Error 2

Cheers,
Martijn


From volker.simonis at gmail.com  Tue Apr 14 08:35:13 2015
From: volker.simonis at gmail.com (Volker Simonis)
Date: Tue, 14 Apr 2015 10:35:13 +0200
Subject: jdk9 windows build failure
In-Reply-To: <552CC7B1.7040307@oracle.com>
References: <5528511A.7090003@oracle.com>
	<CA+3eh12S+0zLKnUcn_aerHdX0KK-tc46hs4rK2g=+sgps4hbCw@mail.gmail.com>
	<552CC7B1.7040307@oracle.com>
Message-ID: <CA+3eh11Hy2VY8vDTYWLHE=i5PARNTNwdaJngHJdZwaqKEe6cTA@mail.gmail.com>

Hi Prasanta,

the COFF isue is a known problem with VS2010 after installing VS2012
or .NET 4.5.1. There exist various workarounds - just google for "LINK
: fatal error LNK1123: failure during conversion to COFF: file
invalid".

The easiest and fastes solution is to remove the bad version of
"cvtres.exe" which is causing the problem as explained in the second
answer at the stackowerflow question
http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval

Regards,
Volker

On Tue, Apr 14, 2015 at 9:54 AM, prasanta sadhukhan
<prasanta.sadhukhan at oracle.com> wrote:
> Hi All,
>
> I also faced this problem when I update my forest through "sh get_source.sh"
> and run "configure", "make clean" followed by "make"
>
>    Creating library jvm.lib and object jvm.exp
> LINK : fatal error LNK1123: failure during conversion to COFF: file invalid
> or corrupt
> NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return
> code '0x463'
> Stop.
> NMAKE : fatal error U1077: 'cd' : return code '0x2'
> Stop.
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
> 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
> Stop.
> make[5]: *** [generic_build2] Error 2
> Makefile:230: recipe for target 'generic_build2' failed
> Makefile:177: recipe for target 'product' failed
> make[4]: *** [product] Error 2
> HotspotWrapper.gmk:44: recipe for target
> '/cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp'
> failed
> make[3]: ***
> [/cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp]
> Error 1
> make[2]: *** [hotspot] Error 1
> make/Main.gmk:193: recipe for target 'hotspot' failed
> make[2]: *** Waiting for unfinished jobs....
>
> Regards
> Prasanta
>
> On 4/13/2015 3:28 PM, Volker Simonis wrote:
>>
>> Hi Phil,
>>
>> are you sure this is the first error?
>>
>> Can you start a new, clean build with only one build job and post
>> both, the configure line and output along with the build log (at least
>> LOG=debug).
>>
>> Have you changed you Cygwin version or are you using a new
>> disk/network share for your sources/output directory?
>>
>> I recently had two Windows build problems:
>>
>>   - wrong files permission. This could be solved by adding the 'noacl'
>> option to the list of default mount options in /etc/fstab of your
>> Cygwin installation.
>>   - I had  "multiple target patterns" failures which only appeared if
>> using Cygwin make version less than 4.1.
>>
>> But both these problems can be at least partially related to our own,
>> modified build environment.
>>
>> Regards,
>> Volker
>>
>> On Sat, Apr 11, 2015 at 12:39 AM, Phil Race <philip.race at oracle.com>
>> wrote:
>>>
>>> For some time (a couple of weeks) I have run into the following error
>>> whenever I try to build on Windows on my system
>>> I've been using forever ..  I have worked around it by doing builds using
>>> JPRT but its getting annoying.
>>> Does anyone have a clue what I am doing wrong. This happens on brand new
>>> clean forests etc.
>>>
>>> make[3]: *** No rule to make target
>>>
>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch',
>>> needed by
>>>
>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'.
>>> Stop.
>>> make[3]: *** Waiting for unfinished jobs....
>>> make[2]: *** [jdk.xml.bind-java] Error 1
>>> make[2]: *** Waiting for unfinished jobs....
>>> make[3]: *** No rule to make target
>>>
>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch',
>>> needed by
>>>
>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'.
>>> Stop.
>>> make[3]: *** Waiting for unfinished jobs....
>>> make[2]: *** [java.xml.ws-java] Error 1
>>>
>>> -phil.
>
>


From magnus.ihse.bursie at oracle.com  Tue Apr 14 09:46:39 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 14 Apr 2015 11:46:39 +0200
Subject: Build attempts to install /usr/local/jvm/ binary in an invalid
	location on Mac OS X
In-Reply-To: <CAP7YuATr=BtkQKzmLv0CUp7SQtPCFB92MdwELVVbePYxNGX6vg@mail.gmail.com>
References: <CAP7YuATr=BtkQKzmLv0CUp7SQtPCFB92MdwELVVbePYxNGX6vg@mail.gmail.com>
Message-ID: <552CE1FF.10204@oracle.com>

Hi Martijn,

On 2015-04-14 10:05, Martijn Verburg wrote:
> Hi all,
>
> Using Configuration:
>
> using configure arguments '--with-boot-jdk=/Library/Java/JavaVirtualMachines
> /jdk1.8.0_40.jdk/Contents/Home/ --with-tools-dir=/opt/local/bin/ --with-
> toolchain-type=gcc --with-freetype-lib=/usr/X11/lib/ --with-freetype
> -include=/usr/X11/include/freetype2/'.
>
> -----
>
> It attempts to install a binary at /usr/local/jvm/openjdk-1.9.0-internal.  /
> usr/local/jvm doesn't exist on Mac OS X and can't be created (need sudo)

The "install" target is probably in need of a lot of TLC. I wouldn't be 
surprised if it has bit-rotted. However, in all normal circumstances, 
running it *will* require root/sudo credentials -- the whole point is to 
install the newly built JDK into a system-wide location.
The suggested commands for doing this is:
 > bash configure --prefix=...
 > make all
 > sudo make install

so that you don't run more of the build than necessary as root. Also 
note that, in theory, you should be able to select another location 
using the build-in autoconf --prefix option. If you select a path 
writable by your user, you will not require the sudo part. I'm not sure 
how well tested that is, though.

/Magnus



From prasanta.sadhukhan at oracle.com  Tue Apr 14 09:47:09 2015
From: prasanta.sadhukhan at oracle.com (prasanta sadhukhan)
Date: Tue, 14 Apr 2015 15:17:09 +0530
Subject: jdk9 windows build failure
In-Reply-To: <CA+3eh11Hy2VY8vDTYWLHE=i5PARNTNwdaJngHJdZwaqKEe6cTA@mail.gmail.com>
References: <5528511A.7090003@oracle.com>	<CA+3eh12S+0zLKnUcn_aerHdX0KK-tc46hs4rK2g=+sgps4hbCw@mail.gmail.com>	<552CC7B1.7040307@oracle.com>
	<CA+3eh11Hy2VY8vDTYWLHE=i5PARNTNwdaJngHJdZwaqKEe6cTA@mail.gmail.com>
Message-ID: <552CE21D.7020803@oracle.com>

Thanks Volker. Renaming |C:\Program Files (x86)\Microsoft Visual Studio 
10.0\VC\BIN\cvtres.exe|
and the build is working
but I wonder why this happened after I update my forest. I did not 
install VS2012 nor .NET4.5.1 myself recently.

Regards
Prasanta
On 4/14/2015 2:05 PM, Volker Simonis wrote:
> Hi Prasanta,
>
> the COFF isue is a known problem with VS2010 after installing VS2012
> or .NET 4.5.1. There exist various workarounds - just google for "LINK
> : fatal error LNK1123: failure during conversion to COFF: file
> invalid".
>
> The easiest and fastes solution is to remove the bad version of
> "cvtres.exe" which is causing the problem as explained in the second
> answer at the stackowerflow question
> http://stackoverflow.com/questions/10888391/error-link-fatal-error-lnk1123-failure-during-conversion-to-coff-file-inval
>
> Regards,
> Volker
>
> On Tue, Apr 14, 2015 at 9:54 AM, prasanta sadhukhan
> <prasanta.sadhukhan at oracle.com> wrote:
>> Hi All,
>>
>> I also faced this problem when I update my forest through "sh get_source.sh"
>> and run "configure", "make clean" followed by "make"
>>
>>     Creating library jvm.lib and object jvm.exp
>> LINK : fatal error LNK1123: failure during conversion to COFF: file invalid
>> or corrupt
>> NMAKE : fatal error U1077: 'C:\progra~2\micros~1.0\vc\bin\link.exe' : return
>> code '0x463'
>> Stop.
>> NMAKE : fatal error U1077: 'cd' : return code '0x2'
>> Stop.
>> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
>> 10.0\VC\BIN\nmake.EXE"' : return code '0x2'
>> Stop.
>> make[5]: *** [generic_build2] Error 2
>> Makefile:230: recipe for target 'generic_build2' failed
>> Makefile:177: recipe for target 'product' failed
>> make[4]: *** [product] Error 2
>> HotspotWrapper.gmk:44: recipe for target
>> '/cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp'
>> failed
>> make[3]: ***
>> [/cygdrive/c/jdk9/client/build/windows-x86-normal-server-release/hotspot/_hotspot.timestamp]
>> Error 1
>> make[2]: *** [hotspot] Error 1
>> make/Main.gmk:193: recipe for target 'hotspot' failed
>> make[2]: *** Waiting for unfinished jobs....
>>
>> Regards
>> Prasanta
>>
>> On 4/13/2015 3:28 PM, Volker Simonis wrote:
>>> Hi Phil,
>>>
>>> are you sure this is the first error?
>>>
>>> Can you start a new, clean build with only one build job and post
>>> both, the configure line and output along with the build log (at least
>>> LOG=debug).
>>>
>>> Have you changed you Cygwin version or are you using a new
>>> disk/network share for your sources/output directory?
>>>
>>> I recently had two Windows build problems:
>>>
>>>    - wrong files permission. This could be solved by adding the 'noacl'
>>> option to the list of default mount options in /etc/fstab of your
>>> Cygwin installation.
>>>    - I had  "multiple target patterns" failures which only appeared if
>>> using Cygwin make version less than 4.1.
>>>
>>> But both these problems can be at least partially related to our own,
>>> modified build environment.
>>>
>>> Regards,
>>> Volker
>>>
>>> On Sat, Apr 11, 2015 at 12:39 AM, Phil Race <philip.race at oracle.com>
>>> wrote:
>>>> For some time (a couple of weeks) I have run into the following error
>>>> whenever I try to build on Windows on my system
>>>> I've been using forever ..  I have worked around it by doing builds using
>>>> JPRT but its getting annoying.
>>>> Does anyone have a clue what I am doing wrong. This happens on brand new
>>>> clean forests etc.
>>>>
>>>> make[3]: *** No rule to make target
>>>>
>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch',
>>>> needed by
>>>>
>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'.
>>>> Stop.
>>>> make[3]: *** Waiting for unfinished jobs....
>>>> make[2]: *** [jdk.xml.bind-java] Error 1
>>>> make[2]: *** Waiting for unfinished jobs....
>>>> make[3]: *** No rule to make target
>>>>
>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch',
>>>> needed by
>>>>
>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'.
>>>> Stop.
>>>> make[3]: *** Waiting for unfinished jobs....
>>>> make[2]: *** [java.xml.ws-java] Error 1
>>>>
>>>> -phil.
>>



From erik.joelsson at oracle.com  Tue Apr 14 10:12:46 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Tue, 14 Apr 2015 12:12:46 +0200
Subject: RFR: JDK-8077419: Launcher mapfile fails linking with SS12u4
In-Reply-To: <552CC4BE.8000604@oracle.com>
References: <552BC3C6.2080409@oracle.com> <552C7112.4030004@oracle.com>
	<552CC4BE.8000604@oracle.com>
Message-ID: <552CE81E.1060106@oracle.com>

The best information that I could find about this is in the Solaris 
documentation found here:
https://docs.oracle.com/cd/E26505_01/pdf/E26506.pdf

Under the heading "Localizing Symbol Instances" there is an example 
mapfile including __Argv, __environ_lock, _environ and _lib_version. The 
text notes that symbol definitions established by your "compiler driver" 
need to be kept global. I believe this is what is happening here.

/Erik

On 2015-04-14 09:41, Erik Joelsson wrote:
>
> On 2015-04-14 03:44, David Holmes wrote:
>> Hi Erik,
>>
>> On 13/04/2015 11:25 PM, Erik Joelsson wrote:
>>> Hello,
>>>
>>> When building JDK 9 with Solaris Studio 12u4, linking of unpack200 and
>>> the java launchers fails due to symbols not being exported. A typical
>>> error message looks like this:
>>>
>>> Undefined first referenced
>>>   symbol in file
>>> __environ_lock
>>> /net/sthserver02/share/sundevtools/devtools/i586/devkit/SS12u4-Solaris11u1/SS12u4-slim/lib/compilers/amd64/crt1x.o 
>>>
>>> (symbol has no version assigned)
>>>
>>> The fix seems to be to add these symbols to the mapfiles.
>>
>> I'm perplexed - what are these symbols and why are we exporting them 
>> ?? I see we already had __environ_lock on x86, but I can't actually 
>> find these in our source code (environ_lock, longdouble_used).
>>
> I don't know. I suspect that these are implicitly created by the 
> compiler and in SS12u4, the implicitly linked lib/obj files suddenly 
> need access to them. Perhaps we should try to ask the SS compiler team 
> for clarification? My googling couldn't find a better answer at least.
>
> /Erik
>
>> David
>>
>>> I also noted that the format of the make dependency files generated by
>>> the compiler is slightly different which required a small adjustment to
>>> our rewriting logic for them to remove leading whitespace.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077419
>>> Webrev: http://cr.openjdk.java.net/~erikj/8077419/webrev.01/
>>>
>>> /Erik
>



From david.holmes at oracle.com  Tue Apr 14 10:36:33 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 14 Apr 2015 20:36:33 +1000
Subject: RFR: JDK-8077419: Launcher mapfile fails linking with SS12u4
In-Reply-To: <552CE81E.1060106@oracle.com>
References: <552BC3C6.2080409@oracle.com> <552C7112.4030004@oracle.com>
	<552CC4BE.8000604@oracle.com> <552CE81E.1060106@oracle.com>
Message-ID: <552CEDB1.4030903@oracle.com>

On 14/04/2015 8:12 PM, Erik Joelsson wrote:
> The best information that I could find about this is in the Solaris
> documentation found here:
> https://docs.oracle.com/cd/E26505_01/pdf/E26506.pdf
>
> Under the heading "Localizing Symbol Instances" there is an example
> mapfile including __Argv, __environ_lock, _environ and _lib_version. The
> text notes that symbol definitions established by your "compiler driver"
> need to be kept global. I believe this is what is happening here.

Thanks Erik. From a quick read I don't really understand what is 
happening here, but I suspect we're doing something "not quite right" 
somewhere that causes this. It seems really ugly to have to define these 
in a map file. I wonder if our compiler experts can shed some light on 
why we need to do this and how to avoid it?

But for expediency that shouldn't hold up getting this fix in place.

Thanks,
David

> /Erik
>
> On 2015-04-14 09:41, Erik Joelsson wrote:
>>
>> On 2015-04-14 03:44, David Holmes wrote:
>>> Hi Erik,
>>>
>>> On 13/04/2015 11:25 PM, Erik Joelsson wrote:
>>>> Hello,
>>>>
>>>> When building JDK 9 with Solaris Studio 12u4, linking of unpack200 and
>>>> the java launchers fails due to symbols not being exported. A typical
>>>> error message looks like this:
>>>>
>>>> Undefined first referenced
>>>>   symbol in file
>>>> __environ_lock
>>>> /net/sthserver02/share/sundevtools/devtools/i586/devkit/SS12u4-Solaris11u1/SS12u4-slim/lib/compilers/amd64/crt1x.o
>>>>
>>>> (symbol has no version assigned)
>>>>
>>>> The fix seems to be to add these symbols to the mapfiles.
>>>
>>> I'm perplexed - what are these symbols and why are we exporting them
>>> ?? I see we already had __environ_lock on x86, but I can't actually
>>> find these in our source code (environ_lock, longdouble_used).
>>>
>> I don't know. I suspect that these are implicitly created by the
>> compiler and in SS12u4, the implicitly linked lib/obj files suddenly
>> need access to them. Perhaps we should try to ask the SS compiler team
>> for clarification? My googling couldn't find a better answer at least.
>>
>> /Erik
>>
>>> David
>>>
>>>> I also noted that the format of the make dependency files generated by
>>>> the compiler is slightly different which required a small adjustment to
>>>> our rewriting logic for them to remove leading whitespace.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077419
>>>> Webrev: http://cr.openjdk.java.net/~erikj/8077419/webrev.01/
>>>>
>>>> /Erik
>>
>


From magnus.ihse.bursie at oracle.com  Tue Apr 14 12:01:18 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Tue, 14 Apr 2015 14:01:18 +0200
Subject: RFR: JDK-8077419: Launcher mapfile fails linking with SS12u4
In-Reply-To: <552CEDB1.4030903@oracle.com>
References: <552BC3C6.2080409@oracle.com>
	<552C7112.4030004@oracle.com>	<552CC4BE.8000604@oracle.com>
	<552CE81E.1060106@oracle.com> <552CEDB1.4030903@oracle.com>
Message-ID: <552D018E.3020506@oracle.com>

On 2015-04-14 12:36, David Holmes wrote:
> On 14/04/2015 8:12 PM, Erik Joelsson wrote:
>> The best information that I could find about this is in the Solaris
>> documentation found here:
>> https://docs.oracle.com/cd/E26505_01/pdf/E26506.pdf
>>
>> Under the heading "Localizing Symbol Instances" there is an example
>> mapfile including __Argv, __environ_lock, _environ and _lib_version. The
>> text notes that symbol definitions established by your "compiler driver"
>> need to be kept global. I believe this is what is happening here.
>
> Thanks Erik. From a quick read I don't really understand what is 
> happening here, but I suspect we're doing something "not quite right" 
> somewhere that causes this. It seems really ugly to have to define 
> these in a map file. I wonder if our compiler experts can shed some 
> light on why we need to do this and how to avoid it?
>
> But for expediency that shouldn't hold up getting this fix in place.

I agree with you 100%. This fix is enough for the time being, but it 
smells funny. On the other hand, the PDF Erik links to seems to indicate 
that this is indeed what needs to be done when having a map file, so it 
might be correct (and just sunstudio that has a smelly design). I too 
would like to get some input from sunstudio compiler experts, though.

/Magnus


From philip.race at oracle.com  Tue Apr 14 17:41:09 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 14 Apr 2015 10:41:09 -0700
Subject: jdk9 windows build failure
In-Reply-To: <552B6366.7000306@oracle.com>
References: <5528511A.7090003@oracle.com> <552B6366.7000306@oracle.com>
Message-ID: <552D5135.3040204@oracle.com>


On 4/12/2015 11:34 PM, Erik Joelsson wrote:
> That looks weird. What does your 
> /cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/make-support/module-deps.gmk 
> look like?

It looks OK  to me. I do have these lines :-
DEPS_java.xml.bind := java.compiler java.datatransfer java.base 
java.desktop java.logging java.activation java.xml
..
DEPS_jdk.xml.bind := jdk.compiler java.compiler java.xml.bind 
java.datatransfer java.base java.desktop java.logging java.activation 
java.xml

.. and lots of other similar lines. No obvious errors.

> What happens if you do "make java.xml.bind-java"? 

sh-4.1$ make java.xml.bind-java
Building target(s) 'java.xml.bind-java' in configuration 
'windows-x86-normal-server-release'
Finished building target(s) 'java.xml.bind-java' in configuration 
'windows-x86-normal-server-release'

So that part succeeded,  but repeating "make" after that results in the 
same error I reported in my initial email.

> Exactly how did you run make to have this happen?

I typed "make" :-). Running in a cygwin shell that is inside a cmd.exe 
shell (not a cygwin window).
Same as I have always done.

-phil.

>
> /Erik
>
> On 2015-04-11 00:39, Phil Race wrote:
>> For some time (a couple of weeks) I have run into the following error 
>> whenever I try to build on Windows on my system
>> I've been using forever ..  I have worked around it by doing builds 
>> using JPRT but its getting annoying.
>> Does anyone have a clue what I am doing wrong. This happens on brand 
>> new clean forests etc.
>>
>> make[3]: *** No rule to make target 
>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
>> needed by 
>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'. 
>> Stop.
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [jdk.xml.bind-java] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> make[3]: *** No rule to make target 
>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
>> needed by 
>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'. 
>> Stop.
>> make[3]: *** Waiting for unfinished jobs....
>> make[2]: *** [java.xml.ws-java] Error 1
>>
>> -phil.
>



From martijnverburg at gmail.com  Tue Apr 14 21:14:11 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Tue, 14 Apr 2015 23:14:11 +0200
Subject: Build attempts to install /usr/local/jvm/ binary in an invalid
	location on Mac OS X
In-Reply-To: <552CE1FF.10204@oracle.com>
References: <CAP7YuATr=BtkQKzmLv0CUp7SQtPCFB92MdwELVVbePYxNGX6vg@mail.gmail.com>
	<552CE1FF.10204@oracle.com>
Message-ID: <CAP7YuAQr+Tc=3jD1oDUsMo4f5xTgDBjwEDin+rGrGd5_W-AWKg@mail.gmail.com>

Hi Magnus,

Thanks for the detailed explanation, appreciated as always!  I'll just
execute make clean images for now and reference the binary via its absolute
path as required.

Of course I'm now onto the next build error ;-).  But I'll open a separate
thread for that tomorrow.

Cheers,
Martijn

On 14 April 2015 at 11:46, Magnus Ihse Bursie <magnus.ihse.bursie at oracle.com
> wrote:

> Hi Martijn,
>
> On 2015-04-14 10:05, Martijn Verburg wrote:
>
>> Hi all,
>>
>> Using Configuration:
>>
>> using configure arguments '--with-boot-jdk=/Library/
>> Java/JavaVirtualMachines
>> /jdk1.8.0_40.jdk/Contents/Home/ --with-tools-dir=/opt/local/bin/ --with-
>> toolchain-type=gcc --with-freetype-lib=/usr/X11/lib/ --with-freetype
>> -include=/usr/X11/include/freetype2/'.
>>
>> -----
>>
>> It attempts to install a binary at /usr/local/jvm/openjdk-1.9.0-internal.
>> /
>> usr/local/jvm doesn't exist on Mac OS X and can't be created (need sudo)
>>
>
> The "install" target is probably in need of a lot of TLC. I wouldn't be
> surprised if it has bit-rotted. However, in all normal circumstances,
> running it *will* require root/sudo credentials -- the whole point is to
> install the newly built JDK into a system-wide location.
> The suggested commands for doing this is:
> > bash configure --prefix=...
> > make all
> > sudo make install
>
> so that you don't run more of the build than necessary as root. Also note
> that, in theory, you should be able to select another location using the
> build-in autoconf --prefix option. If you select a path writable by your
> user, you will not require the sudo part. I'm not sure how well tested that
> is, though.
>
> /Magnus
>
>


From philip.race at oracle.com  Tue Apr 14 22:42:23 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 14 Apr 2015 15:42:23 -0700
Subject: jdk9 windows build failure
In-Reply-To: <552D5135.3040204@oracle.com>
References: <5528511A.7090003@oracle.com> <552B6366.7000306@oracle.com>
	<552D5135.3040204@oracle.com>
Message-ID: <552D97CF.2000700@oracle.com>


> What happens if you do "make java.xml.bind-java"? 

Update: This *apparently* succeeded (ie it didn't say it had failed) but 
it did not create the "batch" file.
And that is why the subsequent "jdk.xml.bind" target did not succeed.

After some exploration I found I was picking up an older version of 
cygwin make (3.81).
Updating my path to pick up a newer cygwin version (4.1) it went smoothly.

Maybe the README-builds.html should not say "Any GNU make 3.81 or newer"

-phil.


On 4/14/2015 10:41 AM, Phil Race wrote:
>
> On 4/12/2015 11:34 PM, Erik Joelsson wrote:
>> That looks weird. What does your 
>> /cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/make-support/module-deps.gmk 
>> look like?
>
> It looks OK  to me. I do have these lines :-
> DEPS_java.xml.bind := java.compiler java.datatransfer java.base 
> java.desktop java.logging java.activation java.xml
> ..
> DEPS_jdk.xml.bind := jdk.compiler java.compiler java.xml.bind 
> java.datatransfer java.base java.desktop java.logging java.activation 
> java.xml
>
> .. and lots of other similar lines. No obvious errors.
>
>> What happens if you do "make java.xml.bind-java"? 
>
> sh-4.1$ make java.xml.bind-java
> Building target(s) 'java.xml.bind-java' in configuration 
> 'windows-x86-normal-server-release'
> Finished building target(s) 'java.xml.bind-java' in configuration 
> 'windows-x86-normal-server-release'
>
> So that part succeeded,  but repeating "make" after that results in 
> the same error I reported in my initial email.
>
>> Exactly how did you run make to have this happen?
>
> I typed "make" :-). Running in a cygwin shell that is inside a cmd.exe 
> shell (not a cygwin window).
> Same as I have always done.
>
> -phil.
>
>>
>> /Erik
>>
>> On 2015-04-11 00:39, Phil Race wrote:
>>> For some time (a couple of weeks) I have run into the following 
>>> error whenever I try to build on Windows on my system
>>> I've been using forever ..  I have worked around it by doing builds 
>>> using JPRT but its getting annoying.
>>> Does anyone have a clue what I am doing wrong. This happens on brand 
>>> new clean forests etc.
>>>
>>> make[3]: *** No rule to make target 
>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
>>> needed by 
>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'. 
>>> Stop.
>>> make[3]: *** Waiting for unfinished jobs....
>>> make[2]: *** [jdk.xml.bind-java] Error 1
>>> make[2]: *** Waiting for unfinished jobs....
>>> make[3]: *** No rule to make target 
>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
>>> needed by 
>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'. 
>>> Stop.
>>> make[3]: *** Waiting for unfinished jobs....
>>> make[2]: *** [java.xml.ws-java] Error 1
>>>
>>> -phil.
>>
>



From david.katleman at oracle.com  Tue Apr 14 23:44:50 2015
From: david.katleman at oracle.com (David Katleman)
Date: Tue, 14 Apr 2015 16:44:50 -0700
Subject: jdk9 windows build failure
In-Reply-To: <552D97CF.2000700@oracle.com>
References: <5528511A.7090003@oracle.com>
	<552B6366.7000306@oracle.com>	<552D5135.3040204@oracle.com>
	<552D97CF.2000700@oracle.com>
Message-ID: <552DA672.5080305@oracle.com>

We went through this exercise in January.

RE intentionally uses what is the documented minimum gnumake (3.81), to 
verify that builds work with the oldest supported gnumake.

> On 2015/1/31 4:01, David Katleman wrote:
>
> You need to revert your 4.0 change make to JDK9 builds.   Until dev 
> upgrades the minimum gnumake used in the JDK 9 builds to 4.0, RE must 
> continue to build with the current official minimum, which is 3.81, to 
> catch that the official minimum still works, as in JDK-8071651 
> <https://bugs.openjdk.java.net/browse/JDK-8071651>.
>
> I've opened up a high priority enhancement request to get the official 
> gnumake updated, JDK-8072023 
> <https://bugs.openjdk.java.net/browse/JDK-8072023>.

Until we update gnumake for windows (JDK-8072023 
<https://bugs.openjdk.java.net/browse/JDK-8072023>), issues like what 
Phil found with gnumake 3.81 should be fixed.

     Thanks
             Dave


On 4/14/2015 3:42 PM, Phil Race wrote:
>
>> What happens if you do "make java.xml.bind-java"? 
>
> Update: This *apparently* succeeded (ie it didn't say it had failed) 
> but it did not create the "batch" file.
> And that is why the subsequent "jdk.xml.bind" target did not succeed.
>
> After some exploration I found I was picking up an older version of 
> cygwin make (3.81).
> Updating my path to pick up a newer cygwin version (4.1) it went 
> smoothly.
>
> Maybe the README-builds.html should not say "Any GNU make 3.81 or newer"
>
> -phil.
>
>
> On 4/14/2015 10:41 AM, Phil Race wrote:
>>
>> On 4/12/2015 11:34 PM, Erik Joelsson wrote:
>>> That looks weird. What does your 
>>> /cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/make-support/module-deps.gmk 
>>> look like?
>>
>> It looks OK  to me. I do have these lines :-
>> DEPS_java.xml.bind := java.compiler java.datatransfer java.base 
>> java.desktop java.logging java.activation java.xml
>> ..
>> DEPS_jdk.xml.bind := jdk.compiler java.compiler java.xml.bind 
>> java.datatransfer java.base java.desktop java.logging java.activation 
>> java.xml
>>
>> .. and lots of other similar lines. No obvious errors.
>>
>>> What happens if you do "make java.xml.bind-java"? 
>>
>> sh-4.1$ make java.xml.bind-java
>> Building target(s) 'java.xml.bind-java' in configuration 
>> 'windows-x86-normal-server-release'
>> Finished building target(s) 'java.xml.bind-java' in configuration 
>> 'windows-x86-normal-server-release'
>>
>> So that part succeeded,  but repeating "make" after that results in 
>> the same error I reported in my initial email.
>>
>>> Exactly how did you run make to have this happen?
>>
>> I typed "make" :-). Running in a cygwin shell that is inside a 
>> cmd.exe shell (not a cygwin window).
>> Same as I have always done.
>>
>> -phil.
>>
>>>
>>> /Erik
>>>
>>> On 2015-04-11 00:39, Phil Race wrote:
>>>> For some time (a couple of weeks) I have run into the following 
>>>> error whenever I try to build on Windows on my system
>>>> I've been using forever ..  I have worked around it by doing builds 
>>>> using JPRT but its getting annoying.
>>>> Does anyone have a clue what I am doing wrong. This happens on 
>>>> brand new clean forests etc.
>>>>
>>>> make[3]: *** No rule to make target 
>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
>>>> needed by 
>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'. 
>>>> Stop.
>>>> make[3]: *** Waiting for unfinished jobs....
>>>> make[2]: *** [jdk.xml.bind-java] Error 1
>>>> make[2]: *** Waiting for unfinished jobs....
>>>> make[3]: *** No rule to make target 
>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
>>>> needed by 
>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'. 
>>>> Stop.
>>>> make[3]: *** Waiting for unfinished jobs....
>>>> make[2]: *** [java.xml.ws-java] Error 1
>>>>
>>>> -phil.
>>>
>>
>



From erik.joelsson at oracle.com  Wed Apr 15 07:41:55 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 15 Apr 2015 09:41:55 +0200
Subject: RFR: JDK-8072023: Investigate and upgrade the minimum supported
	gnumake for JDK 9, from 3.81 to 4.0
Message-ID: <552E1643.6090808@oracle.com>

Please review this change to README-builds.html. I have updated all 
references to the GNU make version to specify that we recommend 4.0 or 
later on Windows. Cygwin has been shipping with 4.x for a long time now 
and we have been using it internally since the source code layout 
change. Using older versions of make, particularly 3.81 version commonly 
used for JDK 7, has been known to cause trouble with the JDK 9 (post src 
reshuffle) build. While 3.82.x versions probably still works in many 
cases, I would rather have us move to 4.x since there are features there 
we would eventually like to be able to use.

Bug: https://bugs.openjdk.java.net/browse/JDK-8072023
Patch:
diff -r d0321d15e0a0 README-builds.html
--- a/README-builds.html
+++ b/README-builds.html
@@ -41,7 +41,8 @@
                          The build is now a "<code>configure &amp;&amp; 
make</code>" style build
                      </li>
                      <li>
-                        Any GNU make 3.81 or newer should work
+                        Any GNU make 3.81 or newer should work, except on
+                        Windows where 4.0 or newer is recommended.
                      </li>
                      <li>
                          The build should scale, i.e. more processors 
should
@@ -358,8 +359,8 @@
                  For all systems:
                  <ul>
                      <li>
-                        Be sure the GNU make utility is version 3.81 or 
newer,
-                        e.g. run "<code>make -version</code>"
+                        Be sure the GNU make utility is version 3.81 
(4.0 on
+                        windows) or newer, e.g. run "<code>make 
-version</code>"
                      </li>
                      <li>
                          Install a
@@ -1726,10 +1727,10 @@
              A few notes about using GNU make:
              <ul>
                  <li>
-                    You need GNU make version 3.81 or newer.
-                    If the GNU make utility on your systems is not
-                    3.81 or newer,
-                    see <a href="#buildgmake">"Building GNU make"</a>.
+                    You need GNU make version 3.81 or newer. On Windows 
4.0 or
+                    newer is recommended.
+                    If the GNU make utility on your systems is not of a 
suitable
+                    version see <a href="#buildgmake">"Building GNU 
make"</a>.
                  </li>
                  <li>
                      Place the location of the GNU make binary in the


/Erik


From erik.joelsson at oracle.com  Wed Apr 15 09:24:56 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 15 Apr 2015 11:24:56 +0200
Subject: RFR: JDK-8077824: Introduce DefineNativeToolchain to handle toolchain
	configurations
Message-ID: <552E2E68.5060806@oracle.com>

The macro SetupNativeCompilation handles various overrides of the 
compiler and linker used for compilation. There is also a LANG option, 
which implies that it needs to be told if it's compiling C or C++ when 
in reality, this is handled automatically. The real purpose of the LANG 
option is just to decide which executable to use for linking in certain 
conditions/platforms.

I would like to put some more structure around this by introducing a new 
macro, DefineNativeToolchain. There s a default and a couple of others, 
extending the default, for linking with the C++ compiler, building for 
the build platform etc. These definitions will help ensure that all the 
necessary executables and options are overridden for each of these usecases.

Bug: https://bugs.openjdk.java.net/browse/JDK-8077824

Webrevs:

The implementation is in NativeCompilation.gmk. I took the liberty of 
cleaning out some unused compiler/linker variables.
Top: http://cr.openjdk.java.net/~erikj/8077824/webrev.root.01/

The jdk changes are mostly just removing "LANG:=" and replacing it when 
necessary with "TOOLCHAIN:=TOOLCHAIN_LINK_CXX". Note that this is not 
needed for Windows only configurations.
Jdk: http://cr.openjdk.java.net/~erikj/8077824/webrev.jdk.01/

/Erik


From erik.joelsson at oracle.com  Wed Apr 15 09:41:36 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 15 Apr 2015 11:41:36 +0200
Subject: RFR: JDK-8077814: Add .DELETE_ON_ERROR to makefiles
Message-ID: <552E3250.5080500@oracle.com>

Please review this small change which will improve incremental build 
reliability. By defining the pseudo target .DELETE_ON_ERROR, make will 
automatically remove the target of a rule if the recipe fails or is 
interrupted (typically ctrl-c). By doing this, the target is 
automatically rebuilt on the next make invocation instead of left in a 
possibly broken state.

I was under the impression that this functionality was already active in 
make, but it appears we have to actively enable it. I chose to put it at 
the top of make/common/MakeBase.gmk as we tend to include that file 
everywhere. The alternative would be spec.gmk.in, but I think we should 
try to keep that file for communication from configure to make.

Bug: https://bugs.openjdk.java.net/browse/JDK-8077814
Patch:
diff -r d0321d15e0a0 make/common/MakeBase.gmk
--- a/make/common/MakeBase.gmk
+++ b/make/common/MakeBase.gmk
@@ -36,6 +36,10 @@
    $(error MakeBase.gmk needs SPEC set to a proper spec.gmk)
  endif

+# By defining this pseudo target, make will automatically remove targets
+# if their recipe fails so that a rebuild is automatically triggered on the
+# next make invocation.
+.DELETE_ON_ERROR:

  ##############################
  # Functions

/Erik


From magnus.ihse.bursie at oracle.com  Wed Apr 15 11:33:59 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 15 Apr 2015 13:33:59 +0200
Subject: RFR: JDK-8077814: Add .DELETE_ON_ERROR to makefiles
In-Reply-To: <552E3250.5080500@oracle.com>
References: <552E3250.5080500@oracle.com>
Message-ID: <552E4CA7.9030303@oracle.com>

On 2015-04-15 11:41, Erik Joelsson wrote:
> Please review this small change which will improve incremental build 
> reliability. By defining the pseudo target .DELETE_ON_ERROR, make will 
> automatically remove the target of a rule if the recipe fails or is 
> interrupted (typically ctrl-c). By doing this, the target is 
> automatically rebuilt on the next make invocation instead of left in a 
> possibly broken state.
>
> I was under the impression that this functionality was already active 
> in make, but it appears we have to actively enable it. I chose to put 
> it at the top of make/common/MakeBase.gmk as we tend to include that 
> file everywhere. The alternative would be spec.gmk.in, but I think we 
> should try to keep that file for communication from configure to make.

Looks good to me.

/Magnus

>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8077814
> Patch:
> diff -r d0321d15e0a0 make/common/MakeBase.gmk
> --- a/make/common/MakeBase.gmk
> +++ b/make/common/MakeBase.gmk
> @@ -36,6 +36,10 @@
>    $(error MakeBase.gmk needs SPEC set to a proper spec.gmk)
>  endif
>
> +# By defining this pseudo target, make will automatically remove targets
> +# if their recipe fails so that a rebuild is automatically triggered 
> on the
> +# next make invocation.
> +.DELETE_ON_ERROR:
>
>  ##############################
>  # Functions
>
> /Erik



From magnus.ihse.bursie at oracle.com  Wed Apr 15 13:12:56 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 15 Apr 2015 15:12:56 +0200
Subject: RFR: JDK-8077847 Better handling of Windows executable manifest
	version
Message-ID: <552E63D8.7050306@oracle.com>

On windows, many executables have an assembly manifest embedded. This 
sets among other things the JDK version. Our current handling of this is 
sub-optimal, using template files that are modified at build time. 
Instead, a command line option to MT, the manifest processor, can be used.

At places we also try to include manifest information twice, using the 
old style of declaring the manifest file in an .rc file. This is not 
needed when we use MT for post-processing.

Bug: https://bugs.openjdk.java.net/browse/JDK-8077847
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8077847-better-windows-manifest/webrev.01

/Magnus


From tim.bell at oracle.com  Wed Apr 15 15:23:27 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 15 Apr 2015 08:23:27 -0700
Subject: RFR: JDK-8077814: Add .DELETE_ON_ERROR to makefiles
In-Reply-To: <552E4CA7.9030303@oracle.com>
References: <552E3250.5080500@oracle.com> <552E4CA7.9030303@oracle.com>
Message-ID: <552E826F.2020509@oracle.com>

Erik:

> On 2015-04-15 11:41, Erik Joelsson wrote:
>> Please review this small change which will improve incremental build 
>> reliability. By defining the pseudo target .DELETE_ON_ERROR, make 
>> will automatically remove the target of a rule if the recipe fails or 
>> is interrupted (typically ctrl-c). By doing this, the target is 
>> automatically rebuilt on the next make invocation instead of left in 
>> a possibly broken state.
>>
>> I was under the impression that this functionality was already active 
>> in make, but it appears we have to actively enable it. I chose to put 
>> it at the top of make/common/MakeBase.gmk as we tend to include that 
>> file everywhere. The alternative would be spec.gmk.in, but I think we 
>> should try to keep that file for communication from configure to make.
>
> Looks good to me.
>
> /Magnus

Looks good to me as well.

/Tim

>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077814
>> Patch:
>> diff -r d0321d15e0a0 make/common/MakeBase.gmk
>> --- a/make/common/MakeBase.gmk
>> +++ b/make/common/MakeBase.gmk
>> @@ -36,6 +36,10 @@
>>    $(error MakeBase.gmk needs SPEC set to a proper spec.gmk)
>>  endif
>>
>> +# By defining this pseudo target, make will automatically remove 
>> targets
>> +# if their recipe fails so that a rebuild is automatically triggered 
>> on the
>> +# next make invocation.
>> +.DELETE_ON_ERROR:
>>
>>  ##############################
>>  # Functions



From martijnverburg at gmail.com  Wed Apr 15 15:42:37 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Wed, 15 Apr 2015 17:42:37 +0200
Subject: Mac OS X build errors missing instancetype + further issues just
	after building jdk.xml.ws
Message-ID: <CAP7YuARGAsc=5bEGC8_M6u1nKaCg_o2r+6=RRO=6LMjOySSWhA@mail.gmail.com>

Hi all,

Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8

--------

After getting past the defined(__OPENBSD__) bug I'm running into a host of
new errors starting with:

/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
error: unknown type name 'instancetype'
 - (instancetype)self;
 ^

------------

The error listings are strong with this one, so I've paste binned the full
output :-)

http://pastebin.com/REgQA8i5

Cheers,
Martijn


From philip.race at oracle.com  Wed Apr 15 15:52:42 2015
From: philip.race at oracle.com (Phil Race)
Date: Wed, 15 Apr 2015 08:52:42 -0700
Subject: jdk9 windows build failure
In-Reply-To: <552DA672.5080305@oracle.com>
References: <5528511A.7090003@oracle.com>
	<552B6366.7000306@oracle.com>	<552D5135.3040204@oracle.com>
	<552D97CF.2000700@oracle.com> <552DA672.5080305@oracle.com>
Message-ID: <552E894A.70207@oracle.com>

If RE are currently building with 3.81 then either not all 3.81's are 
the same
or there's something more subtle going on, since I see this failure when
cloning the forests directly from RE promoted builds.

-phil.

On 4/14/15 4:44 PM, David Katleman wrote:
> We went through this exercise in January.
>
> RE intentionally uses what is the documented minimum gnumake (3.81), 
> to verify that builds work with the oldest supported gnumake.
>
>> On 2015/1/31 4:01, David Katleman wrote:
>>
>> You need to revert your 4.0 change make to JDK9 builds.   Until dev 
>> upgrades the minimum gnumake used in the JDK 9 builds to 4.0, RE must 
>> continue to build with the current official minimum, which is 3.81, 
>> to catch that the official minimum still works, as in JDK-8071651 
>> <https://bugs.openjdk.java.net/browse/JDK-8071651>.
>>
>> I've opened up a high priority enhancement request to get the 
>> official gnumake updated, JDK-8072023 
>> <https://bugs.openjdk.java.net/browse/JDK-8072023>.
>
> Until we update gnumake for windows (JDK-8072023 
> <https://bugs.openjdk.java.net/browse/JDK-8072023>), issues like what 
> Phil found with gnumake 3.81 should be fixed.
>
>     Thanks
>             Dave
>
>
> On 4/14/2015 3:42 PM, Phil Race wrote:
>>
>>> What happens if you do "make java.xml.bind-java"? 
>>
>> Update: This *apparently* succeeded (ie it didn't say it had failed) 
>> but it did not create the "batch" file.
>> And that is why the subsequent "jdk.xml.bind" target did not succeed.
>>
>> After some exploration I found I was picking up an older version of 
>> cygwin make (3.81).
>> Updating my path to pick up a newer cygwin version (4.1) it went 
>> smoothly.
>>
>> Maybe the README-builds.html should not say "Any GNU make 3.81 or newer"
>>
>> -phil.
>>
>>
>> On 4/14/2015 10:41 AM, Phil Race wrote:
>>>
>>> On 4/12/2015 11:34 PM, Erik Joelsson wrote:
>>>> That looks weird. What does your 
>>>> /cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/make-support/module-deps.gmk 
>>>> look like?
>>>
>>> It looks OK  to me. I do have these lines :-
>>> DEPS_java.xml.bind := java.compiler java.datatransfer java.base 
>>> java.desktop java.logging java.activation java.xml
>>> ..
>>> DEPS_jdk.xml.bind := jdk.compiler java.compiler java.xml.bind 
>>> java.datatransfer java.base java.desktop java.logging 
>>> java.activation java.xml
>>>
>>> .. and lots of other similar lines. No obvious errors.
>>>
>>>> What happens if you do "make java.xml.bind-java"? 
>>>
>>> sh-4.1$ make java.xml.bind-java
>>> Building target(s) 'java.xml.bind-java' in configuration 
>>> 'windows-x86-normal-server-release'
>>> Finished building target(s) 'java.xml.bind-java' in configuration 
>>> 'windows-x86-normal-server-release'
>>>
>>> So that part succeeded,  but repeating "make" after that results in 
>>> the same error I reported in my initial email.
>>>
>>>> Exactly how did you run make to have this happen?
>>>
>>> I typed "make" :-). Running in a cygwin shell that is inside a 
>>> cmd.exe shell (not a cygwin window).
>>> Same as I have always done.
>>>
>>> -phil.
>>>
>>>>
>>>> /Erik
>>>>
>>>> On 2015-04-11 00:39, Phil Race wrote:
>>>>> For some time (a couple of weeks) I have run into the following 
>>>>> error whenever I try to build on Windows on my system
>>>>> I've been using forever ..  I have worked around it by doing 
>>>>> builds using JPRT but its getting annoying.
>>>>> Does anyone have a clue what I am doing wrong. This happens on 
>>>>> brand new clean forests etc.
>>>>>
>>>>> make[3]: *** No rule to make target 
>>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
>>>>> needed by 
>>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/jdk.xml.bind/_the.jdk.xml.bind_batch'. 
>>>>> Stop.
>>>>> make[3]: *** Waiting for unfinished jobs....
>>>>> make[2]: *** [jdk.xml.bind-java] Error 1
>>>>> make[2]: *** Waiting for unfinished jobs....
>>>>> make[3]: *** No rule to make target 
>>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.bind/_the.java.xml.bind_batch', 
>>>>> needed by 
>>>>> `/cygdrive/c/jdks/jdk9/build/windows-x86-normal-server-release/jdk/modules/java.xml.ws/_the.java.xml.ws_batch'. 
>>>>> Stop.
>>>>> make[3]: *** Waiting for unfinished jobs....
>>>>> make[2]: *** [java.xml.ws-java] Error 1
>>>>>
>>>>> -phil.
>>>>
>>>
>>
>



From david.dehaven at oracle.com  Wed Apr 15 16:22:48 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Wed, 15 Apr 2015 09:22:48 -0700
Subject: Mac OS X build errors missing instancetype + further issues just
	after building jdk.xml.ws
In-Reply-To: <CAP7YuARGAsc=5bEGC8_M6u1nKaCg_o2r+6=RRO=6LMjOySSWhA@mail.gmail.com>
References: <CAP7YuARGAsc=5bEGC8_M6u1nKaCg_o2r+6=RRO=6LMjOySSWhA@mail.gmail.com>
Message-ID: <99F135A1-F9EB-47E6-881D-3B2AFD0AAAEC@oracle.com>


> Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8
> 
> --------
> 
> After getting past the defined(__OPENBSD__) bug I'm running into a host of
> new errors starting with:
> 
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
> error: unknown type name 'instancetype'
> - (instancetype)self;
> ^

You're using an SDK that's intended to be used exclusively with clang. I think you'd have to go back to MacOSX10.8.sdk for compatibility with gcc.

I'm curious why you're even trying to compile with gcc?

-DrD-



From tim.bell at oracle.com  Wed Apr 15 18:48:32 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 15 Apr 2015 11:48:32 -0700
Subject: RFR: JDK-8077824: Introduce DefineNativeToolchain to handle
	toolchain configurations
In-Reply-To: <552E2E68.5060806@oracle.com>
References: <552E2E68.5060806@oracle.com>
Message-ID: <552EB280.6050308@oracle.com>

Erik:

> The macro SetupNativeCompilation handles various overrides of the 
> compiler and linker used for compilation. There is also a LANG option, 
> which implies that it needs to be told if it's compiling C or C++ when 
> in reality, this is handled automatically. The real purpose of the 
> LANG option is just to decide which executable to use for linking in 
> certain conditions/platforms.
>
> I would like to put some more structure around this by introducing a 
> new macro, DefineNativeToolchain. There s a default and a couple of 
> others, extending the default, for linking with the C++ compiler, 
> building for the build platform etc. These definitions will help 
> ensure that all the necessary executables and options are overridden 
> for each of these usecases.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8077824
>
> Webrevs:
>
> The implementation is in NativeCompilation.gmk. I took the liberty of 
> cleaning out some unused compiler/linker variables.
> Top: http://cr.openjdk.java.net/~erikj/8077824/webrev.root.01/
>
> The jdk changes are mostly just removing "LANG:=" and replacing it 
> when necessary with "TOOLCHAIN:=TOOLCHAIN_LINK_CXX". Note that this is 
> not needed for Windows only configurations.
> Jdk: http://cr.openjdk.java.net/~erikj/8077824/webrev.jdk.01/

Nice cleanup.  Looks good to me.

Tim




From tim.bell at oracle.com  Wed Apr 15 19:41:44 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 15 Apr 2015 12:41:44 -0700
Subject: RFR: JDK-8072023: Investigate and upgrade the minimum supported
	gnumake for JDK 9, from 3.81 to 4.0
In-Reply-To: <552E1643.6090808@oracle.com>
References: <552E1643.6090808@oracle.com>
Message-ID: <552EBEF8.3060708@oracle.com>

Erik:

> Please review this change to README-builds.html. I have updated all 
> references to the GNU make version to specify that we recommend 4.0 or 
> later on Windows. Cygwin has been shipping with 4.x for a long time 
> now and we have been using it internally since the source code layout 
> change. Using older versions of make, particularly 3.81 version 
> commonly used for JDK 7, has been known to cause trouble with the JDK 
> 9 (post src reshuffle) build. While 3.82.x versions probably still 
> works in many cases, I would rather have us move to 4.x since there 
> are features there we would eventually like to be able to use.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8072023

Looks good to me-

/Tim



From david.katleman at oracle.com  Wed Apr 15 20:01:17 2015
From: david.katleman at oracle.com (David Katleman)
Date: Wed, 15 Apr 2015 13:01:17 -0700
Subject: RFR: JDK-8072023: Investigate and upgrade the minimum supported
	gnumake for JDK 9, from 3.81 to 4.0
In-Reply-To: <552E1643.6090808@oracle.com>
References: <552E1643.6090808@oracle.com>
Message-ID: <552EC38D.4070006@oracle.com>

The doc change is fine.

You need a corresponding autoconf update to verify that 4.0 or later is 
being used on windows builds, to prevent cryptic errors like Phil was 
running into.

The windows build should fail in configure if it finds a gnumake older 
than 4.0

         Thanks
                 Dave

On 4/15/2015 12:41 AM, Erik Joelsson wrote:
> Please review this change to README-builds.html. I have updated all 
> references to the GNU make version to specify that we recommend 4.0 or 
> later on Windows. Cygwin has been shipping with 4.x for a long time 
> now and we have been using it internally since the source code layout 
> change. Using older versions of make, particularly 3.81 version 
> commonly used for JDK 7, has been known to cause trouble with the JDK 
> 9 (post src reshuffle) build. While 3.82.x versions probably still 
> works in many cases, I would rather have us move to 4.x since there 
> are features there we would eventually like to be able to use.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8072023
> Patch:
> diff -r d0321d15e0a0 README-builds.html
> --- a/README-builds.html
> +++ b/README-builds.html
> @@ -41,7 +41,8 @@
>                          The build is now a "<code>configure 
> &amp;&amp; make</code>" style build
>                      </li>
>                      <li>
> -                        Any GNU make 3.81 or newer should work
> +                        Any GNU make 3.81 or newer should work, 
> except on
> +                        Windows where 4.0 or newer is recommended.
>                      </li>
>                      <li>
>                          The build should scale, i.e. more processors 
> should
> @@ -358,8 +359,8 @@
>                  For all systems:
>                  <ul>
>                      <li>
> -                        Be sure the GNU make utility is version 3.81 
> or newer,
> -                        e.g. run "<code>make -version</code>"
> +                        Be sure the GNU make utility is version 3.81 
> (4.0 on
> +                        windows) or newer, e.g. run "<code>make 
> -version</code>"
>                      </li>
>                      <li>
>                          Install a
> @@ -1726,10 +1727,10 @@
>              A few notes about using GNU make:
>              <ul>
>                  <li>
> -                    You need GNU make version 3.81 or newer.
> -                    If the GNU make utility on your systems is not
> -                    3.81 or newer,
> -                    see <a href="#buildgmake">"Building GNU make"</a>.
> +                    You need GNU make version 3.81 or newer. On 
> Windows 4.0 or
> +                    newer is recommended.
> +                    If the GNU make utility on your systems is not of 
> a suitable
> +                    version see <a href="#buildgmake">"Building GNU 
> make"</a>.
>                  </li>
>                  <li>
>                      Place the location of the GNU make binary in the
>
>
> /Erik



From tim.bell at oracle.com  Wed Apr 15 20:49:22 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Wed, 15 Apr 2015 13:49:22 -0700
Subject: RFR: JDK-8077847 Better handling of Windows executable manifest
	version
In-Reply-To: <552E63D8.7050306@oracle.com>
References: <552E63D8.7050306@oracle.com>
Message-ID: <552ECED2.1090605@oracle.com>

On 04/15/15 06:12, Magnus Ihse Bursie wrote:
> On windows, many executables have an assembly manifest embedded. This 
> sets among other things the JDK version. Our current handling of this 
> is sub-optimal, using template files that are modified at build time. 
> Instead, a command line option to MT, the manifest processor, can be 
> used.

Thanks for the trip down memory lane!  We worked with manifests back in 
the VS 2005 and 2008 time-frame [1]  :-)

> At places we also try to include manifest information twice, using the 
> old style of declaring the manifest file in an .rc file. This is not 
> needed when we use MT for post-processing.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8077847
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8077847-better-windows-manifest/webrev.01

Looks good to me.

Tim

[1] https://bugs.openjdk.java.net/browse/JDK-6523947
      https://bugs.openjdk.java.net/browse/JDK-6816366
       and several others...



From joe.darcy at oracle.com  Wed Apr 15 23:50:24 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Wed, 15 Apr 2015 16:50:24 -0700
Subject: JDK 9 RFR of JDK-8077912: Turn on doclint checking for more modules
Message-ID: <552EF940.3000302@oracle.com>

Hello,

Please review the patch below to enable doclint checking on more modules 
in the JDK 9 build:

     JDK-8077912: Turn on doclint checking for more modules
     http://cr.openjdk.java.net/~darcy/8077912.0/

(Some doclint cleanup is needed on java.management and java.transaction 
before doclint checking can be enabled in those modules.)

Thanks,

-Joe

--- old/make/CompileJavaModules.gmk    2015-04-15 16:45:27.288035401 -0700
+++ new/make/CompileJavaModules.gmk    2015-04-15 16:45:27.216035400 -0700
@@ -262,6 +262,18 @@

  ################################################################################

+java.instrument_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
'-Xdoclint/package:java.*,javax.*'
+
+################################################################################
+
+java.logging_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference 
'-Xdoclint/package:java.*,javax.*'
+
+################################################################################
+
+java.prefs_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
'-Xdoclint/package:java.*,javax.*'
+
+################################################################################
+
  java.sql_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
'-Xdoclint/package:java.*,javax.*'
  java.sql_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS

@@ -340,6 +352,14 @@

  ################################################################################

+java.security.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
'-Xdoclint/package:java.*,javax.*'
+
+################################################################################
+
+java.smartcardio.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
'-Xdoclint/package:java.*,javax.*'
+
+################################################################################
+
  java.xml.crypto_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
'-Xdoclint/package:java.*,javax.*'
  java.xml.crypto_COPY := .dtd .xml
  java.xml.crypto_CLEAN := .properties



From kim.barrett at oracle.com  Thu Apr 16 04:11:59 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 16 Apr 2015 00:11:59 -0400
Subject: BSD variables not declared? (jdk8 & jdk 9 builds)
In-Reply-To: <552CC4FD.4010904@oracle.com>
References: <CAP7YuAROCv3p+=7wQ6Rfsrxm3yCb0ZvzUCzbZoFji2oM0Ht41A@mail.gmail.com>
	<552CC0A0.8090206@oracle.com> <552CC4FD.4010904@oracle.com>
Message-ID: <A6375837-2372-4228-9344-8F0A26388F8A@oracle.com>

On Apr 14, 2015, at 3:42 AM, David Holmes <david.holmes at oracle.com> wrote:
> 
> On 14/04/2015 5:24 PM, Magnus Ihse Bursie wrote:
>> On 2015-04-12 17:01, Martijn Verburg wrote:
>>> Hi all,
>>> 
>>> On Mac OS X 10.10.2 using gcc 4.8 run make clean images
>>> 
>>> When compiling either jdk8 or jdk9 from scratch I get the following BSD
>>> undefined errors:
>>> 
>>> Compiling
>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp
>>> 
>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1150:7:
>>> 
>>> error: "__FreeBSD__" is not defined [-Werror=undef]
>>>  #elif __FreeBSD__
>>>        ^
>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1152:7:
>>> 
>>> error: "__OpenBSD__" is not defined [-Werror=undef]
>>>  #elif __OpenBSD__
>>>        ^
>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk8/hotspot/src/os/bsd/vm/os_bsd.cpp:1154:7:
>>> 
>>> error: "__NetBSD__" is not defined [-Werror=undef]
>>>  #elif __NetBSD__
>> 
>> That sounds strange. Why would an undefined preprocessor variable
>> trigger an error? I have never heard about this before.
> 
> "-Wundef option causes GCC to warn whenever it encounters an identifier which is not a macro in an ?#if?. "
> 
> Hence we should be using
> 
> #elif defined(__FreeBSD__)
> 
> etc in this context. It may be the compiler normally doesn't look at the erroneous else cases, but this compiler does (or else __APPLE__ is not defined and so we hit these else cases where we don't normally.) ??
> 
>> Since it is in hotspot code, maybe you can get a better response by
>> asking on a hotspot list.
> 
> Yes looks like a hotspot issue. I filed:
> 
> https://bugs.openjdk.java.net/browse/JDK-8077674
> 
> Follow ups on hotspot-runtime-dev please.
> 
> David

Should we be building with -Wundef at all?  The code being complained
about is standards conforming and has a well defined meaning.  The
proposed changes could result in unexpectedly different behavior,
either now or in the future.

Do we know for sure that for all of the

  #elif IDENTIFIER
=>
  #elif defined(IDENTIFIER)

changes there are no situations where IDENTIFIER might be defined 0?

This might be of interest:
https://gcc.gnu.org/gcc-4.4/porting_to.html
Preprocessor conditionals always evaluated




From kim.barrett at oracle.com  Thu Apr 16 04:26:13 2015
From: kim.barrett at oracle.com (Kim Barrett)
Date: Thu, 16 Apr 2015 00:26:13 -0400
Subject: BSD variables not declared? (jdk8 & jdk 9 builds)
In-Reply-To: <A6375837-2372-4228-9344-8F0A26388F8A@oracle.com>
References: <CAP7YuAROCv3p+=7wQ6Rfsrxm3yCb0ZvzUCzbZoFji2oM0Ht41A@mail.gmail.com>
	<552CC0A0.8090206@oracle.com> <552CC4FD.4010904@oracle.com>
	<A6375837-2372-4228-9344-8F0A26388F8A@oracle.com>
Message-ID: <572482B2-63D8-40B5-AD0A-FFA12232C8A8@oracle.com>

> This might be of interest:
> https://gcc.gnu.org/gcc-4.4/porting_to.html
> Preprocessor conditionals always evaluated

Also see this:
http://lists.boost.org/Archives/boost/2011/08/184657.php

?????
This has come up before. The problem is with code like this: 

#if !defined(SOMETHING) 
#elif SOMETHING() == 1 
#endif 

In recent versions of gcc it fails when SOMETHING isn't defined 
because the 'SOMETHING() == 1' clause is always evaluated - even 
though the if statement has already been resolved. This is apparently 
compliant with the standard. 

The solution is to write: 

#if !defined(SOMETHING) 
#else 
# if SOMETHING() == 1 
# endif 
#endif

??????

That same technique could be applied by us, as an alternative to the proposed changes.
But it?s pretty annoying ugly, with sometimes long string of trailing #endif lines.



From david.holmes at oracle.com  Thu Apr 16 04:49:03 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Apr 2015 14:49:03 +1000
Subject: BSD variables not declared? (jdk8 & jdk 9 builds)
In-Reply-To: <572482B2-63D8-40B5-AD0A-FFA12232C8A8@oracle.com>
References: <CAP7YuAROCv3p+=7wQ6Rfsrxm3yCb0ZvzUCzbZoFji2oM0Ht41A@mail.gmail.com>
	<552CC0A0.8090206@oracle.com> <552CC4FD.4010904@oracle.com>
	<A6375837-2372-4228-9344-8F0A26388F8A@oracle.com>
	<572482B2-63D8-40B5-AD0A-FFA12232C8A8@oracle.com>
Message-ID: <552F3F3F.4030008@oracle.com>

Hi Kim,

On 16/04/2015 2:26 PM, Kim Barrett wrote:
>> This might be of interest:
>> https://gcc.gnu.org/gcc-4.4/porting_to.html
>> Preprocessor conditionals always evaluated
>
> Also see this:
> http://lists.boost.org/Archives/boost/2011/08/184657.php
>
> ?????
> This has come up before. The problem is with code like this:
>
> #if !defined(SOMETHING)
> #elif SOMETHING() == 1
> #endif
>
> In recent versions of gcc it fails when SOMETHING isn't defined
> because the 'SOMETHING() == 1' clause is always evaluated - even
> though the if statement has already been resolved. This is apparently
> compliant with the standard.
>
> The solution is to write:
>
> #if !defined(SOMETHING)
> #else
> # if SOMETHING() == 1
> # endif
> #endif
>
> ??????
>
> That same technique could be applied by us, as an alternative to the proposed changes.
> But it?s pretty annoying ugly, with sometimes long string of trailing #endif lines.

Thanks for all the additional information.

So it seems to me there are two choices here:

a) Use the change proposed but verify that the variables concerned are 
ones that if defined will never be defined to be zero (which I believe 
to be the case but may have trouble proving :( )

b) Replace the 'elif XXX' with 'else ifdef XXX'

For the few cases involved here (b) seems the easier path.

David


From erik.joelsson at oracle.com  Thu Apr 16 08:41:04 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 16 Apr 2015 10:41:04 +0200
Subject: RFR: JDK-8072023: Investigate and upgrade the minimum supported
	gnumake for JDK 9, from 3.81 to 4.0
In-Reply-To: <552EC38D.4070006@oracle.com>
References: <552E1643.6090808@oracle.com> <552EC38D.4070006@oracle.com>
Message-ID: <552F75A0.6040008@oracle.com>

Good point, I will fix that.

/Erik

On 2015-04-15 22:01, David Katleman wrote:
> The doc change is fine.
>
> You need a corresponding autoconf update to verify that 4.0 or later 
> is being used on windows builds, to prevent cryptic errors like Phil 
> was running into.
>
> The windows build should fail in configure if it finds a gnumake older 
> than 4.0
>
>         Thanks
>                 Dave
>
> On 4/15/2015 12:41 AM, Erik Joelsson wrote:
>> Please review this change to README-builds.html. I have updated all 
>> references to the GNU make version to specify that we recommend 4.0 
>> or later on Windows. Cygwin has been shipping with 4.x for a long 
>> time now and we have been using it internally since the source code 
>> layout change. Using older versions of make, particularly 3.81 
>> version commonly used for JDK 7, has been known to cause trouble with 
>> the JDK 9 (post src reshuffle) build. While 3.82.x versions probably 
>> still works in many cases, I would rather have us move to 4.x since 
>> there are features there we would eventually like to be able to use.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072023
>> Patch:
>> diff -r d0321d15e0a0 README-builds.html
>> --- a/README-builds.html
>> +++ b/README-builds.html
>> @@ -41,7 +41,8 @@
>>                          The build is now a "<code>configure 
>> &amp;&amp; make</code>" style build
>>                      </li>
>>                      <li>
>> -                        Any GNU make 3.81 or newer should work
>> +                        Any GNU make 3.81 or newer should work, 
>> except on
>> +                        Windows where 4.0 or newer is recommended.
>>                      </li>
>>                      <li>
>>                          The build should scale, i.e. more processors 
>> should
>> @@ -358,8 +359,8 @@
>>                  For all systems:
>>                  <ul>
>>                      <li>
>> -                        Be sure the GNU make utility is version 3.81 
>> or newer,
>> -                        e.g. run "<code>make -version</code>"
>> +                        Be sure the GNU make utility is version 3.81 
>> (4.0 on
>> +                        windows) or newer, e.g. run "<code>make 
>> -version</code>"
>>                      </li>
>>                      <li>
>>                          Install a
>> @@ -1726,10 +1727,10 @@
>>              A few notes about using GNU make:
>>              <ul>
>>                  <li>
>> -                    You need GNU make version 3.81 or newer.
>> -                    If the GNU make utility on your systems is not
>> -                    3.81 or newer,
>> -                    see <a href="#buildgmake">"Building GNU make"</a>.
>> +                    You need GNU make version 3.81 or newer. On 
>> Windows 4.0 or
>> +                    newer is recommended.
>> +                    If the GNU make utility on your systems is not 
>> of a suitable
>> +                    version see <a href="#buildgmake">"Building GNU 
>> make"</a>.
>>                  </li>
>>                  <li>
>>                      Place the location of the GNU make binary in the
>>
>>
>> /Erik
>



From magnus.ihse.bursie at oracle.com  Thu Apr 16 08:42:10 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 16 Apr 2015 10:42:10 +0200
Subject: RFR: JDK-8077824: Introduce DefineNativeToolchain to handle
	toolchain configurations
In-Reply-To: <552E2E68.5060806@oracle.com>
References: <552E2E68.5060806@oracle.com>
Message-ID: <552F75E2.9030602@oracle.com>

On 2015-04-15 11:24, Erik Joelsson wrote:
> The macro SetupNativeCompilation handles various overrides of the 
> compiler and linker used for compilation. There is also a LANG option, 
> which implies that it needs to be told if it's compiling C or C++ when 
> in reality, this is handled automatically. The real purpose of the 
> LANG option is just to decide which executable to use for linking in 
> certain conditions/platforms.
>
> I would like to put some more structure around this by introducing a 
> new macro, DefineNativeToolchain. There s a default and a couple of 
> others, extending the default, for linking with the C++ compiler, 
> building for the build platform etc. These definitions will help 
> ensure that all the necessary executables and options are overridden 
> for each of these usecases.

In general, I'm very happy with this. It's a nice encapsulation!

However, I do have a bunch of issues/questions:

* AR is missing from the documentation of DefineNativeToolchain.

* LDCXX is mentioned in the documentation of DefineNativeToolchain, but 
not used. It seems that it should not be used there, but it should be 
removed from the documentation.

* DefineNativeToolchain seems to do nothing if EXTENDS is not set. This 
is since all the "magic" is done by NamedParamsMacroTemplate. Maybe this 
should be explained in a comment.

* The comment "LANG C or C++" should be removed for SetupNativeCompilation.

* The call to $(CC) when processing RC files, should (perhaps?) be $1_CC 
now.

* $1_MT should be in VARDEPS. (Maybe not really a regression, but it 
would be nice to fix it now)

* I can't find that $1_CC is in VARDEPS either, should probably go in 
somewhere. In general, all the TOOLCHAIN variables should go in VARDEPS.

* BUILD_LIBJAWT seems to have lost a LANG := C++ but not gained a 
TOOLCHAIN := TOOLCHAIN_LINK_CXX. The same goes for LIBAWT_LANG, 
BUILD_LIBSUNMSCAPI, BUILD_LIBJSOUNDDS and the accessbridge stuff in 
Lib-jdk.accessibility.gmk.

Is there some reason that the change here does not change the resulting 
link behavior? Or is this an oversight?

/Magnus


From erik.joelsson at oracle.com  Thu Apr 16 08:42:39 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 16 Apr 2015 10:42:39 +0200
Subject: JDK 9 RFR of JDK-8077912: Turn on doclint checking for more
	modules
In-Reply-To: <552EF940.3000302@oracle.com>
References: <552EF940.3000302@oracle.com>
Message-ID: <552F75FF.5000407@oracle.com>

Looks ok to me.

/Erik

On 2015-04-16 01:50, joe darcy wrote:
> Hello,
>
> Please review the patch below to enable doclint checking on more 
> modules in the JDK 9 build:
>
>     JDK-8077912: Turn on doclint checking for more modules
>     http://cr.openjdk.java.net/~darcy/8077912.0/
>
> (Some doclint cleanup is needed on java.management and 
> java.transaction before doclint checking can be enabled in those 
> modules.)
>
> Thanks,
>
> -Joe
>
> --- old/make/CompileJavaModules.gmk    2015-04-15 16:45:27.288035401 
> -0700
> +++ new/make/CompileJavaModules.gmk    2015-04-15 16:45:27.216035400 
> -0700
> @@ -262,6 +262,18 @@
>
>  ################################################################################ 
>
>
> +java.instrument_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
> +java.logging_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
> +java.prefs_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
>  java.sql_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
>  java.sql_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS
>
> @@ -340,6 +352,14 @@
>
>  ################################################################################ 
>
>
> +java.security.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
> +java.smartcardio.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
>  java.xml.crypto_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
>  java.xml.crypto_COPY := .dtd .xml
>  java.xml.crypto_CLEAN := .properties
>



From magnus.ihse.bursie at oracle.com  Thu Apr 16 08:49:59 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 16 Apr 2015 10:49:59 +0200
Subject: JDK 9 RFR of JDK-8077912: Turn on doclint checking for more
	modules
In-Reply-To: <552EF940.3000302@oracle.com>
References: <552EF940.3000302@oracle.com>
Message-ID: <552F77B7.6060801@oracle.com>

On 2015-04-16 01:50, joe darcy wrote:
> Hello,
>
> Please review the patch below to enable doclint checking on more 
> modules in the JDK 9 build:
>
>     JDK-8077912: Turn on doclint checking for more modules
>     http://cr.openjdk.java.net/~darcy/8077912.0/
>
> (Some doclint cleanup is needed on java.management and 
> java.transaction before doclint checking can be enabled in those 
> modules.)

Looks good to me. I like that warm fuzzy feeling I get when I see all 
these cleanups. Thank you :)

/Magnus

>
> Thanks,
>
> -Joe
>
> --- old/make/CompileJavaModules.gmk    2015-04-15 16:45:27.288035401 
> -0700
> +++ new/make/CompileJavaModules.gmk    2015-04-15 16:45:27.216035400 
> -0700
> @@ -262,6 +262,18 @@
>
>  ################################################################################ 
>
>
> +java.instrument_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
> +java.logging_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
> +java.prefs_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
>  java.sql_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
>  java.sql_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS
>
> @@ -340,6 +352,14 @@
>
>  ################################################################################ 
>
>
> +java.security.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
> +java.smartcardio.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
> +
> +################################################################################ 
>
> +
>  java.xml.crypto_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
> '-Xdoclint/package:java.*,javax.*'
>  java.xml.crypto_COPY := .dtd .xml
>  java.xml.crypto_CLEAN := .properties
>



From magnus.ihse.bursie at oracle.com  Thu Apr 16 09:02:37 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 16 Apr 2015 11:02:37 +0200
Subject: jdk9 windows build failure
In-Reply-To: <552DA672.5080305@oracle.com>
References: <5528511A.7090003@oracle.com>	<552B6366.7000306@oracle.com>	<552D5135.3040204@oracle.com>	<552D97CF.2000700@oracle.com>
	<552DA672.5080305@oracle.com>
Message-ID: <552F7AAD.2040101@oracle.com>

On 2015-04-15 01:44, David Katleman wrote:
> We went through this exercise in January.
>
> RE intentionally uses what is the documented minimum gnumake (3.81), 
> to verify that builds work with the oldest supported gnumake.
>
>> On 2015/1/31 4:01, David Katleman wrote:
>>
>> You need to revert your 4.0 change make to JDK9 builds.   Until dev 
>> upgrades the minimum gnumake used in the JDK 9 builds to 4.0, RE must 
>> continue to build with the current official minimum, which is 3.81, 
>> to catch that the official minimum still works, as in JDK-8071651 
>> <https://bugs.openjdk.java.net/browse/JDK-8071651>.
>>
>> I've opened up a high priority enhancement request to get the 
>> official gnumake updated, JDK-8072023 
>> <https://bugs.openjdk.java.net/browse/JDK-8072023>.
>
> Until we update gnumake for windows (JDK-8072023 
> <https://bugs.openjdk.java.net/browse/JDK-8072023>), issues like what 
> Phil found with gnumake 3.81 should be fixed.

I'm not really comfortable with letting go of support for GNU Make 3.81. 
It's been around for a long time and was the latest stable release for a 
long time when GNU Make didn't make much progress. While Windows is 
special, since cygwin more easily pushes newer versions on users, if 
this is indeed a problem with make 3.81 maybe we should try to go to the 
bottom with it.

What makes java.xml.bind so special that make 3.81 should barf on it, 
but no other modules?

/Magnus


From magnus.ihse.bursie at oracle.com  Thu Apr 16 09:05:29 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 16 Apr 2015 11:05:29 +0200
Subject: RFR: JDK-8072023: Investigate and upgrade the minimum supported
	gnumake for JDK 9, from 3.81 to 4.0
In-Reply-To: <552E1643.6090808@oracle.com>
References: <552E1643.6090808@oracle.com>
Message-ID: <552F7B59.2060301@oracle.com>

On 2015-04-15 09:41, Erik Joelsson wrote:
> Please review this change to README-builds.html. I have updated all 
> references to the GNU make version to specify that we recommend 4.0 or 
> later on Windows. Cygwin has been shipping with 4.x for a long time 
> now and we have been using it internally since the source code layout 
> change. Using older versions of make, particularly 3.81 version 
> commonly used for JDK 7, has been known to cause trouble with the JDK 
> 9 (post src reshuffle) build. While 3.82.x versions probably still 
> works in many cases, I would rather have us move to 4.x since there 
> are features there we would eventually like to be able to use.
Am I just a backwards old-timer if I think we should still support 3.81? 
It's one thing to recommend 4.x to users, I'll agree with that anytime, 
but should we require 4.0 by a check in configure, or a warning?

/Magnus



From erik.joelsson at oracle.com  Thu Apr 16 09:29:49 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 16 Apr 2015 11:29:49 +0200
Subject: RFR: JDK-8072023: Investigate and upgrade the minimum supported
	gnumake for JDK 9, from 3.81 to 4.0
In-Reply-To: <552F7B59.2060301@oracle.com>
References: <552E1643.6090808@oracle.com> <552F7B59.2060301@oracle.com>
Message-ID: <552F810D.5010104@oracle.com>


On 2015-04-16 11:05, Magnus Ihse Bursie wrote:
> On 2015-04-15 09:41, Erik Joelsson wrote:
>> Please review this change to README-builds.html. I have updated all 
>> references to the GNU make version to specify that we recommend 4.0 
>> or later on Windows. Cygwin has been shipping with 4.x for a long 
>> time now and we have been using it internally since the source code 
>> layout change. Using older versions of make, particularly 3.81 
>> version commonly used for JDK 7, has been known to cause trouble with 
>> the JDK 9 (post src reshuffle) build. While 3.82.x versions probably 
>> still works in many cases, I would rather have us move to 4.x since 
>> there are features there we would eventually like to be able to use.
> Am I just a backwards old-timer if I think we should still support 
> 3.81? It's one thing to recommend 4.x to users, I'll agree with that 
> anytime, but should we require 4.0 by a check in configure, or a warning?
>
The "job server", which we rely heavily on in the post source-shuffle 
JDK 9 build, was not implemented in gnu make on Windows until 4.0, at 
least according to the NEWS file in the gnu make source distribution. I 
think I have seen Cygwin versions of gnu make 3.82.x sort of working 
with the job server, but I wouldn't trust that. There have also been 
multiple issues reported with the build that have simply been solved by 
using a newer (4.x) gnu make. Internally at Oracle, we have been using a 
special build of gnu make 3.81 for a long time and that version 
specifically crashed/misbehaved consistently in the new JDK 9 build.

Given all this, I find very little motivation to spend time trying to 
work around apparent issues in certain versions of gnu make on Cygwin, 
when the simple solution is to just upgrade. Especially given how simple 
it is to upgrade (Cygwin practically forces you to do it anyway). If 
someone else would like to spend this time, I won't object, but taking 
https://bugs.openjdk.java.net/browse/JDK-8071651 as an example of 
inconsistencies between versions, that person would also need to 
dedicate time to keep verifying that it's working.

I certainly agree that we shouldn't force gnu make 4.0 on all platforms 
as many linux distributions, Solaris etc are still shipping with 3.81 so 
keeping compatibility there is convenient. However, for Cygwin, that 
case cannot be made.

This all applies to Cygwin since that's the UNIX emulation environment 
we use. In msys things may be different. I would only propose this 
configure check when running on Cygwin for now.

/Erik


From erik.joelsson at oracle.com  Thu Apr 16 09:37:35 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 16 Apr 2015 11:37:35 +0200
Subject: RFR: JDK-8077847 Better handling of Windows executable manifest
	version
In-Reply-To: <552E63D8.7050306@oracle.com>
References: <552E63D8.7050306@oracle.com>
Message-ID: <552F82DF.1090505@oracle.com>

Looks good to me.

/Erik

On 2015-04-15 15:12, Magnus Ihse Bursie wrote:
> On windows, many executables have an assembly manifest embedded. This 
> sets among other things the JDK version. Our current handling of this 
> is sub-optimal, using template files that are modified at build time. 
> Instead, a command line option to MT, the manifest processor, can be 
> used.
>
> At places we also try to include manifest information twice, using the 
> old style of declaring the manifest file in an .rc file. This is not 
> needed when we use MT for post-processing.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8077847
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8077847-better-windows-manifest/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Thu Apr 16 10:01:46 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 16 Apr 2015 12:01:46 +0200
Subject: RFR: JDK-8077824: Introduce DefineNativeToolchain to handle
	toolchain configurations
In-Reply-To: <552F75E2.9030602@oracle.com>
References: <552E2E68.5060806@oracle.com> <552F75E2.9030602@oracle.com>
Message-ID: <552F888A.3020002@oracle.com>

Hello,

New webrev: http://cr.openjdk.java.net/~erikj/8077824/webrev.root.02/

On 2015-04-16 10:42, Magnus Ihse Bursie wrote:
>
> In general, I'm very happy with this. It's a nice encapsulation!
>
Thanks!
> However, I do have a bunch of issues/questions:
>
> * AR is missing from the documentation of DefineNativeToolchain.
>
Fixed
> * LDCXX is mentioned in the documentation of DefineNativeToolchain, 
> but not used. It seems that it should not be used there, but it should 
> be removed from the documentation.
Correct, removed.
>
> * DefineNativeToolchain seems to do nothing if EXTENDS is not set. 
> This is since all the "magic" is done by NamedParamsMacroTemplate. 
> Maybe this should be explained in a comment.
>
Added a comment
> * The comment "LANG C or C++" should be removed for 
> SetupNativeCompilation.
>
Removed
> * The call to $(CC) when processing RC files, should (perhaps?) be 
> $1_CC now.
>
Fixed
> * $1_MT should be in VARDEPS. (Maybe not really a regression, but it 
> would be nice to fix it now)
>
Added
> * I can't find that $1_CC is in VARDEPS either, should probably go in 
> somewhere. In general, all the TOOLCHAIN variables should go in VARDEPS.
>
$1_CC and $1_CXX were already, but for the COMPILE_VARDEPS used for 
compilation, not for linking. Missing was however $1_AS and some other 
variables used in the linker recipe. I added all that I could find.
> * BUILD_LIBJAWT seems to have lost a LANG := C++ but not gained a 
> TOOLCHAIN := TOOLCHAIN_LINK_CXX. The same goes for LIBAWT_LANG, 
> BUILD_LIBSUNMSCAPI, BUILD_LIBJSOUNDDS and the accessbridge stuff in 
> Lib-jdk.accessibility.gmk.
>
> Is there some reason that the change here does not change the 
> resulting link behavior? Or is this an oversight?
>
This is on purpose. The Windows only libraries link the same way 
regardless of C or C++ so no need to add special configuration for them.

/Erik


From erik.joelsson at oracle.com  Thu Apr 16 10:42:30 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 16 Apr 2015 12:42:30 +0200
Subject: RFR: JDK-8072023: Investigate and upgrade the minimum supported
	gnumake for JDK 9, from 3.81 to 4.0
In-Reply-To: <552F75A0.6040008@oracle.com>
References: <552E1643.6090808@oracle.com> <552EC38D.4070006@oracle.com>
	<552F75A0.6040008@oracle.com>
Message-ID: <552F9216.2060008@oracle.com>

Here is a webrev including a configure check.

http://cr.openjdk.java.net/~erikj/8072023/webrev.01/

/Erik

On 2015-04-16 10:41, Erik Joelsson wrote:
> Good point, I will fix that.
>
> /Erik
>
> On 2015-04-15 22:01, David Katleman wrote:
>> The doc change is fine.
>>
>> You need a corresponding autoconf update to verify that 4.0 or later 
>> is being used on windows builds, to prevent cryptic errors like Phil 
>> was running into.
>>
>> The windows build should fail in configure if it finds a gnumake 
>> older than 4.0
>>
>>         Thanks
>>                 Dave
>>
>> On 4/15/2015 12:41 AM, Erik Joelsson wrote:
>>> Please review this change to README-builds.html. I have updated all 
>>> references to the GNU make version to specify that we recommend 4.0 
>>> or later on Windows. Cygwin has been shipping with 4.x for a long 
>>> time now and we have been using it internally since the source code 
>>> layout change. Using older versions of make, particularly 3.81 
>>> version commonly used for JDK 7, has been known to cause trouble 
>>> with the JDK 9 (post src reshuffle) build. While 3.82.x versions 
>>> probably still works in many cases, I would rather have us move to 
>>> 4.x since there are features there we would eventually like to be 
>>> able to use.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8072023
>>> Patch:
>>> diff -r d0321d15e0a0 README-builds.html
>>> --- a/README-builds.html
>>> +++ b/README-builds.html
>>> @@ -41,7 +41,8 @@
>>>                          The build is now a "<code>configure 
>>> &amp;&amp; make</code>" style build
>>>                      </li>
>>>                      <li>
>>> -                        Any GNU make 3.81 or newer should work
>>> +                        Any GNU make 3.81 or newer should work, 
>>> except on
>>> +                        Windows where 4.0 or newer is recommended.
>>>                      </li>
>>>                      <li>
>>>                          The build should scale, i.e. more 
>>> processors should
>>> @@ -358,8 +359,8 @@
>>>                  For all systems:
>>>                  <ul>
>>>                      <li>
>>> -                        Be sure the GNU make utility is version 
>>> 3.81 or newer,
>>> -                        e.g. run "<code>make -version</code>"
>>> +                        Be sure the GNU make utility is version 
>>> 3.81 (4.0 on
>>> +                        windows) or newer, e.g. run "<code>make 
>>> -version</code>"
>>>                      </li>
>>>                      <li>
>>>                          Install a
>>> @@ -1726,10 +1727,10 @@
>>>              A few notes about using GNU make:
>>>              <ul>
>>>                  <li>
>>> -                    You need GNU make version 3.81 or newer.
>>> -                    If the GNU make utility on your systems is not
>>> -                    3.81 or newer,
>>> -                    see <a href="#buildgmake">"Building GNU make"</a>.
>>> +                    You need GNU make version 3.81 or newer. On 
>>> Windows 4.0 or
>>> +                    newer is recommended.
>>> +                    If the GNU make utility on your systems is not 
>>> of a suitable
>>> +                    version see <a href="#buildgmake">"Building GNU 
>>> make"</a>.
>>>                  </li>
>>>                  <li>
>>>                      Place the location of the GNU make binary in the
>>>
>>>
>>> /Erik
>>
>



From magnus.ihse.bursie at oracle.com  Thu Apr 16 12:12:09 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 16 Apr 2015 14:12:09 +0200
Subject: RFR: JDK-8077824: Introduce DefineNativeToolchain to handle
	toolchain configurations
In-Reply-To: <552F888A.3020002@oracle.com>
References: <552E2E68.5060806@oracle.com> <552F75E2.9030602@oracle.com>
	<552F888A.3020002@oracle.com>
Message-ID: <552FA719.9060506@oracle.com>

On 2015-04-16 12:01, Erik Joelsson wrote:
> Hello,
>
> New webrev: http://cr.openjdk.java.net/~erikj/8077824/webrev.root.02/

Looks good to me now! Just one typo: "assignements", no need to respin 
the webrev for that.

>
>
>> * BUILD_LIBJAWT seems to have lost a LANG := C++ but not gained a 
>> TOOLCHAIN := TOOLCHAIN_LINK_CXX. The same goes for LIBAWT_LANG, 
>> BUILD_LIBSUNMSCAPI, BUILD_LIBJSOUNDDS and the accessbridge stuff in 
>> Lib-jdk.accessibility.gmk.
>>
>> Is there some reason that the change here does not change the 
>> resulting link behavior? Or is this an oversight?
>>
> This is on purpose. The Windows only libraries link the same way 
> regardless of C or C++ so no need to add special configuration for them.

I realized that later. Good riddance! :)

/Magnus



From magnus.ihse.bursie at oracle.com  Thu Apr 16 12:14:03 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 16 Apr 2015 14:14:03 +0200
Subject: RFR: JDK-8072023: Investigate and upgrade the minimum supported
	gnumake for JDK 9, from 3.81 to 4.0
In-Reply-To: <552F9216.2060008@oracle.com>
References: <552E1643.6090808@oracle.com>
	<552EC38D.4070006@oracle.com>	<552F75A0.6040008@oracle.com>
	<552F9216.2060008@oracle.com>
Message-ID: <552FA78B.1030403@oracle.com>

On 2015-04-16 12:42, Erik Joelsson wrote:
> Here is a webrev including a configure check.
>
> http://cr.openjdk.java.net/~erikj/8072023/webrev.01/

Looks good to me.

/Magnus



From magnus.ihse.bursie at oracle.com  Thu Apr 16 12:15:22 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Thu, 16 Apr 2015 14:15:22 +0200
Subject: RFR: JDK-8072023: Investigate and upgrade the minimum supported
	gnumake for JDK 9, from 3.81 to 4.0
In-Reply-To: <552F810D.5010104@oracle.com>
References: <552E1643.6090808@oracle.com> <552F7B59.2060301@oracle.com>
	<552F810D.5010104@oracle.com>
Message-ID: <552FA7DA.2080903@oracle.com>

On 2015-04-16 11:29, Erik Joelsson wrote:
>
> On 2015-04-16 11:05, Magnus Ihse Bursie wrote:
>> Am I just a backwards old-timer if I think we should still support 
>> 3.81? It's one thing to recommend 4.x to users, I'll agree with that 
>> anytime, but should we require 4.0 by a check in configure, or a 
>> warning?
>>
> The "job server", which we rely heavily on in the post source-shuffle 
> JDK 9 build, was not implemented in gnu make on Windows until 4.0, at 
> least according to the NEWS file in the gnu make source distribution.
>
> [...]
>
> I certainly agree that we shouldn't force gnu make 4.0 on all 
> platforms as many linux distributions, Solaris etc are still shipping 
> with 3.81 so keeping compatibility there is convenient. However, for 
> Cygwin, that case cannot be made.

Alright. :) We'll have another requirement on Windows, I can live with that.

/Magnus


From martijnverburg at gmail.com  Thu Apr 16 13:35:47 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Thu, 16 Apr 2015 15:35:47 +0200
Subject: Mac OS X build errors missing instancetype + further issues just
	after building jdk.xml.ws
In-Reply-To: <99F135A1-F9EB-47E6-881D-3B2AFD0AAAEC@oracle.com>
References: <CAP7YuARGAsc=5bEGC8_M6u1nKaCg_o2r+6=RRO=6LMjOySSWhA@mail.gmail.com>
	<99F135A1-F9EB-47E6-881D-3B2AFD0AAAEC@oracle.com>
Message-ID: <CAP7YuAQBddqubx4pOXv4jCg-c8kObe6fgTyBt-apB1D1_bzAZw@mail.gmail.com>

Hi David,

Thanks for your response!  I was using GCC as I had a host of other errors
when using clang :-|.  I'll post those in a separate mail for comparison.

Cheers,
Martijn

On 15 April 2015 at 18:22, David DeHaven <david.dehaven at oracle.com> wrote:

>
> > Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8
> >
> > --------
> >
> > After getting past the defined(__OPENBSD__) bug I'm running into a host
> of
> > new errors starting with:
> >
> >
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
> >
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
> > error: unknown type name 'instancetype'
> > - (instancetype)self;
> > ^
>
> You're using an SDK that's intended to be used exclusively with clang. I
> think you'd have to go back to MacOSX10.8.sdk for compatibility with gcc.
>
> I'm curious why you're even trying to compile with gcc?
>
> -DrD-
>
>


From tim.bell at oracle.com  Thu Apr 16 14:46:57 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 16 Apr 2015 07:46:57 -0700
Subject: JDK 9 RFR of JDK-8077912: Turn on doclint checking for more
	modules
In-Reply-To: <552F77B7.6060801@oracle.com>
References: <552EF940.3000302@oracle.com> <552F77B7.6060801@oracle.com>
Message-ID: <552FCB61.2050003@oracle.com>

Joe:


> On 2015-04-16 01:50, joe darcy wrote:
>> Hello,
>>
>> Please review the patch below to enable doclint checking on more 
>> modules in the JDK 9 build:
>>
>>     JDK-8077912: Turn on doclint checking for more modules
>>     http://cr.openjdk.java.net/~darcy/8077912.0/
>>
>> (Some doclint cleanup is needed on java.management and 
>> java.transaction before doclint checking can be enabled in those 
>> modules.)
>
> Looks good to me. I like that warm fuzzy feeling I get when I see all 
> these cleanups. Thank you :)
>
> /Magnus


Looks good to me as well.

Tim

>> --- old/make/CompileJavaModules.gmk 2015-04-15 16:45:27.288035401 -0700
>> +++ new/make/CompileJavaModules.gmk    2015-04-15 16:45:27.216035400 
>> -0700
>> @@ -262,6 +262,18 @@
>>
>>  ################################################################################ 
>>
>>
>> +java.instrument_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>> '-Xdoclint/package:java.*,javax.*'
>> +
>> +################################################################################ 
>>
>> +
>> +java.logging_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference 
>> '-Xdoclint/package:java.*,javax.*'
>> +
>> +################################################################################ 
>>
>> +
>> +java.prefs_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>> '-Xdoclint/package:java.*,javax.*'
>> +
>> +################################################################################ 
>>
>> +
>>  java.sql_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>> '-Xdoclint/package:java.*,javax.*'
>>  java.sql_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS
>>
>> @@ -340,6 +352,14 @@
>>
>>  ################################################################################ 
>>
>>
>> +java.security.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>> '-Xdoclint/package:java.*,javax.*'
>> +
>> +################################################################################ 
>>
>> +
>> +java.smartcardio.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>> '-Xdoclint/package:java.*,javax.*'
>> +
>> +################################################################################ 
>>
>> +
>>  java.xml.crypto_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>> '-Xdoclint/package:java.*,javax.*'
>>  java.xml.crypto_COPY := .dtd .xml
>>  java.xml.crypto_CLEAN := .properties
>>
>



From philip.race at oracle.com  Thu Apr 16 15:54:25 2015
From: philip.race at oracle.com (Phil Race)
Date: Thu, 16 Apr 2015 08:54:25 -0700
Subject: jdk9 windows build failure
In-Reply-To: <552F7AAD.2040101@oracle.com>
References: <5528511A.7090003@oracle.com>	<552B6366.7000306@oracle.com>	<552D5135.3040204@oracle.com>	<552D97CF.2000700@oracle.com>
	<552DA672.5080305@oracle.com> <552F7AAD.2040101@oracle.com>
Message-ID: <552FDB31.30905@oracle.com>

 > What makes java.xml.bind so special that make 3.81 should barf on it, 
but no other modules?

Nothing that I can see. Its very strange.

-phil.

On 04/16/2015 02:02 AM, Magnus Ihse Bursie wrote:
> On 2015-04-15 01:44, David Katleman wrote:
>> We went through this exercise in January.
>>
>> RE intentionally uses what is the documented minimum gnumake (3.81), 
>> to verify that builds work with the oldest supported gnumake.
>>
>>> On 2015/1/31 4:01, David Katleman wrote:
>>>
>>> You need to revert your 4.0 change make to JDK9 builds. Until dev 
>>> upgrades the minimum gnumake used in the JDK 9 builds to 4.0, RE 
>>> must continue to build with the current official minimum, which is 
>>> 3.81, to catch that the official minimum still works, as in 
>>> JDK-8071651 <https://bugs.openjdk.java.net/browse/JDK-8071651>.
>>>
>>> I've opened up a high priority enhancement request to get the 
>>> official gnumake updated, JDK-8072023 
>>> <https://bugs.openjdk.java.net/browse/JDK-8072023>.
>>
>> Until we update gnumake for windows (JDK-8072023 
>> <https://bugs.openjdk.java.net/browse/JDK-8072023>), issues like what 
>> Phil found with gnumake 3.81 should be fixed.
>
> I'm not really comfortable with letting go of support for GNU Make 
> 3.81. It's been around for a long time and was the latest stable 
> release for a long time when GNU Make didn't make much progress. While 
> Windows is special, since cygwin more easily pushes newer versions on 
> users, if this is indeed a problem with make 3.81 maybe we should try 
> to go to the bottom with it.
>
> What makes java.xml.bind so special that make 3.81 should barf on it, 
> but no other modules?
>
> /Magnus



From tim.bell at oracle.com  Thu Apr 16 17:33:25 2015
From: tim.bell at oracle.com (Tim Bell)
Date: Thu, 16 Apr 2015 10:33:25 -0700
Subject: RFR: JDK-8077824: Introduce DefineNativeToolchain to handle
	toolchain configurations
In-Reply-To: <552F888A.3020002@oracle.com>
References: <552E2E68.5060806@oracle.com> <552F75E2.9030602@oracle.com>
	<552F888A.3020002@oracle.com>
Message-ID: <552FF265.3090803@oracle.com>

Erik:

> New webrev: http://cr.openjdk.java.net/~erikj/8077824/webrev.root.02/
>
> On 2015-04-16 10:42, Magnus Ihse Bursie wrote:
>>
>> In general, I'm very happy with this. It's a nice encapsulation!
>>
> Thanks!
>> However, I do have a bunch of issues/questions:
>>
>> * AR is missing from the documentation of DefineNativeToolchain.
>>
> Fixed
>> * LDCXX is mentioned in the documentation of DefineNativeToolchain, 
>> but not used. It seems that it should not be used there, but it 
>> should be removed from the documentation.
> Correct, removed.
>>
>> * DefineNativeToolchain seems to do nothing if EXTENDS is not set. 
>> This is since all the "magic" is done by NamedParamsMacroTemplate. 
>> Maybe this should be explained in a comment.
>>
> Added a comment
>> * The comment "LANG C or C++" should be removed for 
>> SetupNativeCompilation.
>>
> Removed
>> * The call to $(CC) when processing RC files, should (perhaps?) be 
>> $1_CC now.
>>
> Fixed
>> * $1_MT should be in VARDEPS. (Maybe not really a regression, but it 
>> would be nice to fix it now)
>>
> Added
>> * I can't find that $1_CC is in VARDEPS either, should probably go in 
>> somewhere. In general, all the TOOLCHAIN variables should go in VARDEPS.
>>
> $1_CC and $1_CXX were already, but for the COMPILE_VARDEPS used for 
> compilation, not for linking. Missing was however $1_AS and some other 
> variables used in the linker recipe. I added all that I could find.
>> * BUILD_LIBJAWT seems to have lost a LANG := C++ but not gained a 
>> TOOLCHAIN := TOOLCHAIN_LINK_CXX. The same goes for LIBAWT_LANG, 
>> BUILD_LIBSUNMSCAPI, BUILD_LIBJSOUNDDS and the accessbridge stuff in 
>> Lib-jdk.accessibility.gmk.
>>
>> Is there some reason that the change here does not change the 
>> resulting link behavior? Or is this an oversight?
>>
> This is on purpose. The Windows only libraries link the same way 
> regardless of C or C++ so no need to add special configuration for them

Even better.  Looks good to me.

Tim



From joe.darcy at oracle.com  Thu Apr 16 19:09:29 2015
From: joe.darcy at oracle.com (joe darcy)
Date: Thu, 16 Apr 2015 12:09:29 -0700
Subject: JDK 9 RFR of JDK-8077912: Turn on doclint checking for more
	modules
In-Reply-To: <552FCB61.2050003@oracle.com>
References: <552EF940.3000302@oracle.com> <552F77B7.6060801@oracle.com>
	<552FCB61.2050003@oracle.com>
Message-ID: <553008E9.4030207@oracle.com>

PS Some doclint fixes in additional modules came in and Tim did an 
off-list review to add in the new modules to the list.

Thanks,

-Joe

On 4/16/2015 7:46 AM, Tim Bell wrote:
> Joe:
>
>
>> On 2015-04-16 01:50, joe darcy wrote:
>>> Hello,
>>>
>>> Please review the patch below to enable doclint checking on more 
>>> modules in the JDK 9 build:
>>>
>>>     JDK-8077912: Turn on doclint checking for more modules
>>>     http://cr.openjdk.java.net/~darcy/8077912.0/
>>>
>>> (Some doclint cleanup is needed on java.management and 
>>> java.transaction before doclint checking can be enabled in those 
>>> modules.)
>>
>> Looks good to me. I like that warm fuzzy feeling I get when I see all 
>> these cleanups. Thank you :)
>>
>> /Magnus
>
>
> Looks good to me as well.
>
> Tim
>
>>> --- old/make/CompileJavaModules.gmk 2015-04-15 16:45:27.288035401 -0700
>>> +++ new/make/CompileJavaModules.gmk    2015-04-15 16:45:27.216035400 
>>> -0700
>>> @@ -262,6 +262,18 @@
>>>
>>>  ################################################################################ 
>>>
>>>
>>> +java.instrument_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>>> '-Xdoclint/package:java.*,javax.*'
>>> +
>>> +################################################################################ 
>>>
>>> +
>>> +java.logging_ADD_JAVAC_FLAGS := -Xdoclint:all/protected,-reference 
>>> '-Xdoclint/package:java.*,javax.*'
>>> +
>>> +################################################################################ 
>>>
>>> +
>>> +java.prefs_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>>> '-Xdoclint/package:java.*,javax.*'
>>> +
>>> +################################################################################ 
>>>
>>> +
>>>  java.sql_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>>> '-Xdoclint/package:java.*,javax.*'
>>>  java.sql_SETUP := GENERATE_JDKBYTECODE_NOWARNINGS
>>>
>>> @@ -340,6 +352,14 @@
>>>
>>>  ################################################################################ 
>>>
>>>
>>> +java.security.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>>> '-Xdoclint/package:java.*,javax.*'
>>> +
>>> +################################################################################ 
>>>
>>> +
>>> +java.smartcardio.jgss_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>>> '-Xdoclint/package:java.*,javax.*'
>>> +
>>> +################################################################################ 
>>>
>>> +
>>>  java.xml.crypto_ADD_JAVAC_FLAGS := -Xdoclint:all/protected 
>>> '-Xdoclint/package:java.*,javax.*'
>>>  java.xml.crypto_COPY := .dtd .xml
>>>  java.xml.crypto_CLEAN := .properties
>>>
>>
>



From david.dehaven at oracle.com  Thu Apr 16 20:18:51 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Thu, 16 Apr 2015 13:18:51 -0700
Subject: Mac OS X build errors missing instancetype + further issues just
	after building jdk.xml.ws
In-Reply-To: <CAP7YuAQBddqubx4pOXv4jCg-c8kObe6fgTyBt-apB1D1_bzAZw@mail.gmail.com>
References: <CAP7YuARGAsc=5bEGC8_M6u1nKaCg_o2r+6=RRO=6LMjOySSWhA@mail.gmail.com>
	<99F135A1-F9EB-47E6-881D-3B2AFD0AAAEC@oracle.com>
	<CAP7YuAQBddqubx4pOXv4jCg-c8kObe6fgTyBt-apB1D1_bzAZw@mail.gmail.com>
Message-ID: <04B950C5-B2FA-47EC-A008-B6184E350A19@oracle.com>

Sorry, I've had my blinders on for a few weeks. What's the original goal here? Are you just trying to build OpenJDK 9 on Mac OS X? If you're using clang in Xcode then it should "just work".

-DrD-

> On Apr 16, 2015, at 6:35 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
> 
> Hi David,
> 
> Thanks for your response!  I was using GCC as I had a host of other errors when using clang :-|.  I'll post those in a separate mail for comparison.
> 
> Cheers,
> Martijn
> 
> On 15 April 2015 at 18:22, David DeHaven <david.dehaven at oracle.com> wrote:
> 
> > Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8
> >
> > --------
> >
> > After getting past the defined(__OPENBSD__) bug I'm running into a host of
> > new errors starting with:
> >
> > /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
> > /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
> > error: unknown type name 'instancetype'
> > - (instancetype)self;
> > ^
> 
> You're using an SDK that's intended to be used exclusively with clang. I think you'd have to go back to MacOSX10.8.sdk for compatibility with gcc.
> 
> I'm curious why you're even trying to compile with gcc?
> 
> -DrD-
> 
> 



From david.holmes at oracle.com  Fri Apr 17 03:07:12 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 Apr 2015 13:07:12 +1000
Subject: How to keep follow up fixes with the original ?
Message-ID: <553078E0.4030804@oracle.com>

It has happened again that a broken fix, for which there was a quick 
follow up fix, has been pushed to the master without the follow up fix 
going with it. So now everyone will potentially be impacted by the bad 
fix as it propagates back down to all the forests :(

Bad fix:

https://bugs.openjdk.java.net/browse/JDK-8073634

Follow up:

https://bugs.openjdk.java.net/browse/JDK-8077563

We need something in place to ensure this doesn't happen!

David


From lana.steuck at oracle.com  Fri Apr 17 04:28:23 2015
From: lana.steuck at oracle.com (Lana Steuck)
Date: Thu, 16 Apr 2015 21:28:23 -0700
Subject: How to keep follow up fixes with the original ?
In-Reply-To: <553078E0.4030804@oracle.com>
References: <553078E0.4030804@oracle.com>
Message-ID: <55308BE7.9020908@oracle.com>

Hi David,

 > We need something in place to ensure this doesn't happen!

We push to Master after team forests successfully go through the 
following PIT steps:
- full build (hotspot ... install) for all 7 platforms
- fastdebug builds for all 7 platforms
- boot_cycle builds
- extended set of JPRT tests (the failures are getting OK-ed by dev)
- SQE teams are informed and list of fixes are submitted to SQE db
- manual testing of client-libs on main platforms.

The PIT process can be beefed up to cover more scenarios, however 
there's always a cost that comes with it. At the end, it's a balance of 
cost-benefits and potential risks.

 > We need something in place to ensure this doesn't happen!

Do you see a simple way to prevent it? Usually people familiar with the 
fix/issue contact me to let me know if they need an extra PIT restart or 
if they need the PIT to be delayed - I can always move deadline for a 
few hours, even a day if needed - just let me know.

Thank you,
Lana



On 04/16/2015 08:07 PM, David Holmes wrote:
> It has happened again that a broken fix, for which there was a quick 
> follow up fix, has been pushed to the master without the follow up fix 
> going with it. So now everyone will potentially be impacted by the bad 
> fix as it propagates back down to all the forests :(
>
> Bad fix:
>
> https://bugs.openjdk.java.net/browse/JDK-8073634
>
> Follow up:
>
> https://bugs.openjdk.java.net/browse/JDK-8077563
>
> We need something in place to ensure this doesn't happen!
>
> David



From david.holmes at oracle.com  Fri Apr 17 05:41:06 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 Apr 2015 15:41:06 +1000
Subject: How to keep follow up fixes with the original ?
In-Reply-To: <55308BE7.9020908@oracle.com>
References: <553078E0.4030804@oracle.com> <55308BE7.9020908@oracle.com>
Message-ID: <55309CF2.1080801@oracle.com>

Hi Lana,

On 17/04/2015 2:28 PM, Lana Steuck wrote:
> Hi David,
>
>  > We need something in place to ensure this doesn't happen!
>
> We push to Master after team forests successfully go through the
> following PIT steps:
> - full build (hotspot ... install) for all 7 platforms
> - fastdebug builds for all 7 platforms
> - boot_cycle builds
> - extended set of JPRT tests (the failures are getting OK-ed by dev)
> - SQE teams are informed and list of fixes are submitted to SQE db
> - manual testing of client-libs on main platforms.
>
> The PIT process can be beefed up to cover more scenarios, however
> there's always a cost that comes with it. At the end, it's a balance of
> cost-benefits and potential risks.

The problem, in both cases (hence the 'again') affected builds where 
configure was not run from directly inside the source tree. I thought 
that between developers builds, JPRT builds, RE builds and PIT builds, 
we had the two basic cases covered, but somehow these slipped through.
But that's not my main concern - mistakes happen.

>  > We need something in place to ensure this doesn't happen!
>
> Do you see a simple way to prevent it? Usually people familiar with the
> fix/issue contact me to let me know if they need an extra PIT restart or
> if they need the PIT to be delayed - I can always move deadline for a
> few hours, even a day if needed - just let me know.

I don't see a simple way. :) Somehow we need to associate two 
changesets/bugs such that they are guaranteed/required to be pushed 
around together. I don't think we have any automated capabilities for 
that - though I can imagine some kind of JBS relationship that jcheck 
would look for. Maybe the manual process of contacting you needs to be 
formalized a bit (not everyone knows what a wonderful job you do ;-) ) 
such that an email can be sent to a well-known address to report the 
problem. But of course that doesn't help if you don't realize there is a 
need to do this - which comes down to education I guess: hence this 
email. :)

Aside: anti-deltas wouldn't help in this case either, but the ability to 
really rollback changesets would. :)

I should also note that the scope of this particular problem is smaller 
than I had thought, because I thought JPRT builds would be affected - 
but they aren't. So its only some of us poor end developers who may get 
bitten.

Thanks,
David

> Thank you,
> Lana
>
>
>
> On 04/16/2015 08:07 PM, David Holmes wrote:
>> It has happened again that a broken fix, for which there was a quick
>> follow up fix, has been pushed to the master without the follow up fix
>> going with it. So now everyone will potentially be impacted by the bad
>> fix as it propagates back down to all the forests :(
>>
>> Bad fix:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8073634
>>
>> Follow up:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8077563
>>
>> We need something in place to ensure this doesn't happen!
>>
>> David
>


From magnus.ihse.bursie at oracle.com  Fri Apr 17 08:12:09 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 17 Apr 2015 10:12:09 +0200
Subject: How to keep follow up fixes with the original ?
In-Reply-To: <55309CF2.1080801@oracle.com>
References: <553078E0.4030804@oracle.com> <55308BE7.9020908@oracle.com>
	<55309CF2.1080801@oracle.com>
Message-ID: <5530C059.3020705@oracle.com>

On 2015-04-17 07:41, David Holmes wrote:
> though I can imagine some kind of JBS relationship that jcheck would 
> look for.

As a start, just having a special JBS relationship for the developers to 
watch out for, even if jcheck cannot do it, might be a good idea? So 
instead of just a "relates to", there should be a "BROKEN, fixed by" 
link, at the original, bad fix, pointing to the follow-up. Hopefully it 
will register with the eyeballs of the engineer doing the backport.

/Magnus


From vadim.pakhnushev at oracle.com  Fri Apr 17 09:15:23 2015
From: vadim.pakhnushev at oracle.com (Vadim Pakhnushev)
Date: Fri, 17 Apr 2015 12:15:23 +0300
Subject: Mac OS X build errors missing instancetype + further issues just
	after building jdk.xml.ws
In-Reply-To: <04B950C5-B2FA-47EC-A008-B6184E350A19@oracle.com>
References: <CAP7YuARGAsc=5bEGC8_M6u1nKaCg_o2r+6=RRO=6LMjOySSWhA@mail.gmail.com>	<99F135A1-F9EB-47E6-881D-3B2AFD0AAAEC@oracle.com>	<CAP7YuAQBddqubx4pOXv4jCg-c8kObe6fgTyBt-apB1D1_bzAZw@mail.gmail.com>
	<04B950C5-B2FA-47EC-A008-B6184E350A19@oracle.com>
Message-ID: <5530CF2B.9050804@oracle.com>

David,

Not really with the latest clang, there is this bug 
https://bugs.openjdk.java.net/browse/JDK-8077364, which is only in 
hotspot repo yet.
With this fix this should work though (at least works for me).

Thanks,
Vadim

On 16.04.2015 23:18, David DeHaven wrote:
> Sorry, I've had my blinders on for a few weeks. What's the original goal here? Are you just trying to build OpenJDK 9 on Mac OS X? If you're using clang in Xcode then it should "just work".
>
> -DrD-
>
>> On Apr 16, 2015, at 6:35 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
>>
>> Hi David,
>>
>> Thanks for your response!  I was using GCC as I had a host of other errors when using clang :-|.  I'll post those in a separate mail for comparison.
>>
>> Cheers,
>> Martijn
>>
>> On 15 April 2015 at 18:22, David DeHaven <david.dehaven at oracle.com> wrote:
>>
>>> Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8
>>>
>>> --------
>>>
>>> After getting past the defined(__OPENBSD__) bug I'm running into a host of
>>> new errors starting with:
>>>
>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
>>> error: unknown type name 'instancetype'
>>> - (instancetype)self;
>>> ^
>> You're using an SDK that's intended to be used exclusively with clang. I think you'd have to go back to MacOSX10.8.sdk for compatibility with gcc.
>>
>> I'm curious why you're even trying to compile with gcc?
>>
>> -DrD-
>>
>>



From magnus.ihse.bursie at oracle.com  Fri Apr 17 09:18:02 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 17 Apr 2015 11:18:02 +0200
Subject: RFR: JDK-8078046 Remove MCS post-processing on Solaris
Message-ID: <5530CFCA.1060100@oracle.com>

We should remove the MCS post-processing on Solaris.

The msc command is used to post-process the binaries on Solaris, with 
the intent of adding the version number. Post-processing of binaries is 
a step that we'd like to avoid, if possible.

It now turns out that the MCS processing has been broken since at least 
JDK8, and nobody has noticed. I recommend we just remove it.

Bug: https://bugs.openjdk.java.net/browse/JDK-8078046
WebRev: http://cr.openjdk.java.net/~ihse/JDK-8078046-remove-MCS/webrev.01

/Magnus


From martijnverburg at gmail.com  Fri Apr 17 09:41:29 2015
From: martijnverburg at gmail.com (Martijn Verburg)
Date: Fri, 17 Apr 2015 11:41:29 +0200
Subject: Mac OS X build errors missing instancetype + further issues just
	after building jdk.xml.ws
In-Reply-To: <04B950C5-B2FA-47EC-A008-B6184E350A19@oracle.com>
References: <CAP7YuARGAsc=5bEGC8_M6u1nKaCg_o2r+6=RRO=6LMjOySSWhA@mail.gmail.com>
	<99F135A1-F9EB-47E6-881D-3B2AFD0AAAEC@oracle.com>
	<CAP7YuAQBddqubx4pOXv4jCg-c8kObe6fgTyBt-apB1D1_bzAZw@mail.gmail.com>
	<04B950C5-B2FA-47EC-A008-B6184E350A19@oracle.com>
Message-ID: <CAP7YuARZ622x6C6Mjm_Y-a92WndYFB7pDJoHxVz6e_7TU3wbrA@mail.gmail.com>

Hi David,

Yes that is/was the original goal :-).  I note Vadim's later post about the
latest Clang support patch needing to land in jdk9, I'll wait until that
happens and post a followup.

Cheers,
Martijn

On 16 April 2015 at 22:18, David DeHaven <david.dehaven at oracle.com> wrote:

> Sorry, I've had my blinders on for a few weeks. What's the original goal
> here? Are you just trying to build OpenJDK 9 on Mac OS X? If you're using
> clang in Xcode then it should "just work".
>
> -DrD-
>
> > On Apr 16, 2015, at 6:35 AM, Martijn Verburg <martijnverburg at gmail.com>
> wrote:
> >
> > Hi David,
> >
> > Thanks for your response!  I was using GCC as I had a host of other
> errors when using clang :-|.  I'll post those in a separate mail for
> comparison.
> >
> > Cheers,
> > Martijn
> >
> > On 15 April 2015 at 18:22, David DeHaven <david.dehaven at oracle.com>
> wrote:
> >
> > > Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8
> > >
> > > --------
> > >
> > > After getting past the defined(__OPENBSD__) bug I'm running into a
> host of
> > > new errors starting with:
> > >
> > >
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
> > >
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
> > > error: unknown type name 'instancetype'
> > > - (instancetype)self;
> > > ^
> >
> > You're using an SDK that's intended to be used exclusively with clang. I
> think you'd have to go back to MacOSX10.8.sdk for compatibility with gcc.
> >
> > I'm curious why you're even trying to compile with gcc?
> >
> > -DrD-
> >
> >
>
>


From david.holmes at oracle.com  Fri Apr 17 10:18:25 2015
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 Apr 2015 20:18:25 +1000
Subject: RFR: JDK-8078046 Remove MCS post-processing on Solaris
In-Reply-To: <5530CFCA.1060100@oracle.com>
References: <5530CFCA.1060100@oracle.com>
Message-ID: <5530DDF1.4040803@oracle.com>

Hi Magnus,

On 17/04/2015 7:18 PM, Magnus Ihse Bursie wrote:
> We should remove the MCS post-processing on Solaris.
>
> The msc command is used to post-process the binaries on Solaris, with
> the intent of adding the version number. Post-processing of binaries is
> a step that we'd like to avoid, if possible.
>
> It now turns out that the MCS processing has been broken since at least
> JDK8, and nobody has noticed. I recommend we just remove it.

In what way was it broken?

What role was it serving?

Who was the consumer of the added information?

Are the people who can answer those questions likely to be watching 
build-dev? ;-)

Happy to see code removed and the build simplified, but only after 
ensuring we understand the impact.

Thanks,
David

> Bug: https://bugs.openjdk.java.net/browse/JDK-8078046
> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8078046-remove-MCS/webrev.01
>
> /Magnus


From magnus.ihse.bursie at oracle.com  Fri Apr 17 10:33:22 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 17 Apr 2015 12:33:22 +0200
Subject: RFR: JDK-8078046 Remove MCS post-processing on Solaris
In-Reply-To: <5530DDF1.4040803@oracle.com>
References: <5530CFCA.1060100@oracle.com> <5530DDF1.4040803@oracle.com>
Message-ID: <5530E172.8090703@oracle.com>

On 2015-04-17 12:18, David Holmes wrote:
> Hi Magnus,
>
> On 17/04/2015 7:18 PM, Magnus Ihse Bursie wrote:
>> We should remove the MCS post-processing on Solaris.
>>
>> The msc command is used to post-process the binaries on Solaris, with
>> the intent of adding the version number. Post-processing of binaries is
>> a step that we'd like to avoid, if possible.
>>
>> It now turns out that the MCS processing has been broken since at least
>> JDK8, and nobody has noticed. I recommend we just remove it.
>
> In what way was it broken?

It was intended to add the version string to the comment field. However, 
sometime early during development of the original build-infra, the code 
was moved so that the variable containing the version string was put in 
spec.gmk, which made it evaluate to empty when POST_MCS_CMD was defined 
in the configure script. So it sets the comment field to "JDK " instead 
of e.g. "JDK 1.8.0".

>
> What role was it serving?

Putting the version string in the comment field of Solaris binaries. I'm 
not sure what purpose that in turn would serve. Checking some random 
Solaris binaries doesn't show any consistency in how/when this field is 
set to anything meaningful, neither can I dig up any serious use cases 
on Google.

>
> Who was the consumer of the added information?
?? Nobody that have discovered that it has been missing since JDK8 and 
complained, at least.
>
> Are the people who can answer those questions likely to be watching 
> build-dev? ;-)

SInce my guesstimate is that this set of people is ~= ?, the answer 
would probably be yes. ;-) (But that depends on your set logic 
interpretation of member-of and empty-set :-)).

> Happy to see code removed and the build simplified, but only after 
> ensuring we understand the impact.

I have no clue how to further locate anyone who can describe the impact, 
apart from the apparent lack of anyone complaining for all this time. If 
you have any suggestions, please forward this review to them.

The reason I noticed this at all was due to the work for the new version 
string, JEP-223. So the alternative to removing this is to "fix" it and 
introduce a version string that has not been there for all of JDK8, and 
which is soon likely to change radically in format anyway.

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Apr 17 12:20:06 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 17 Apr 2015 14:20:06 +0200
Subject: RFR: JDK-8078058 Clean up mac bundles logic
Message-ID: <5530FA76.9020302@oracle.com>

The MacBundles logic needs some love.

1) The names defined in spec.gmk.in just says "bundle" but this is a 
somewhat overloaded term, shared e.g. by jprt. This should be renamed to 
macosx_bundle.

2) We should use the modern SetupTextFileProcessing to process the plist 
template files.

3) We should just clean up the open/non-open mess wrt names and version 
strings.

I chose to keep the non-open versions, for several reasons. It's 
probably more likely that anyone is dependent on the more widely 
distributed Oracle JDK, so changing that would likely be more 
disruptive. And secondly, in one case the non-open version was more 
informative, which is likely to be a good thing. (In the other case, it 
was just a difference of using paranthesis  or not.)

Bug: https://bugs.openjdk.java.net/browse/JDK-8078058
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8078058-cleanup-macosx-bundles/webrev.01

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Apr 17 12:52:23 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 17 Apr 2015 14:52:23 +0200
Subject: RFR: JDK-8074859 Turn on warnings as error
Message-ID: <55310207.9050207@oracle.com>

With JDK-8074096, the number of warnings in the product was reduced to a 
minimum. This enables the next step, which is turning on the respective 
compiler flags that turns warnings into errors. In the long run, this is 
the only way to keep the warnings from creeping back.

Even with JDK-8074096, the product does not build 100% warning free. 
This is due to some warnings that cannot be disabled, or (in one case) 
where C and C++ code is mixed, and warnings for both languages cannot be 
used. A system similar to the one introduced in JDK-8074096 is therefore 
needed, in which individual libraries can be exempted from this flag, 
until such warnings are fixed. A library can thus disable warnings as 
errors with WARNINGS_AS_ERRORS := false, or (better) use a 
toolchain-specific version, e.g WARNINGS_AS_ERRORS_gcc := false. This is 
intended as a temporary measure, though. The long-term solution is 
reasonably to fix the warnings and remove that argument.

Also, different versions of compilers can generate a different set of 
warnings. It is therefore necessary to be able to turn off this 
globally. Therefor a new flag for configure is introduced: 
--disable-warnings-as-errors.

While the code compiles without errors on the build systems used 
internally at Oracle, this might not be the case on other combinations 
of operating system versions and toolchain versions. To facilitate for 
unexpecting developers, a help message is added if the build fails, that 
suggests using --disable-warnings-as-errors. This solution was chosen as 
a compromise between the "hard core" solution of turning on warnings as 
errors by default for anyone, and the cowar... erm, conservative 
solution of checking if the compiler versions exactly match what's used 
inside Oracle (and therefore regularly tested), and only turn it on in 
that case.

Similarly to JDK-8074096, I intend to file follow-up bugs for each 
individual library that got a WARNINGS_AS_ERRORS_* := false.

Bug: https://bugs.openjdk.java.net/browse/JDK-8074859
WebRev for top: 
http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01
WebRev for jdk: 
http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01

Some comments:

* I needed to add a few more DISABLED_WARNINGS. For windows, this is 
most likely due to the recent compiler change. For other libraries, I'm 
not sure, but it might well be the result of recent changes that has 
introduced new warnings. If so, it highlights the need of this patch to 
keep the build warning free.

* For a few libraries and toolchains, there is *both* WARNINGS_AS_ERRORS 
:= false and a DISABLED_WARNINGS list. This is the case if not all 
warnings are possible to disable.

* I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This is 
included in our JDK LDFLAGS, so it should not be set separately, and 
definitely not as CFLAGS. (This caused compiler warnings, which now 
turned into errors.) However, a more suitable long-term solution is 
probably to move the knowledge of how to create shared libraries more 
specifically into SetupNativeCompilation, and not set it as part of the 
JDK flags.

/Magnus


From magnus.ihse.bursie at oracle.com  Fri Apr 17 13:09:17 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 17 Apr 2015 15:09:17 +0200
Subject: RFR: JDK-8077992 Eliminate JDK build dependency of native2ascii and
	update Japanese nroff man pages to UTF-8 encoding
Message-ID: <553105FD.4050906@oracle.com>

 From bug report: "Proposal has been made to remove "native2ascii" tool 
from JDK9.

It was identified that JDK9 uses "native2ascii" itself to convert 
Japanese nroff man pages to various encodings (Linux: UTF-8, Solaris: 
UTF-8, PCK/SJIS) from eucJP source. [...] Since the supported Solaris 
and Linux OS releases now support UTF-8 locales by default, we should 
just deliver UTF-8 encoded nroff man pages and eliminate the conversion 
process. "

Michael Fang has supplied a patch that converts the man pages to UTF8. 
My fix here will need that patch applied to the jdk repo to work. I'll 
not supply it in the webrev though, it's large and hardly readable. It 
is attached to the bug report.

Note that the removal of the sed expression is safe since the VERSION 
tag is long gone.

Bug: https://bugs.openjdk.java.net/browse/JDK-8077992
WebRev: 
http://cr.openjdk.java.net/~ihse/JDK-8077992-remove-native2ascii-from-build/webrev.01

Signed,
Magnus, Head Director of Good Riddance Dept.


From mandy.chung at oracle.com  Fri Apr 17 13:52:37 2015
From: mandy.chung at oracle.com (Mandy Chung)
Date: Fri, 17 Apr 2015 06:52:37 -0700
Subject: RFR: JDK-8077992 Eliminate JDK build dependency of native2ascii
	and update Japanese nroff man pages to UTF-8 encoding
In-Reply-To: <553105FD.4050906@oracle.com>
References: <553105FD.4050906@oracle.com>
Message-ID: <55311025.1010802@oracle.com>

On 4/17/2015 6:09 AM, Magnus Ihse Bursie wrote:
> From bug report: "Proposal has been made to remove "native2ascii" tool 
> from JDK9.
>
> It was identified that JDK9 uses "native2ascii" itself to convert 
> Japanese nroff man pages to various encodings (Linux: UTF-8, Solaris: 
> UTF-8, PCK/SJIS) from eucJP source. [...] Since the supported Solaris 
> and Linux OS releases now support UTF-8 locales by default, we should 
> just deliver UTF-8 encoded nroff man pages and eliminate the 
> conversion process. "
>
> Michael Fang has supplied a patch that converts the man pages to UTF8. 
> My fix here will need that patch applied to the jdk repo to work. I'll 
> not supply it in the webrev though, it's large and hardly readable. It 
> is attached to the bug report.
>
> Note that the removal of the sed expression is safe since the VERSION 
> tag is long gone.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8077992
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8077992-remove-native2ascii-from-build/webrev.01
>

The build change looks good to me.   Thanks for doing this.

Mandy


From michael.fang at oracle.com  Fri Apr 17 17:25:13 2015
From: michael.fang at oracle.com (Michael Fang)
Date: Fri, 17 Apr 2015 10:25:13 -0700
Subject: RFR: JDK-8077992 Eliminate JDK build dependency of native2ascii
	and update Japanese nroff man pages to UTF-8 encoding
In-Reply-To: <55311025.1010802@oracle.com>
References: <553105FD.4050906@oracle.com> <55311025.1010802@oracle.com>
Message-ID: <553141F9.1090201@oracle.com>

Thanks Magnus and Mandy for taking care of build changes.

-michael

On 2015?04?17? 06:52, Mandy Chung wrote:
> On 4/17/2015 6:09 AM, Magnus Ihse Bursie wrote:
>> From bug report: "Proposal has been made to remove "native2ascii" 
>> tool from JDK9.
>>
>> It was identified that JDK9 uses "native2ascii" itself to convert 
>> Japanese nroff man pages to various encodings (Linux: UTF-8, Solaris: 
>> UTF-8, PCK/SJIS) from eucJP source. [...] Since the supported Solaris 
>> and Linux OS releases now support UTF-8 locales by default, we should 
>> just deliver UTF-8 encoded nroff man pages and eliminate the 
>> conversion process. "
>>
>> Michael Fang has supplied a patch that converts the man pages to 
>> UTF8. My fix here will need that patch applied to the jdk repo to 
>> work. I'll not supply it in the webrev though, it's large and hardly 
>> readable. It is attached to the bug report.
>>
>> Note that the removal of the sed expression is safe since the VERSION 
>> tag is long gone.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8077992
>> WebRev: 
>> http://cr.openjdk.java.net/~ihse/JDK-8077992-remove-native2ascii-from-build/webrev.01
>>
>
> The build change looks good to me.   Thanks for doing this.
>
> Mandy


From james.laskey at oracle.com  Fri Apr 17 20:07:12 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 17 Apr 2015 17:07:12 -0300
Subject: Jake, hashes and aliases
Message-ID: <A2AEF05A-83AE-42AA-9966-DD710459D9AD@oracle.com>

java.lang.module.ResolveException: Hash of java.security.jgss (IPAH/Z1wbzCE8aG78apqik6QR94TaBJqcatAkW+35rs=) differs to expected hash (O61Gv4243oRyV7LoD/FjaNBXgRtREFjG4p1Q//V8cGI=)
	at java.lang.module.Resolver.fail(java.base at 9.0/Resolver.java:416)
	at java.lang.module.Resolver.checkHashes(java.base at 9.0/Resolver.java:407)
	at java.lang.module.Resolver.resolve(java.base at 9.0/Resolver.java:135)
	at java.lang.module.Configuration.resolve(java.base at 9.0/Configuration.java:80)
	at jdk.jigsaw.tools.jlink.JlinkTask.createImage(jdk.jlink at 9.0/JlinkTask.java:294)
	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:232)
	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:215)
	at jdk.jigsaw.tools.jlink.Main.main(jdk.jlink at 9.0/Main.java:33)
make[3]: *** [/Projects/jake/build/macosx-x86_64-normal-server-fastdebug/images/jdk-server/bin/java] Error 4
make[3]: *** Waiting for unfinished jobs....
java.lang.module.ResolveException: Hash of java.security.sasl (RYmhSNVe20U0aKdkVmf4uTxhPRSdUbJu/q8UxQmGLX8=) differs to expected hash (OCim25Rq6hJk4uJiHwkeT7snnHemh3co4JmweYOfxGc=)
	at java.lang.module.Resolver.fail(java.base at 9.0/Resolver.java:416)
	at java.lang.module.Resolver.checkHashes(java.base at 9.0/Resolver.java:407)
	at java.lang.module.Resolver.resolve(java.base at 9.0/Resolver.java:135)
	at java.lang.module.Configuration.resolve(java.base at 9.0/Configuration.java:80)
	at jdk.jigsaw.tools.jlink.JlinkTask.createImage(jdk.jlink at 9.0/JlinkTask.java:294)
	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:232)
	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:215)
	at jdk.jigsaw.tools.jlink.Main.main(jdk.jlink at 9.0/Main.java:33)
java.lang.module.ResolveException: Hash of java.security.sasl (RYmhSNVe20U0aKdkVmf4uTxhPRSdUbJu/q8UxQmGLX8=) differs to expected hash (OCim25Rq6hJk4uJiHwkeT7snnHemh3co4JmweYOfxGc=)
	at java.lang.module.Resolver.fail(java.base at 9.0/Resolver.java:416)
	at java.lang.module.Resolver.checkHashes(java.base at 9.0/Resolver.java:407)
	at java.lang.module.Resolver.resolve(java.base at 9.0/Resolver.java:135)
	at java.lang.module.Configuration.resolve(java.base at 9.0/Configuration.java:80)
	at jdk.jigsaw.tools.jlink.JlinkTask.createImage(jdk.jlink at 9.0/JlinkTask.java:294)
	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:232)
	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:215)
	at jdk.jigsaw.tools.jlink.Main.main(jdk.jlink at 9.0/Main.java:33)


Is there any way we can not use the full canonical path for hash generation.  I generally operate off a soft link for my projects and this obviously bungs up hash generation. I have to add PWD=`pwd -p` to make configure work correctly.

? Jim




From james.laskey at oracle.com  Fri Apr 17 20:13:32 2015
From: james.laskey at oracle.com (Jim Laskey (Oracle))
Date: Fri, 17 Apr 2015 17:13:32 -0300
Subject: Jake, hashes and aliases
In-Reply-To: <A2AEF05A-83AE-42AA-9966-DD710459D9AD@oracle.com>
References: <A2AEF05A-83AE-42AA-9966-DD710459D9AD@oracle.com>
Message-ID: <E6DBC7B4-8E73-47FF-A277-8EA2117867FF@oracle.com>

I was wrong - that didn?t resolve my issue.


> On Apr 17, 2015, at 5:07 PM, Jim Laskey (Oracle) <james.laskey at oracle.com> wrote:
> 
> java.lang.module.ResolveException: Hash of java.security.jgss (IPAH/Z1wbzCE8aG78apqik6QR94TaBJqcatAkW+35rs=) differs to expected hash (O61Gv4243oRyV7LoD/FjaNBXgRtREFjG4p1Q//V8cGI=)
> 	at java.lang.module.Resolver.fail(java.base at 9.0/Resolver.java:416)
> 	at java.lang.module.Resolver.checkHashes(java.base at 9.0/Resolver.java:407)
> 	at java.lang.module.Resolver.resolve(java.base at 9.0/Resolver.java:135)
> 	at java.lang.module.Configuration.resolve(java.base at 9.0/Configuration.java:80)
> 	at jdk.jigsaw.tools.jlink.JlinkTask.createImage(jdk.jlink at 9.0/JlinkTask.java:294)
> 	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:232)
> 	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:215)
> 	at jdk.jigsaw.tools.jlink.Main.main(jdk.jlink at 9.0/Main.java:33)
> make[3]: *** [/Projects/jake/build/macosx-x86_64-normal-server-fastdebug/images/jdk-server/bin/java] Error 4
> make[3]: *** Waiting for unfinished jobs....
> java.lang.module.ResolveException: Hash of java.security.sasl (RYmhSNVe20U0aKdkVmf4uTxhPRSdUbJu/q8UxQmGLX8=) differs to expected hash (OCim25Rq6hJk4uJiHwkeT7snnHemh3co4JmweYOfxGc=)
> 	at java.lang.module.Resolver.fail(java.base at 9.0/Resolver.java:416)
> 	at java.lang.module.Resolver.checkHashes(java.base at 9.0/Resolver.java:407)
> 	at java.lang.module.Resolver.resolve(java.base at 9.0/Resolver.java:135)
> 	at java.lang.module.Configuration.resolve(java.base at 9.0/Configuration.java:80)
> 	at jdk.jigsaw.tools.jlink.JlinkTask.createImage(jdk.jlink at 9.0/JlinkTask.java:294)
> 	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:232)
> 	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:215)
> 	at jdk.jigsaw.tools.jlink.Main.main(jdk.jlink at 9.0/Main.java:33)
> java.lang.module.ResolveException: Hash of java.security.sasl (RYmhSNVe20U0aKdkVmf4uTxhPRSdUbJu/q8UxQmGLX8=) differs to expected hash (OCim25Rq6hJk4uJiHwkeT7snnHemh3co4JmweYOfxGc=)
> 	at java.lang.module.Resolver.fail(java.base at 9.0/Resolver.java:416)
> 	at java.lang.module.Resolver.checkHashes(java.base at 9.0/Resolver.java:407)
> 	at java.lang.module.Resolver.resolve(java.base at 9.0/Resolver.java:135)
> 	at java.lang.module.Configuration.resolve(java.base at 9.0/Configuration.java:80)
> 	at jdk.jigsaw.tools.jlink.JlinkTask.createImage(jdk.jlink at 9.0/JlinkTask.java:294)
> 	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:232)
> 	at jdk.jigsaw.tools.jlink.JlinkTask.run(jdk.jlink at 9.0/JlinkTask.java:215)
> 	at jdk.jigsaw.tools.jlink.Main.main(jdk.jlink at 9.0/Main.java:33)
> 
> 
> Is there any way we can not use the full canonical path for hash generation.  I generally operate off a soft link for my projects and this obviously bungs up hash generation. I have to add PWD=`pwd -p` to make configure work correctly.
> 
> ? Jim
> 
> 



From erik.joelsson at oracle.com  Mon Apr 20 06:57:30 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 20 Apr 2015 08:57:30 +0200
Subject: RFR: JDK-8078058 Clean up mac bundles logic
In-Reply-To: <5530FA76.9020302@oracle.com>
References: <5530FA76.9020302@oracle.com>
Message-ID: <5534A35A.60501@oracle.com>

Looks good to me.

/Erik

On 2015-04-17 14:20, Magnus Ihse Bursie wrote:
> The MacBundles logic needs some love.
>
> 1) The names defined in spec.gmk.in just says "bundle" but this is a 
> somewhat overloaded term, shared e.g. by jprt. This should be renamed 
> to macosx_bundle.
>
> 2) We should use the modern SetupTextFileProcessing to process the 
> plist template files.
>
> 3) We should just clean up the open/non-open mess wrt names and 
> version strings.
>
> I chose to keep the non-open versions, for several reasons. It's 
> probably more likely that anyone is dependent on the more widely 
> distributed Oracle JDK, so changing that would likely be more 
> disruptive. And secondly, in one case the non-open version was more 
> informative, which is likely to be a good thing. (In the other case, 
> it was just a difference of using paranthesis  or not.)
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8078058
> WebRev: 
> http://cr.openjdk.java.net/~ihse/JDK-8078058-cleanup-macosx-bundles/webrev.01
>
> /Magnus



From erik.joelsson at oracle.com  Mon Apr 20 07:02:13 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 20 Apr 2015 09:02:13 +0200
Subject: RFR: JDK-8074859 Turn on warnings as error
In-Reply-To: <55310207.9050207@oracle.com>
References: <55310207.9050207@oracle.com>
Message-ID: <5534A475.2090909@oracle.com>

Looks good to me.

/Erik

On 2015-04-17 14:52, Magnus Ihse Bursie wrote:
> With JDK-8074096, the number of warnings in the product was reduced to 
> a minimum. This enables the next step, which is turning on the 
> respective compiler flags that turns warnings into errors. In the long 
> run, this is the only way to keep the warnings from creeping back.
>
> Even with JDK-8074096, the product does not build 100% warning free. 
> This is due to some warnings that cannot be disabled, or (in one case) 
> where C and C++ code is mixed, and warnings for both languages cannot 
> be used. A system similar to the one introduced in JDK-8074096 is 
> therefore needed, in which individual libraries can be exempted from 
> this flag, until such warnings are fixed. A library can thus disable 
> warnings as errors with WARNINGS_AS_ERRORS := false, or (better) use a 
> toolchain-specific version, e.g WARNINGS_AS_ERRORS_gcc := false. This 
> is intended as a temporary measure, though. The long-term solution is 
> reasonably to fix the warnings and remove that argument.
>
> Also, different versions of compilers can generate a different set of 
> warnings. It is therefore necessary to be able to turn off this 
> globally. Therefor a new flag for configure is introduced: 
> --disable-warnings-as-errors.
>
> While the code compiles without errors on the build systems used 
> internally at Oracle, this might not be the case on other combinations 
> of operating system versions and toolchain versions. To facilitate for 
> unexpecting developers, a help message is added if the build fails, 
> that suggests using --disable-warnings-as-errors. This solution was 
> chosen as a compromise between the "hard core" solution of turning on 
> warnings as errors by default for anyone, and the cowar... erm, 
> conservative solution of checking if the compiler versions exactly 
> match what's used inside Oracle (and therefore regularly tested), and 
> only turn it on in that case.
>
> Similarly to JDK-8074096, I intend to file follow-up bugs for each 
> individual library that got a WARNINGS_AS_ERRORS_* := false.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074859
> WebRev for top: 
> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-top/webrev.01
> WebRev for jdk: 
> http://cr.openjdk.java.net/~ihse/JDK-8074859-warnings-as-errors-jdk/webrev.01
>
> Some comments:
>
> * I needed to add a few more DISABLED_WARNINGS. For windows, this is 
> most likely due to the recent compiler change. For other libraries, 
> I'm not sure, but it might well be the result of recent changes that 
> has introduced new warnings. If so, it highlights the need of this 
> patch to keep the build warning free.
>
> * For a few libraries and toolchains, there is *both* 
> WARNINGS_AS_ERRORS := false and a DISABLED_WARNINGS list. This is the 
> case if not all warnings are possible to disable.
>
> * I have removed some incorrect uses of SHARED_LIBRARY_FLAGS. This is 
> included in our JDK LDFLAGS, so it should not be set separately, and 
> definitely not as CFLAGS. (This caused compiler warnings, which now 
> turned into errors.) However, a more suitable long-term solution is 
> probably to move the knowledge of how to create shared libraries more 
> specifically into SetupNativeCompilation, and not set it as part of 
> the JDK flags.
>
> /Magnus



From david.dehaven at oracle.com  Mon Apr 20 15:04:36 2015
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 20 Apr 2015 08:04:36 -0700
Subject: Mac OS X build errors missing instancetype + further issues just
	after building jdk.xml.ws
In-Reply-To: <5530CF2B.9050804@oracle.com>
References: <CAP7YuARGAsc=5bEGC8_M6u1nKaCg_o2r+6=RRO=6LMjOySSWhA@mail.gmail.com>
	<99F135A1-F9EB-47E6-881D-3B2AFD0AAAEC@oracle.com>
	<CAP7YuAQBddqubx4pOXv4jCg-c8kObe6fgTyBt-apB1D1_bzAZw@mail.gmail.com>
	<04B950C5-B2FA-47EC-A008-B6184E350A19@oracle.com>
	<5530CF2B.9050804@oracle.com>
Message-ID: <AEBDED8A-C001-4DB1-9642-E75CFD26EAC9@oracle.com>

Ah, ok. I haven't updated to 6.3 yet so I haven't seen the issue.

-DrD-

> David,
> 
> Not really with the latest clang, there is this bug https://bugs.openjdk.java.net/browse/JDK-8077364, which is only in hotspot repo yet.
> With this fix this should work though (at least works for me).
> 
> Thanks,
> Vadim
> 
> On 16.04.2015 23:18, David DeHaven wrote:
>> Sorry, I've had my blinders on for a few weeks. What's the original goal here? Are you just trying to build OpenJDK 9 on Mac OS X? If you're using clang in Xcode then it should "just work".
>> 
>> -DrD-
>> 
>>> On Apr 16, 2015, at 6:35 AM, Martijn Verburg <martijnverburg at gmail.com> wrote:
>>> 
>>> Hi David,
>>> 
>>> Thanks for your response!  I was using GCC as I had a host of other errors when using clang :-|.  I'll post those in a separate mail for comparison.
>>> 
>>> Cheers,
>>> Martijn
>>> 
>>> On 15 April 2015 at 18:22, David DeHaven <david.dehaven at oracle.com> wrote:
>>> 
>>>> Mac OS X 10.10.3, latest Xcode (6.3), using GCC 4.8
>>>> 
>>>> --------
>>>> 
>>>> After getting past the defined(__OPENBSD__) bug I'm running into a host of
>>>> new errors starting with:
>>>> 
>>>> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26:
>>>> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.10.sdk/usr/include/objc/NSObject.h:22:1:
>>>> error: unknown type name 'instancetype'
>>>> - (instancetype)self;
>>>> ^
>>> You're using an SDK that's intended to be used exclusively with clang. I think you'd have to go back to MacOSX10.8.sdk for compatibility with gcc.
>>> 
>>> I'm curious why you're even trying to compile with gcc?
>>> 
>>> -DrD-
>>> 
>>> 
> 



From peter.brunet at oracle.com  Tue Apr 21 18:53:51 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 21 Apr 2015 13:53:51 -0500
Subject: 9 b58 fails on Win 8 when screen reader running
Message-ID: <55369CBF.3010404@oracle.com>

Starting with b58 with JAWS (screen reader) running on Win 8, when
starting SwingSet2 the splash screen appears but the application doesn't
start.  There are no messages in the console.  I see b58 only had one fix:

8076531 infrastructure Switch default compiler on Windows to VS2013

What might be wrong? 

How do I debug this?

Pete


From philip.race at oracle.com  Tue Apr 21 19:42:28 2015
From: philip.race at oracle.com (Phil Race)
Date: Tue, 21 Apr 2015 12:42:28 -0700
Subject: 9 b58 fails on Win 8 when screen reader running
In-Reply-To: <55369CBF.3010404@oracle.com>
References: <55369CBF.3010404@oracle.com>
Message-ID: <5536A824.3030606@oracle.com>

Perhaps JAWS is not well behaved w.r.t multiple DLL versions ?
Does it happen only on win 8 ? If you boot the same system into win 8 or 
win 8.1 is it OK ?

What do you see logged by hotspot from typing Ctrl-Break in the shell ?
Other than that, debugging is very likely going to require you build 
with VS2013

Does it happen if you use javaw instead of java ?

-phil.

On 04/21/2015 11:53 AM, Pete Brunet wrote:
> Starting with b58 with JAWS (screen reader) running on Win 8, when
> starting SwingSet2 the splash screen appears but the application doesn't
> start.  There are no messages in the console.  I see b58 only had one fix:
>
> 8076531 infrastructure Switch default compiler on Windows to VS2013
>
> What might be wrong?
>
> How do I debug this?
>
> Pete



From peter.brunet at oracle.com  Tue Apr 21 20:19:54 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Tue, 21 Apr 2015 15:19:54 -0500
Subject: 9 b58 fails on Win 8 when screen reader running
In-Reply-To: <5536A824.3030606@oracle.com>
References: <55369CBF.3010404@oracle.com> <5536A824.3030606@oracle.com>
Message-ID: <5536B0EA.80009@oracle.com>

Hi Phil,

On 4/21/15 2:42 PM, Phil Race wrote:
> Perhaps JAWS is not well behaved w.r.t multiple DLL versions ?
Tell me more.
> Does it happen only on win 8 ? If you boot the same system into win 8
> or win 8.1 is it OK ?
Win 7 is no problem.  I run Win 8.1 Pro in a VirtualBox VM.  This bug
was reported as
https://bugs.openjdk.java.net/browse/intjdk-7615864
>
> What do you see logged by hotspot from typing Ctrl-Break in the shell ?
It will be back to the command prompt before I can do that.
> Other than that, debugging is very likely going to require you build
> with VS2013
>
> Does it happen if you use javaw instead of java ?
Same behavior: splash screen, then back to the prompt.
>
> -phil.
>
> On 04/21/2015 11:53 AM, Pete Brunet wrote:
>> Starting with b58 with JAWS (screen reader) running on Win 8, when
>> starting SwingSet2 the splash screen appears but the application doesn't
>> start.  There are no messages in the console.  I see b58 only had one
>> fix:
>>
>> 8076531 infrastructure Switch default compiler on Windows to VS2013
>>
>> What might be wrong?
>>
>> How do I debug this?
>>
>> Pete
>



From david.holmes at oracle.com  Wed Apr 22 09:16:09 2015
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 22 Apr 2015 19:16:09 +1000
Subject: 9 b58 fails on Win 8 when screen reader running
In-Reply-To: <5536B0EA.80009@oracle.com>
References: <55369CBF.3010404@oracle.com> <5536A824.3030606@oracle.com>
	<5536B0EA.80009@oracle.com>
Message-ID: <553766D9.9030104@oracle.com>

Do you get more info if you set _JAVA_LAUNCHER_DEBUG in the environment?

David

On 22/04/2015 6:19 AM, Pete Brunet wrote:
> Hi Phil,
>
> On 4/21/15 2:42 PM, Phil Race wrote:
>> Perhaps JAWS is not well behaved w.r.t multiple DLL versions ?
> Tell me more.
>> Does it happen only on win 8 ? If you boot the same system into win 8
>> or win 8.1 is it OK ?
> Win 7 is no problem.  I run Win 8.1 Pro in a VirtualBox VM.  This bug
> was reported as
> https://bugs.openjdk.java.net/browse/intjdk-7615864
>>
>> What do you see logged by hotspot from typing Ctrl-Break in the shell ?
> It will be back to the command prompt before I can do that.
>> Other than that, debugging is very likely going to require you build
>> with VS2013
>>
>> Does it happen if you use javaw instead of java ?
> Same behavior: splash screen, then back to the prompt.
>>
>> -phil.
>>
>> On 04/21/2015 11:53 AM, Pete Brunet wrote:
>>> Starting with b58 with JAWS (screen reader) running on Win 8, when
>>> starting SwingSet2 the splash screen appears but the application doesn't
>>> start.  There are no messages in the console.  I see b58 only had one
>>> fix:
>>>
>>> 8076531 infrastructure Switch default compiler on Windows to VS2013
>>>
>>> What might be wrong?
>>>
>>> How do I debug this?
>>>
>>> Pete
>>
>


From peter.brunet at oracle.com  Wed Apr 22 21:06:22 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 22 Apr 2015 16:06:22 -0500
Subject: build failure after switching to vs2013
Message-ID: <55380D4E.7080700@oracle.com>

I was able to build 9 OK then I switched from VS2010 to VS2013 and now
get the following.  I tried hg tpull -u but that didn't help. 

Is there something I need to do besides installing VS Pro 2013 with
Update 4?

$ make images 2>&1 | tee make-64.log
Building target 'images' in configuration
'windows-x86_64-normal-server-release'

c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
: error C2220: warning treated as error - no 'object' file generated
c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
: warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated
API warnings
        c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
declaration of 'gethostbyname'
Lib-jdk.hprof.agent.gmk:44: recipe for target
'/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
[/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
Error 2
make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
make[2]: *** [jdk.hprof.agent-libs] Error 1
make[2]: *** Waiting for unfinished jobs....
/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
recipe for target 'main' failed
make[1]: *** [main] Error 1
/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
recipe for target 'images' failed
make: *** [images] Error 2


From peter.brunet at oracle.com  Wed Apr 22 21:12:04 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 22 Apr 2015 16:12:04 -0500
Subject: build failure after switching to vs2013
In-Reply-To: <55380D4E.7080700@oracle.com>
References: <55380D4E.7080700@oracle.com>
Message-ID: <55380EA4.7030901@oracle.com>

p.s. I also had done a make reconfigure and make clean.  I'll try make
clean and reconfigure from bash.

On 4/22/15 4:06 PM, Pete Brunet wrote:
> I was able to build 9 OK then I switched from VS2010 to VS2013 and now
> get the following.  I tried hg tpull -u but that didn't help. 
>
> Is there something I need to do besides installing VS Pro 2013 with
> Update 4?
>
> $ make images 2>&1 | tee make-64.log
> Building target 'images' in configuration
> 'windows-x86_64-normal-server-release'
>
> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
> : error C2220: warning treated as error - no 'object' file generated
> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated
> API warnings
>         c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
> declaration of 'gethostbyname'
> Lib-jdk.hprof.agent.gmk:44: recipe for target
> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
> Error 2
> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
> make[2]: *** [jdk.hprof.agent-libs] Error 1
> make[2]: *** Waiting for unfinished jobs....
> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
> recipe for target 'main' failed
> make[1]: *** [main] Error 1
> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
> recipe for target 'images' failed
> make: *** [images] Error 2



From david.holmes at oracle.com  Wed Apr 22 21:52:10 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Apr 2015 07:52:10 +1000
Subject: build failure after switching to vs2013
In-Reply-To: <55380D4E.7080700@oracle.com>
References: <55380D4E.7080700@oracle.com>
Message-ID: <5538180A.6080608@oracle.com>

On 23/04/2015 7:06 AM, Pete Brunet wrote:
> I was able to build 9 OK then I switched from VS2010 to VS2013 and now
> get the following.  I tried hg tpull -u but that didn't help.
>
> Is there something I need to do besides installing VS Pro 2013 with
> Update 4?

There may be follow-up fixes to address the warnings that are not in 
your forest - which forest are you using?

David

> $ make images 2>&1 | tee make-64.log
> Building target 'images' in configuration
> 'windows-x86_64-normal-server-release'
>
> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
> : error C2220: warning treated as error - no 'object' file generated
> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated
> API warnings
>          c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
> declaration of 'gethostbyname'
> Lib-jdk.hprof.agent.gmk:44: recipe for target
> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
> Error 2
> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
> make[2]: *** [jdk.hprof.agent-libs] Error 1
> make[2]: *** Waiting for unfinished jobs....
> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
> recipe for target 'main' failed
> make[1]: *** [main] Error 1
> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
> recipe for target 'images' failed
> make: *** [images] Error 2
>


From peter.brunet at oracle.com  Wed Apr 22 22:02:05 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 22 Apr 2015 17:02:05 -0500
Subject: build failure after switching to vs2013
In-Reply-To: <55380EA4.7030901@oracle.com>
References: <55380D4E.7080700@oracle.com> <55380EA4.7030901@oracle.com>
Message-ID: <55381A5D.1020900@oracle.com>

This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now:

     LANG := C, \
     OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \
     CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \
+        -D_WINSOCK_DEPRECATED_NO_WARNINGS \
         $(BUILD_LIBHPROF_CFLAGS), \
     CFLAGS_debug := -DHPROF_LOGGING, \
     MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \

Pete

On 4/22/15 4:12 PM, Pete Brunet wrote:
> p.s. I also had done a make reconfigure and make clean.  I'll try make
> clean and reconfigure from bash.
>
> On 4/22/15 4:06 PM, Pete Brunet wrote:
>> I was able to build 9 OK then I switched from VS2010 to VS2013 and now
>> get the following.  I tried hg tpull -u but that didn't help. 
>>
>> Is there something I need to do besides installing VS Pro 2013 with
>> Update 4?
>>
>> $ make images 2>&1 | tee make-64.log
>> Building target 'images' in configuration
>> 'windows-x86_64-normal-server-release'
>>
>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>> : error C2220: warning treated as error - no 'object' file generated
>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated
>> API warnings
>>         c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
>> declaration of 'gethostbyname'
>> Lib-jdk.hprof.agent.gmk:44: recipe for target
>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
>> Error 2
>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
>> make[2]: *** [jdk.hprof.agent-libs] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
>> recipe for target 'main' failed
>> make[1]: *** [main] Error 1
>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
>> recipe for target 'images' failed
>> make: *** [images] Error 2



From peter.brunet at oracle.com  Wed Apr 22 22:03:10 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 22 Apr 2015 17:03:10 -0500
Subject: build failure after switching to vs2013
In-Reply-To: <5538180A.6080608@oracle.com>
References: <55380D4E.7080700@oracle.com> <5538180A.6080608@oracle.com>
Message-ID: <55381A9E.9040303@oracle.com>



On 4/22/15 4:52 PM, David Holmes wrote:
> On 23/04/2015 7:06 AM, Pete Brunet wrote:
>> I was able to build 9 OK then I switched from VS2010 to VS2013 and now
>> get the following.  I tried hg tpull -u but that didn't help.
>>
>> Is there something I need to do besides installing VS Pro 2013 with
>> Update 4?
>
> There may be follow-up fixes to address the warnings that are not in
> your forest - which forest are you using?
client
>
> David
>
>> $ make images 2>&1 | tee make-64.log
>> Building target 'images' in configuration
>> 'windows-x86_64-normal-server-release'
>>
>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>
>> : error C2220: warning treated as error - no 'object' file generated
>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>
>> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated
>> API warnings
>>          c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
>> declaration of 'gethostbyname'
>> Lib-jdk.hprof.agent.gmk:44: recipe for target
>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
>>
>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
>>
>> Error 2
>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
>> make[2]: *** [jdk.hprof.agent-libs] Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
>> recipe for target 'main' failed
>> make[1]: *** [main] Error 1
>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
>> recipe for target 'images' failed
>> make: *** [images] Error 2
>>



From david.holmes at oracle.com  Wed Apr 22 23:48:56 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Apr 2015 09:48:56 +1000
Subject: build failure after switching to vs2013
In-Reply-To: <55381A5D.1020900@oracle.com>
References: <55380D4E.7080700@oracle.com> <55380EA4.7030901@oracle.com>
	<55381A5D.1020900@oracle.com>
Message-ID: <55383368.1070003@oracle.com>

Peter,

See

https://bugs.openjdk.java.net/browse/JDK-8077422

update 4 is not supported yet.

David

On 23/04/2015 8:02 AM, Pete Brunet wrote:
> This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now:
>
>       LANG := C, \
>       OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \
>       CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \
> +        -D_WINSOCK_DEPRECATED_NO_WARNINGS \
>           $(BUILD_LIBHPROF_CFLAGS), \
>       CFLAGS_debug := -DHPROF_LOGGING, \
>       MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \
>
> Pete
>
> On 4/22/15 4:12 PM, Pete Brunet wrote:
>> p.s. I also had done a make reconfigure and make clean.  I'll try make
>> clean and reconfigure from bash.
>>
>> On 4/22/15 4:06 PM, Pete Brunet wrote:
>>> I was able to build 9 OK then I switched from VS2010 to VS2013 and now
>>> get the following.  I tried hg tpull -u but that didn't help.
>>>
>>> Is there something I need to do besides installing VS Pro 2013 with
>>> Update 4?
>>>
>>> $ make images 2>&1 | tee make-64.log
>>> Building target 'images' in configuration
>>> 'windows-x86_64-normal-server-release'
>>>
>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>> : error C2220: warning treated as error - no 'object' file generated
>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
>>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable deprecated
>>> API warnings
>>>          c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
>>> declaration of 'gethostbyname'
>>> Lib-jdk.hprof.agent.gmk:44: recipe for target
>>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
>>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
>>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
>>> Error 2
>>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
>>> make[2]: *** [jdk.hprof.agent-libs] Error 1
>>> make[2]: *** Waiting for unfinished jobs....
>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
>>> recipe for target 'main' failed
>>> make[1]: *** [main] Error 1
>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
>>> recipe for target 'images' failed
>>> make: *** [images] Error 2
>


From peter.brunet at oracle.com  Thu Apr 23 00:56:18 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 22 Apr 2015 19:56:18 -0500
Subject: 9 b58 fails on Win 8 when screen reader running
In-Reply-To: <5536B0EA.80009@oracle.com>
References: <55369CBF.3010404@oracle.com> <5536A824.3030606@oracle.com>
	<5536B0EA.80009@oracle.com>
Message-ID: <55384332.5040801@oracle.com>

The problem is fixed by doing this (using the VS2013 versions of the
dump/editbin):
editbin ...\java.exe /HIGHENTROPYVA:NO

You can see the before and after using
dumpbin ...\java.exe /HEADERS

Before:

OPTIONAL HEADER VALUES
...
            8160 DLL characteristics
                   High Entropy Virtual Addresses
                   Dynamic base
                   NX compatible
                   Terminal Server Aware

After:

OPTIONAL HEADER VALUES
...
            8140 DLL characteristics
                   Dynamic base
                   NX compatible
                   Terminal Server Aware

The following is from an industry contact who ran into the same thing in
their own app:

The high-entropy 64-bit address space layout randomization feature is
specific to 64-bit versions of Windows 8. It is discussed in some detail
in the article "Software defense: mitigating common exploitation
techniques" found at
http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx.

This feature is enabled by default in 64-bit executable images and can
be disabled via the /HIGHENTROPYVA:NO linker switch. See
http://msdn.microsoft.com/en-us/library/jj835761.aspx

With the high-entropy 64-bit address space layout randomization option
enabled, all memory addresses in a 64-bit app are guaranteed to be above
4gb. This means that if any module has latent pointer truncation issues
in 64-bit builds, these issues will manifest themselves when this flag
is set.

Pete

On 4/21/15 3:19 PM, Pete Brunet wrote:
> Hi Phil,
>
> On 4/21/15 2:42 PM, Phil Race wrote:
>> Perhaps JAWS is not well behaved w.r.t multiple DLL versions ?
> Tell me more.
>> Does it happen only on win 8 ? If you boot the same system into win 8
>> or win 8.1 is it OK ?
> Win 7 is no problem.  I run Win 8.1 Pro in a VirtualBox VM.  This bug
> was reported as
> https://bugs.openjdk.java.net/browse/intjdk-7615864
>> What do you see logged by hotspot from typing Ctrl-Break in the shell ?
> It will be back to the command prompt before I can do that.
>> Other than that, debugging is very likely going to require you build
>> with VS2013
>>
>> Does it happen if you use javaw instead of java ?
> Same behavior: splash screen, then back to the prompt.
>> -phil.
>>
>> On 04/21/2015 11:53 AM, Pete Brunet wrote:
>>> Starting with b58 with JAWS (screen reader) running on Win 8, when
>>> starting SwingSet2 the splash screen appears but the application doesn't
>>> start.  There are no messages in the console.  I see b58 only had one
>>> fix:
>>>
>>> 8076531 infrastructure Switch default compiler on Windows to VS2013
>>>
>>> What might be wrong?
>>>
>>> How do I debug this?
>>>
>>> Pete



From peter.brunet at oracle.com  Thu Apr 23 00:57:39 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 22 Apr 2015 19:57:39 -0500
Subject: build failure after switching to vs2013
In-Reply-To: <55383368.1070003@oracle.com>
References: <55380D4E.7080700@oracle.com> <55380EA4.7030901@oracle.com>
	<55381A5D.1020900@oracle.com> <55383368.1070003@oracle.com>
Message-ID: <55384383.6020007@oracle.com>



On 4/22/15 6:48 PM, David Holmes wrote:
> Peter,
>
> See
>
> https://bugs.openjdk.java.net/browse/JDK-8077422
>
> update 4 is not supported yet.
Hi David, Do I need to uninstall Update 4 and install Update 3?  -Pete
>
> David
>
> On 23/04/2015 8:02 AM, Pete Brunet wrote:
>> This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now:
>>
>>       LANG := C, \
>>       OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \
>>       CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \
>> +        -D_WINSOCK_DEPRECATED_NO_WARNINGS \
>>           $(BUILD_LIBHPROF_CFLAGS), \
>>       CFLAGS_debug := -DHPROF_LOGGING, \
>>       MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \
>>
>> Pete
>>
>> On 4/22/15 4:12 PM, Pete Brunet wrote:
>>> p.s. I also had done a make reconfigure and make clean.  I'll try make
>>> clean and reconfigure from bash.
>>>
>>> On 4/22/15 4:06 PM, Pete Brunet wrote:
>>>> I was able to build 9 OK then I switched from VS2010 to VS2013 and now
>>>> get the following.  I tried hg tpull -u but that didn't help.
>>>>
>>>> Is there something I need to do besides installing VS Pro 2013 with
>>>> Update 4?
>>>>
>>>> $ make images 2>&1 | tee make-64.log
>>>> Building target 'images' in configuration
>>>> 'windows-x86_64-normal-server-release'
>>>>
>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>>>
>>>> : error C2220: warning treated as error - no 'object' file generated
>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>>>
>>>> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
>>>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable
>>>> deprecated
>>>> API warnings
>>>>          c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
>>>> declaration of 'gethostbyname'
>>>> Lib-jdk.hprof.agent.gmk:44: recipe for target
>>>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
>>>>
>>>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
>>>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
>>>>
>>>> Error 2
>>>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
>>>> make[2]: *** [jdk.hprof.agent-libs] Error 1
>>>> make[2]: *** Waiting for unfinished jobs....
>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
>>>> recipe for target 'main' failed
>>>> make[1]: *** [main] Error 1
>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
>>>> recipe for target 'images' failed
>>>> make: *** [images] Error 2
>>



From david.holmes at oracle.com  Thu Apr 23 01:00:07 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 23 Apr 2015 11:00:07 +1000
Subject: build failure after switching to vs2013
In-Reply-To: <55384383.6020007@oracle.com>
References: <55380D4E.7080700@oracle.com> <55380EA4.7030901@oracle.com>
	<55381A5D.1020900@oracle.com> <55383368.1070003@oracle.com>
	<55384383.6020007@oracle.com>
Message-ID: <55384417.4030803@oracle.com>

On 23/04/2015 10:57 AM, Pete Brunet wrote:
> On 4/22/15 6:48 PM, David Holmes wrote:
>> Peter,
>>
>> See
>>
>> https://bugs.openjdk.java.net/browse/JDK-8077422
>>
>> update 4 is not supported yet.
> Hi David, Do I need to uninstall Update 4 and install Update 3?  -Pete

I was assume so - I have no personal experience with these tools.

David

>>
>> David
>>
>> On 23/04/2015 8:02 AM, Pete Brunet wrote:
>>> This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now:
>>>
>>>        LANG := C, \
>>>        OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \
>>>        CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \
>>> +        -D_WINSOCK_DEPRECATED_NO_WARNINGS \
>>>            $(BUILD_LIBHPROF_CFLAGS), \
>>>        CFLAGS_debug := -DHPROF_LOGGING, \
>>>        MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \
>>>
>>> Pete
>>>
>>> On 4/22/15 4:12 PM, Pete Brunet wrote:
>>>> p.s. I also had done a make reconfigure and make clean.  I'll try make
>>>> clean and reconfigure from bash.
>>>>
>>>> On 4/22/15 4:06 PM, Pete Brunet wrote:
>>>>> I was able to build 9 OK then I switched from VS2010 to VS2013 and now
>>>>> get the following.  I tried hg tpull -u but that didn't help.
>>>>>
>>>>> Is there something I need to do besides installing VS Pro 2013 with
>>>>> Update 4?
>>>>>
>>>>> $ make images 2>&1 | tee make-64.log
>>>>> Building target 'images' in configuration
>>>>> 'windows-x86_64-normal-server-release'
>>>>>
>>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>>>>
>>>>> : error C2220: warning treated as error - no 'object' file generated
>>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>>>>
>>>>> : warning C4996: 'gethostbyname': Use getaddrinfo() or GetAddrInfoW()
>>>>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable
>>>>> deprecated
>>>>> API warnings
>>>>>           c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
>>>>> declaration of 'gethostbyname'
>>>>> Lib-jdk.hprof.agent.gmk:44: recipe for target
>>>>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
>>>>>
>>>>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
>>>>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
>>>>>
>>>>> Error 2
>>>>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
>>>>> make[2]: *** [jdk.hprof.agent-libs] Error 1
>>>>> make[2]: *** Waiting for unfinished jobs....
>>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
>>>>> recipe for target 'main' failed
>>>>> make[1]: *** [main] Error 1
>>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
>>>>> recipe for target 'images' failed
>>>>> make: *** [images] Error 2
>>>
>


From erik.joelsson at oracle.com  Thu Apr 23 01:18:57 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 22 Apr 2015 18:18:57 -0700
Subject: build failure after switching to vs2013
In-Reply-To: <55384417.4030803@oracle.com>
References: <55380D4E.7080700@oracle.com> <55380EA4.7030901@oracle.com>
	<55381A5D.1020900@oracle.com> <55383368.1070003@oracle.com>
	<55384383.6020007@oracle.com> <55384417.4030803@oracle.com>
Message-ID: <55384881.6000803@oracle.com>

I'm currently working on updating the official compilers used internally 
at Oracle and the intended version for VS is VS2013 sp4. Servicability 
closed the bug David linked, but since the removal of that code hasn't 
happened yet, I think we should propose your patch as a fix for that bug.

/Erik

On 2015-04-22 18:00, David Holmes wrote:
> On 23/04/2015 10:57 AM, Pete Brunet wrote:
>> On 4/22/15 6:48 PM, David Holmes wrote:
>>> Peter,
>>>
>>> See
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8077422
>>>
>>> update 4 is not supported yet.
>> Hi David, Do I need to uninstall Update 4 and install Update 3? -Pete
>
> I was assume so - I have no personal experience with these tools.
>
> David
>
>>>
>>> David
>>>
>>> On 23/04/2015 8:02 AM, Pete Brunet wrote:
>>>> This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now:
>>>>
>>>>        LANG := C, \
>>>>        OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \
>>>>        CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \
>>>> +        -D_WINSOCK_DEPRECATED_NO_WARNINGS \
>>>>            $(BUILD_LIBHPROF_CFLAGS), \
>>>>        CFLAGS_debug := -DHPROF_LOGGING, \
>>>>        MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \
>>>>
>>>> Pete
>>>>
>>>> On 4/22/15 4:12 PM, Pete Brunet wrote:
>>>>> p.s. I also had done a make reconfigure and make clean.  I'll try 
>>>>> make
>>>>> clean and reconfigure from bash.
>>>>>
>>>>> On 4/22/15 4:06 PM, Pete Brunet wrote:
>>>>>> I was able to build 9 OK then I switched from VS2010 to VS2013 
>>>>>> and now
>>>>>> get the following.  I tried hg tpull -u but that didn't help.
>>>>>>
>>>>>> Is there something I need to do besides installing VS Pro 2013 with
>>>>>> Update 4?
>>>>>>
>>>>>> $ make images 2>&1 | tee make-64.log
>>>>>> Building target 'images' in configuration
>>>>>> 'windows-x86_64-normal-server-release'
>>>>>>
>>>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86) 
>>>>>>
>>>>>>
>>>>>> : error C2220: warning treated as error - no 'object' file generated
>>>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86) 
>>>>>>
>>>>>>
>>>>>> : warning C4996: 'gethostbyname': Use getaddrinfo() or 
>>>>>> GetAddrInfoW()
>>>>>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable
>>>>>> deprecated
>>>>>> API warnings
>>>>>> c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
>>>>>> declaration of 'gethostbyname'
>>>>>> Lib-jdk.hprof.agent.gmk:44: recipe for target
>>>>>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h 
>>>>>>
>>>>>>
>>>>>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
>>>>>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj] 
>>>>>>
>>>>>>
>>>>>> Error 2
>>>>>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
>>>>>> make[2]: *** [jdk.hprof.agent-libs] Error 1
>>>>>> make[2]: *** Waiting for unfinished jobs....
>>>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
>>>>>> recipe for target 'main' failed
>>>>>> make[1]: *** [main] Error 1
>>>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
>>>>>> recipe for target 'images' failed
>>>>>> make: *** [images] Error 2
>>>>
>>



From erik.joelsson at oracle.com  Thu Apr 23 01:20:06 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 22 Apr 2015 18:20:06 -0700
Subject: 9 b58 fails on Win 8 when screen reader running
In-Reply-To: <55384332.5040801@oracle.com>
References: <55369CBF.3010404@oracle.com> <5536A824.3030606@oracle.com>
	<5536B0EA.80009@oracle.com> <55384332.5040801@oracle.com>
Message-ID: <553848C6.7020403@oracle.com>

That's an interesting find. I suppose we need to add that linker flag 
then. Do you have a bug opened for this issue?

/Erik

On 2015-04-22 17:56, Pete Brunet wrote:
> The problem is fixed by doing this (using the VS2013 versions of the
> dump/editbin):
> editbin ...\java.exe /HIGHENTROPYVA:NO
>
> You can see the before and after using
> dumpbin ...\java.exe /HEADERS
>
> Before:
>
> OPTIONAL HEADER VALUES
> ...
>              8160 DLL characteristics
>                     High Entropy Virtual Addresses
>                     Dynamic base
>                     NX compatible
>                     Terminal Server Aware
>
> After:
>
> OPTIONAL HEADER VALUES
> ...
>              8140 DLL characteristics
>                     Dynamic base
>                     NX compatible
>                     Terminal Server Aware
>
> The following is from an industry contact who ran into the same thing in
> their own app:
>
> The high-entropy 64-bit address space layout randomization feature is
> specific to 64-bit versions of Windows 8. It is discussed in some detail
> in the article "Software defense: mitigating common exploitation
> techniques" found at
> http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx.
>
> This feature is enabled by default in 64-bit executable images and can
> be disabled via the /HIGHENTROPYVA:NO linker switch. See
> http://msdn.microsoft.com/en-us/library/jj835761.aspx
>
> With the high-entropy 64-bit address space layout randomization option
> enabled, all memory addresses in a 64-bit app are guaranteed to be above
> 4gb. This means that if any module has latent pointer truncation issues
> in 64-bit builds, these issues will manifest themselves when this flag
> is set.
>
> Pete
>
> On 4/21/15 3:19 PM, Pete Brunet wrote:
>> Hi Phil,
>>
>> On 4/21/15 2:42 PM, Phil Race wrote:
>>> Perhaps JAWS is not well behaved w.r.t multiple DLL versions ?
>> Tell me more.
>>> Does it happen only on win 8 ? If you boot the same system into win 8
>>> or win 8.1 is it OK ?
>> Win 7 is no problem.  I run Win 8.1 Pro in a VirtualBox VM.  This bug
>> was reported as
>> https://bugs.openjdk.java.net/browse/intjdk-7615864
>>> What do you see logged by hotspot from typing Ctrl-Break in the shell ?
>> It will be back to the command prompt before I can do that.
>>> Other than that, debugging is very likely going to require you build
>>> with VS2013
>>>
>>> Does it happen if you use javaw instead of java ?
>> Same behavior: splash screen, then back to the prompt.
>>> -phil.
>>>
>>> On 04/21/2015 11:53 AM, Pete Brunet wrote:
>>>> Starting with b58 with JAWS (screen reader) running on Win 8, when
>>>> starting SwingSet2 the splash screen appears but the application doesn't
>>>> start.  There are no messages in the console.  I see b58 only had one
>>>> fix:
>>>>
>>>> 8076531 infrastructure Switch default compiler on Windows to VS2013
>>>>
>>>> What might be wrong?
>>>>
>>>> How do I debug this?
>>>>
>>>> Pete



From peter.brunet at oracle.com  Thu Apr 23 02:26:42 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Wed, 22 Apr 2015 21:26:42 -0500
Subject: 9 b58 fails on Win 8 when screen reader running
In-Reply-To: <553848C6.7020403@oracle.com>
References: <55369CBF.3010404@oracle.com> <5536A824.3030606@oracle.com>
	<5536B0EA.80009@oracle.com> <55384332.5040801@oracle.com>
	<553848C6.7020403@oracle.com>
Message-ID: <55385862.1020500@oracle.com>

Hi Erik, It's https://bugs.openjdk.java.net/browse/INTJDK-7615864.

On 4/22/15 8:20 PM, Erik Joelsson wrote:
> That's an interesting find. I suppose we need to add that linker flag
> then. Do you have a bug opened for this issue?
>
> /Erik
>
> On 2015-04-22 17:56, Pete Brunet wrote:
>> The problem is fixed by doing this (using the VS2013 versions of the
>> dump/editbin):
>> editbin ...\java.exe /HIGHENTROPYVA:NO
>>
>> You can see the before and after using
>> dumpbin ...\java.exe /HEADERS
>>
>> Before:
>>
>> OPTIONAL HEADER VALUES
>> ...
>>              8160 DLL characteristics
>>                     High Entropy Virtual Addresses
>>                     Dynamic base
>>                     NX compatible
>>                     Terminal Server Aware
>>
>> After:
>>
>> OPTIONAL HEADER VALUES
>> ...
>>              8140 DLL characteristics
>>                     Dynamic base
>>                     NX compatible
>>                     Terminal Server Aware
>>
>> The following is from an industry contact who ran into the same thing in
>> their own app:
>>
>> The high-entropy 64-bit address space layout randomization feature is
>> specific to 64-bit versions of Windows 8. It is discussed in some detail
>> in the article "Software defense: mitigating common exploitation
>> techniques" found at
>> http://blogs.technet.com/b/srd/archive/2013/12/11/software-defense-mitigating-common-exploitation-techniques.aspx.
>>
>>
>> This feature is enabled by default in 64-bit executable images and can
>> be disabled via the /HIGHENTROPYVA:NO linker switch. See
>> http://msdn.microsoft.com/en-us/library/jj835761.aspx
>>
>> With the high-entropy 64-bit address space layout randomization option
>> enabled, all memory addresses in a 64-bit app are guaranteed to be above
>> 4gb. This means that if any module has latent pointer truncation issues
>> in 64-bit builds, these issues will manifest themselves when this flag
>> is set.
>>
>> Pete
>>
>> On 4/21/15 3:19 PM, Pete Brunet wrote:
>>> Hi Phil,
>>>
>>> On 4/21/15 2:42 PM, Phil Race wrote:
>>>> Perhaps JAWS is not well behaved w.r.t multiple DLL versions ?
>>> Tell me more.
>>>> Does it happen only on win 8 ? If you boot the same system into win 8
>>>> or win 8.1 is it OK ?
>>> Win 7 is no problem.  I run Win 8.1 Pro in a VirtualBox VM.  This bug
>>> was reported as
>>> https://bugs.openjdk.java.net/browse/intjdk-7615864
>>>> What do you see logged by hotspot from typing Ctrl-Break in the
>>>> shell ?
>>> It will be back to the command prompt before I can do that.
>>>> Other than that, debugging is very likely going to require you build
>>>> with VS2013
>>>>
>>>> Does it happen if you use javaw instead of java ?
>>> Same behavior: splash screen, then back to the prompt.
>>>> -phil.
>>>>
>>>> On 04/21/2015 11:53 AM, Pete Brunet wrote:
>>>>> Starting with b58 with JAWS (screen reader) running on Win 8, when
>>>>> starting SwingSet2 the splash screen appears but the application
>>>>> doesn't
>>>>> start.  There are no messages in the console.  I see b58 only had one
>>>>> fix:
>>>>>
>>>>> 8076531 infrastructure Switch default compiler on Windows to VS2013
>>>>>
>>>>> What might be wrong?
>>>>>
>>>>> How do I debug this?
>>>>>
>>>>> Pete
>



From staffan.larsen at oracle.com  Thu Apr 23 12:06:27 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Thu, 23 Apr 2015 14:06:27 +0200
Subject: RFR: 8076473 Remove the jhat code and update makefiles
Message-ID: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>

Please review this change to remove the jhat tool. I will not push this change until the tests have been removed (see a different review thread).

JEP: https://bugs.openjdk.java.net/browse/JDK-8059039 <https://bugs.openjdk.java.net/browse/JDK-8059039> 
bug: https://bugs.openjdk.java.net/browse/JDK-8076473 <https://bugs.openjdk.java.net/browse/JDK-8076473>

webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ <http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/>
webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ <http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/>

Thanks,
/Staffan



From Alan.Bateman at oracle.com  Thu Apr 23 12:15:14 2015
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 23 Apr 2015 13:15:14 +0100
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
Message-ID: <5538E252.9040006@oracle.com>



On 23/04/2015 13:06, Staffan Larsen wrote:
> Please review this change to remove the jhat tool. I will not push 
> this change until the tests have been removed (see a different review 
> thread).
>
> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>
> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ 
> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.root.00/>
> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ 
> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.jdk.00/>
>
This looks good to me, and I assume Katja's patch from yesterday got all 
the tests.

-Alan.


From sbaiduzh at redhat.com  Thu Apr 23 13:52:48 2015
From: sbaiduzh at redhat.com (Stanislav Baiduzhyi)
Date: Thu, 23 Apr 2015 15:52:48 +0200
Subject: RFR (XS) 8078404: VERBOSE make flag is not handled properly
Message-ID: <1916332.n0AEn7rVWJ@thinkpad.hell>

Hi All,

Please review and sponsor following webrev. It fixes the use of VERBOSE make 
flag for openjdk 8. Currently, executing 'build VERBOSE=1 images' fails with 
"No rule to make target '1'".

Webrev:
https://487f7412f3e78e1958440a7d4d778f6aa5da2088.googledrive.com/host/0B5Kp-cB1sXJrfmN3c3hidnYzcWp3X0pwMjN2cXM1YUtmLW1WdzlyeU45eHF3RHI5X09uX00/fix-verbose/

Bug:
https://bugs.openjdk.java.net/browse/JDK-8078404

-- 
Regards,
    Stas



From erik.joelsson at oracle.com  Thu Apr 23 15:22:56 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Apr 2015 08:22:56 -0700
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <5538E252.9040006@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
	<5538E252.9040006@oracle.com>
Message-ID: <55390E50.1050209@oracle.com>

Looks good to me.

/Erik

On 2015-04-23 05:15, Alan Bateman wrote:
>
>
> On 23/04/2015 13:06, Staffan Larsen wrote:
>> Please review this change to remove the jhat tool. I will not push 
>> this change until the tests have been removed (see a different review 
>> thread).
>>
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
>> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>>
>> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ 
>> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.root.00/>
>> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ 
>> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.jdk.00/>
>>
> This looks good to me, and I assume Katja's patch from yesterday got 
> all the tests.
>
> -Alan.



From erik.joelsson at oracle.com  Thu Apr 23 15:30:46 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Apr 2015 08:30:46 -0700
Subject: RFR (XS) 8078404: VERBOSE make flag is not handled properly
In-Reply-To: <1916332.n0AEn7rVWJ@thinkpad.hell>
References: <1916332.n0AEn7rVWJ@thinkpad.hell>
Message-ID: <55391026.30309@oracle.com>

Hello Stanislav,

What do you want to achieve by setting VERBOSE=1? AFAIK that has never 
been a valid value for the VERBOSE input variable. In jdk8, we initially 
introduced VERBOSE as an input variable to the new build system. It was 
default set to "-s" to make the build quiet, but if you wanted command 
lines echoed, you used "make VERBOSE=". That was later superseded by the 
LOG input variable, which is set to a log level like "info, warn, debug, 
trace". In jdk9, we completely removed support for the VERBOSE input 
variable.

/Erik

On 2015-04-23 06:52, Stanislav Baiduzhyi wrote:
> Hi All,
>
> Please review and sponsor following webrev. It fixes the use of VERBOSE make
> flag for openjdk 8. Currently, executing 'build VERBOSE=1 images' fails with
> "No rule to make target '1'".
>
> Webrev:
> https://487f7412f3e78e1958440a7d4d778f6aa5da2088.googledrive.com/host/0B5Kp-cB1sXJrfmN3c3hidnYzcWp3X0pwMjN2cXM1YUtmLW1WdzlyeU45eHF3RHI5X09uX00/fix-verbose/
>
> Bug:
> https://bugs.openjdk.java.net/browse/JDK-8078404
>



From erik.joelsson at oracle.com  Thu Apr 23 16:42:38 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Apr 2015 09:42:38 -0700
Subject: RFR: JDK-8078437: Enable use of devkits for Windows
Message-ID: <553920FE.8070809@oracle.com>

Hello,

Internally at Oracle, we have been using devkits for building on Linux 
and Solaris. We would like to extend this to also work on Windows for 
our internal build servers. Using a devkit simplifies build server setup 
and maintenance greatly by not having to pre install a certain version 
of Visual Studio but instead being able to just plop down a bundle with 
the correct version.

This patch provides a script that generates the devkit for VS2013 (for 
future reference and documentation) and changes configure to accept it 
using the --with-devkit option.

Configuring a build to use the installed Visual Studio will continue to 
work as before and will most likely continue to be the preferred way of 
building for most developers.

Bug: https://bugs.openjdk.java.net/browse/JDK-8078437
Webrev: http://cr.openjdk.java.net/~erikj/8078437/webrev.01/

/Erik


From serguei.spitsyn at oracle.com  Thu Apr 23 19:52:42 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 23 Apr 2015 12:52:42 -0700
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
Message-ID: <55394D8A.4080101@oracle.com>

It looks good.
A question:
   Do we want to get rid of the jhat in the 
jdk/closed/old-build/common/Release.gmk ?
     jhat.1             \
     com/sun/tools/hat       \
     jhat$(EXE_SUFFIX)

Thanks,
Serguei



On 4/23/15 5:06 AM, Staffan Larsen wrote:
> Please review this change to remove the jhat tool. I will not push 
> this change until the tests have been removed (see a different review 
> thread).
>
> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>
> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ 
> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.root.00/>
> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ 
> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.jdk.00/>
>
> Thanks,
> /Staffan
>



From erik.joelsson at oracle.com  Thu Apr 23 21:50:04 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Thu, 23 Apr 2015 14:50:04 -0700
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <55394D8A.4080101@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
	<55394D8A.4080101@oracle.com>
Message-ID: <5539690C.4090007@oracle.com>

No, that file is old legacy and not used anymore. It will hopefully soon 
go away.

/Erik

On 2015-04-23 12:52, serguei.spitsyn at oracle.com wrote:
> It looks good.
> A question:
>   Do we want to get rid of the jhat in the 
> jdk/closed/old-build/common/Release.gmk ?
>     jhat.1             \
>     com/sun/tools/hat       \
>     jhat$(EXE_SUFFIX)
>
> Thanks,
> Serguei
>
>
>
> On 4/23/15 5:06 AM, Staffan Larsen wrote:
>> Please review this change to remove the jhat tool. I will not push 
>> this change until the tests have been removed (see a different review 
>> thread).
>>
>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
>> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>>
>> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ 
>> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.root.00/>
>> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ 
>> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.jdk.00/>
>>
>> Thanks,
>> /Staffan
>>
>



From serguei.spitsyn at oracle.com  Thu Apr 23 23:41:35 2015
From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com)
Date: Thu, 23 Apr 2015 16:41:35 -0700
Subject: RFR: 8076473 Remove the jhat code and update makefiles
In-Reply-To: <5539690C.4090007@oracle.com>
References: <02CE85B0-C47A-41DC-A56B-0F021B9945CF@oracle.com>
	<55394D8A.4080101@oracle.com> <5539690C.4090007@oracle.com>
Message-ID: <5539832F.2070900@oracle.com>

On 4/23/15 2:50 PM, Erik Joelsson wrote:
> No, that file is old legacy and not used anymore. It will hopefully 
> soon go away.

Ok then.

Thanks, Erik!
Serguei

>
> /Erik
>
> On 2015-04-23 12:52, serguei.spitsyn at oracle.com wrote:
>> It looks good.
>> A question:
>>   Do we want to get rid of the jhat in the 
>> jdk/closed/old-build/common/Release.gmk ?
>>     jhat.1             \
>>     com/sun/tools/hat       \
>>     jhat$(EXE_SUFFIX)
>>
>> Thanks,
>> Serguei
>>
>>
>>
>> On 4/23/15 5:06 AM, Staffan Larsen wrote:
>>> Please review this change to remove the jhat tool. I will not push 
>>> this change until the tests have been removed (see a different 
>>> review thread).
>>>
>>> JEP: https://bugs.openjdk.java.net/browse/JDK-8059039
>>> bug: https://bugs.openjdk.java.net/browse/JDK-8076473
>>>
>>> webrev root: http://cr.openjdk.java.net/~sla/8076473/webrev.root.00/ 
>>> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.root.00/>
>>> webrev jdk: http://cr.openjdk.java.net/~sla/8076473/webrev.jdk.00/ 
>>> <http://cr.openjdk.java.net/%7Esla/8076473/webrev.jdk.00/>
>>>
>>> Thanks,
>>> /Staffan
>>>
>>
>



From peter.brunet at oracle.com  Fri Apr 24 02:34:41 2015
From: peter.brunet at oracle.com (Pete Brunet)
Date: Thu, 23 Apr 2015 21:34:41 -0500
Subject: build failure after switching to vs2013
In-Reply-To: <55384881.6000803@oracle.com>
References: <55380D4E.7080700@oracle.com> <55380EA4.7030901@oracle.com>
	<55381A5D.1020900@oracle.com> <55383368.1070003@oracle.com>
	<55384383.6020007@oracle.com> <55384417.4030803@oracle.com>
	<55384881.6000803@oracle.com>
Message-ID: <5539ABC1.6000701@oracle.com>

Is there any reason to keep vs2010 on my machine?  I'm short on disk space.

On 4/22/15 8:18 PM, Erik Joelsson wrote:
> I'm currently working on updating the official compilers used
> internally at Oracle and the intended version for VS is VS2013 sp4.
> Servicability closed the bug David linked, but since the removal of
> that code hasn't happened yet, I think we should propose your patch as
> a fix for that bug.
>
> /Erik
>
> On 2015-04-22 18:00, David Holmes wrote:
>> On 23/04/2015 10:57 AM, Pete Brunet wrote:
>>> On 4/22/15 6:48 PM, David Holmes wrote:
>>>> Peter,
>>>>
>>>> See
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8077422
>>>>
>>>> update 4 is not supported yet.
>>> Hi David, Do I need to uninstall Update 4 and install Update 3? -Pete
>>
>> I was assume so - I have no personal experience with these tools.
>>
>> David
>>
>>>>
>>>> David
>>>>
>>>> On 23/04/2015 8:02 AM, Pete Brunet wrote:
>>>>> This hack to jdk/make/lib/Lib-jdk.hprof.agent.gmk works for now:
>>>>>
>>>>>        LANG := C, \
>>>>>        OPTIMIZATION := $(LIBHPROF_OPTIMIZATION), \
>>>>>        CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \
>>>>> +        -D_WINSOCK_DEPRECATED_NO_WARNINGS \
>>>>>            $(BUILD_LIBHPROF_CFLAGS), \
>>>>>        CFLAGS_debug := -DHPROF_LOGGING, \
>>>>>        MAPFILE :=
>>>>> $(JDK_TOPDIR)/make/mapfiles/libhprof/mapfile-vers, \
>>>>>
>>>>> Pete
>>>>>
>>>>> On 4/22/15 4:12 PM, Pete Brunet wrote:
>>>>>> p.s. I also had done a make reconfigure and make clean.  I'll try
>>>>>> make
>>>>>> clean and reconfigure from bash.
>>>>>>
>>>>>> On 4/22/15 4:06 PM, Pete Brunet wrote:
>>>>>>> I was able to build 9 OK then I switched from VS2010 to VS2013
>>>>>>> and now
>>>>>>> get the following.  I tried hg tpull -u but that didn't help.
>>>>>>>
>>>>>>> Is there something I need to do besides installing VS Pro 2013 with
>>>>>>> Update 4?
>>>>>>>
>>>>>>> $ make images 2>&1 | tee make-64.log
>>>>>>> Building target 'images' in configuration
>>>>>>> 'windows-x86_64-normal-server-release'
>>>>>>>
>>>>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>>>>>>
>>>>>>>
>>>>>>> : error C2220: warning treated as error - no 'object' file
>>>>>>> generated
>>>>>>> c:/Users/Pete/JDK9/INTJDK-7615864/client/jdk/src/jdk.hprof.agent/windows/native/libhprof/hprof_md.c(86)
>>>>>>>
>>>>>>>
>>>>>>> : warning C4996: 'gethostbyname': Use getaddrinfo() or
>>>>>>> GetAddrInfoW()
>>>>>>> instead or define _WINSOCK_DEPRECATED_NO_WARNINGS to disable
>>>>>>> deprecated
>>>>>>> API warnings
>>>>>>> c:\progra~2\wi3cf2~1\8.1\include\um\winsock2.h(2238) : see
>>>>>>> declaration of 'gethostbyname'
>>>>>>> Lib-jdk.hprof.agent.gmk:44: recipe for target
>>>>>>> '/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.h
>>>>>>>
>>>>>>>
>>>>>>> prof.agent/libhprof_jvmti/hprof_md.obj' failedmake[3]: ***
>>>>>>> [/cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/build/windows-x86_64-normal-server-release/support/native/jdk.hprof.agent/libhprof_jvmti/hprof_md.obj]
>>>>>>>
>>>>>>>
>>>>>>> Error 2
>>>>>>> make/Main.gmk:168: recipe for target 'jdk.hprof.agent-libs' failed
>>>>>>> make[2]: *** [jdk.hprof.agent-libs] Error 1
>>>>>>> make[2]: *** Waiting for unfinished jobs....
>>>>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:255:
>>>>>>>
>>>>>>> recipe for target 'main' failed
>>>>>>> make[1]: *** [main] Error 1
>>>>>>> /cygdrive/c/Users/Pete/JDK9/INTJDK-7615864/client/make/Init.gmk:171:
>>>>>>>
>>>>>>> recipe for target 'images' failed
>>>>>>> make: *** [images] Error 2
>>>>>
>>>
>



From staffan.larsen at oracle.com  Fri Apr 24 07:25:54 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Fri, 24 Apr 2015 09:25:54 +0200
Subject: RFR: 8066757 Can't build 'images' with --disable-zip-debug-info on OS
	X after jigsaw m2 merge
Message-ID: <A857749C-11F3-4FAE-8ECE-852D60CF3451@oracle.com>

Please review this fix for using --disable-zip-debug-info when compiling the images target.

OS X stores symbol information in a .dylib file inside a .dSYM directory and that file should not be stripped, so this patch prunes the tree at the .dSYM directory.

bug: https://bugs.openjdk.java.net/browse/JDK-8066757
webrev: http://cr.openjdk.java.net/~sla/8066757/webrev.00 <http://cr.openjdk.java.net/~sla/8066757/webrev.00>

Thanks,
/Staffan

From sbaiduzh at redhat.com  Fri Apr 24 11:38:13 2015
From: sbaiduzh at redhat.com (Stanislav Baiduzhyi)
Date: Fri, 24 Apr 2015 13:38:13 +0200
Subject: RFR (XS) 8078404: VERBOSE make flag is not handled properly
In-Reply-To: <55391026.30309@oracle.com>
References: <1916332.n0AEn7rVWJ@thinkpad.hell> <55391026.30309@oracle.com>
Message-ID: <1581671.hYtGbxe1KE@thinkpad.hell>

On Thursday 23 April 2015 08:30:46 Erik Joelsson wrote:
> Hello Stanislav,
> 
> What do you want to achieve by setting VERBOSE=1? AFAIK that has never
> been a valid value for the VERBOSE input variable. In jdk8, we initially
> introduced VERBOSE as an input variable to the new build system. It was
> default set to "-s" to make the build quiet, but if you wanted command
> lines echoed, you used "make VERBOSE=". That was later superseded by the
> LOG input variable, which is set to a log level like "info, warn, debug,
> trace". In jdk9, we completely removed support for the VERBOSE input
> variable.

Ah, so everything I've actually achieved was only dropping '-s' from 
options... Didn't expected that I have to leave VERBOSE empty to override it. 
Sorry for that, and thank you for the detailed explanation.

-- 
Regards,
    Stas



From erik.joelsson at oracle.com  Fri Apr 24 15:21:29 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Fri, 24 Apr 2015 08:21:29 -0700
Subject: RFR: 8066757 Can't build 'images' with --disable-zip-debug-info
	on OS X after jigsaw m2 merge
In-Reply-To: <A857749C-11F3-4FAE-8ECE-852D60CF3451@oracle.com>
References: <A857749C-11F3-4FAE-8ECE-852D60CF3451@oracle.com>
Message-ID: <553A5F79.8090003@oracle.com>

Looks good to me.

/Erik

On 2015-04-24 00:25, Staffan Larsen wrote:
> Please review this fix for using --disable-zip-debug-info when compiling the images target.
>
> OS X stores symbol information in a .dylib file inside a .dSYM directory and that file should not be stripped, so this patch prunes the tree at the .dSYM directory.
>
> bug: https://bugs.openjdk.java.net/browse/JDK-8066757
> webrev: http://cr.openjdk.java.net/~sla/8066757/webrev.00 <http://cr.openjdk.java.net/~sla/8066757/webrev.00>
>
> Thanks,
> /Staffan



From Sergey.Bylokhov at oracle.com  Fri Apr 24 16:56:18 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Fri, 24 Apr 2015 19:56:18 +0300
Subject: Windows configure error : LZMAPATH
In-Reply-To: <5508BF77.2070905@oracle.com>
References: <5508BF77.2070905@oracle.com>
Message-ID: <553A75B2.4020800@oracle.com>

Got the same issue when I try to build jdk8u-dev. But everything is ok 
in jdk9.

On 18.03.2015 2:57, Phil Race wrote:
> I'll admit its been a few weeks since I've build JDK on Windows except 
> via jprt
> but now I can't get past configure and I don't know why its resolving 
> a variable
> that I didn't set instead of looking on my path ..
>
>
> checking Checking for install src... not found, cannot build installer
> checking for JUnit... no, deploy tests cannot be run
> checking for wix... no, needed for installer, set --with-wix=/path/to/wix
> checking for lzma... configure: The path of LZMAPATH, which resolves 
> as "C:/util
> s/", is invalid.
> configure: error: Cannot locate the the path of LZMAPATH
> configure exiting with result code 1
>
> C:\jdks\jdk9-client>set LZMAPATH
> Environment variable LZMAPATH not defined
>
> C:\jdks\jdk9-client>sh
> sh-4.1$ which lzma
> /cygdrive/c/tools/jdkutils/bin/lzma
>
>
> -phil.


-- 
Best regards, Sergey.



From magnus.ihse.bursie at oracle.com  Fri Apr 24 17:04:20 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 24 Apr 2015 19:04:20 +0200
Subject: RFR: JDK-8078437: Enable use of devkits for Windows
In-Reply-To: <553920FE.8070809@oracle.com>
References: <553920FE.8070809@oracle.com>
Message-ID: <AC1EA411-7006-4B62-AB3B-3D8C633685F9@oracle.com>

Looks good to me. 

/Magnus

> 23 apr 2015 kl. 18:42 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Hello,
> 
> Internally at Oracle, we have been using devkits for building on Linux and Solaris. We would like to extend this to also work on Windows for our internal build servers. Using a devkit simplifies build server setup and maintenance greatly by not having to pre install a certain version of Visual Studio but instead being able to just plop down a bundle with the correct version.
> 
> This patch provides a script that generates the devkit for VS2013 (for future reference and documentation) and changes configure to accept it using the --with-devkit option.
> 
> Configuring a build to use the installed Visual Studio will continue to work as before and will most likely continue to be the preferred way of building for most developers.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8078437
> Webrev: http://cr.openjdk.java.net/~erikj/8078437/webrev.01/
> 
> /Erik


From magnus.ihse.bursie at oracle.com  Fri Apr 24 17:05:57 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Fri, 24 Apr 2015 19:05:57 +0200
Subject: RFR: 8066757 Can't build 'images' with --disable-zip-debug-info
	on OS X after jigsaw m2 merge
In-Reply-To: <553A5F79.8090003@oracle.com>
References: <A857749C-11F3-4FAE-8ECE-852D60CF3451@oracle.com>
	<553A5F79.8090003@oracle.com>
Message-ID: <C406EA2B-4E3E-438F-9A73-D799CC83F894@oracle.com>

Looks good to me too. 

/Magnus

> 24 apr 2015 kl. 17:21 skrev Erik Joelsson <erik.joelsson at oracle.com>:
> 
> Looks good to me.
> 
> /Erik
> 
>> On 2015-04-24 00:25, Staffan Larsen wrote:
>> Please review this fix for using --disable-zip-debug-info when compiling the images target.
>> 
>> OS X stores symbol information in a .dylib file inside a .dSYM directory and that file should not be stripped, so this patch prunes the tree at the .dSYM directory.
>> 
>> bug: https://bugs.openjdk.java.net/browse/JDK-8066757
>> webrev: http://cr.openjdk.java.net/~sla/8066757/webrev.00 <http://cr.openjdk.java.net/~sla/8066757/webrev.00>
>> 
>> Thanks,
>> /Staffan
> 


From alexey.menkov at oracle.com  Fri Apr 24 17:37:09 2015
From: alexey.menkov at oracle.com (alexey menkov)
Date: Fri, 24 Apr 2015 20:37:09 +0300
Subject: Windows configure error : LZMAPATH
In-Reply-To: <553A75B2.4020800@oracle.com>
References: <5508BF77.2070905@oracle.com> <553A75B2.4020800@oracle.com>
Message-ID: <553A7F45.8030504@oracle.com>

lzma is required for installer.
You can get it from /java/devtools/windows/bin/
(I suppose both lzma.exe & lzma.dll are required)

regards
Alex

On 24.04.2015 19:56, Sergey Bylokhov wrote:
> Got the same issue when I try to build jdk8u-dev. But everything is ok
> in jdk9.
>
> On 18.03.2015 2:57, Phil Race wrote:
>> I'll admit its been a few weeks since I've build JDK on Windows except
>> via jprt
>> but now I can't get past configure and I don't know why its resolving
>> a variable
>> that I didn't set instead of looking on my path ..
>>
>>
>> checking Checking for install src... not found, cannot build installer
>> checking for JUnit... no, deploy tests cannot be run
>> checking for wix... no, needed for installer, set --with-wix=/path/to/wix
>> checking for lzma... configure: The path of LZMAPATH, which resolves
>> as "C:/util
>> s/", is invalid.
>> configure: error: Cannot locate the the path of LZMAPATH
>> configure exiting with result code 1
>>
>> C:\jdks\jdk9-client>set LZMAPATH
>> Environment variable LZMAPATH not defined
>>
>> C:\jdks\jdk9-client>sh
>> sh-4.1$ which lzma
>> /cygdrive/c/tools/jdkutils/bin/lzma
>>
>>
>> -phil.
>
>


From ingemar.aberg at oracle.com  Mon Apr 27 10:25:27 2015
From: ingemar.aberg at oracle.com (Ingemar Aberg)
Date: Mon, 27 Apr 2015 12:25:27 +0200
Subject: RFR: JDK-8074016 Add convenient way of adding custom test targets
	to hotspot's test makefile
Message-ID: <553E0E97.5060303@oracle.com>

Please review this small fix to hotspot's test makefile

The file hotspot/test/Makefile provides '-include $(ALT_MAKE)/Makefile' 
close to the top (before most variables are set).
Move that line to after the variables are defined so they are available 
to the custom makefile.

Bug: https://bugs.openjdk.java.net/browse/JDK-8074016

Webrev: http://cr.openjdk.java.net/~sla/iaberg/8074016/webrev.00/

/Ingemar


From erik.joelsson at oracle.com  Mon Apr 27 15:58:39 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Mon, 27 Apr 2015 08:58:39 -0700
Subject: RFR: JDK-8074016 Add convenient way of adding custom test targets
	to hotspot's test makefile
In-Reply-To: <553E0E97.5060303@oracle.com>
References: <553E0E97.5060303@oracle.com>
Message-ID: <553E5CAF.7060603@oracle.com>

Looks ok to me, but you should probably get a hotspot review to look at 
it too.

/Erik

On 2015-04-27 03:25, Ingemar Aberg wrote:
> Please review this small fix to hotspot's test makefile
>
> The file hotspot/test/Makefile provides '-include 
> $(ALT_MAKE)/Makefile' close to the top (before most variables are set).
> Move that line to after the variables are defined so they are 
> available to the custom makefile.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074016
>
> Webrev: http://cr.openjdk.java.net/~sla/iaberg/8074016/webrev.00/
>
> /Ingemar



From staffan.larsen at oracle.com  Mon Apr 27 17:52:12 2015
From: staffan.larsen at oracle.com (Staffan Larsen)
Date: Mon, 27 Apr 2015 19:52:12 +0200
Subject: RFR: JDK-8074016 Add convenient way of adding custom test targets
	to hotspot's test makefile
In-Reply-To: <553E0E97.5060303@oracle.com>
References: <553E0E97.5060303@oracle.com>
Message-ID: <49247736-1919-4112-A1EB-CF5AC8BA97AC@oracle.com>

Looks good!

Thanks,
/Staffan

> On 27 apr 2015, at 12:25, Ingemar Aberg <ingemar.aberg at oracle.com> wrote:
> 
> Please review this small fix to hotspot's test makefile
> 
> The file hotspot/test/Makefile provides '-include $(ALT_MAKE)/Makefile' close to the top (before most variables are set).
> Move that line to after the variables are defined so they are available to the custom makefile.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8074016
> 
> Webrev: http://cr.openjdk.java.net/~sla/iaberg/8074016/webrev.00/
> 
> /Ingemar



From david.holmes at oracle.com  Tue Apr 28 07:36:19 2015
From: david.holmes at oracle.com (David Holmes)
Date: Tue, 28 Apr 2015 17:36:19 +1000
Subject: RFR: JDK-8074016 Add convenient way of adding custom test targets
	to hotspot's test makefile
In-Reply-To: <49247736-1919-4112-A1EB-CF5AC8BA97AC@oracle.com>
References: <553E0E97.5060303@oracle.com>
	<49247736-1919-4112-A1EB-CF5AC8BA97AC@oracle.com>
Message-ID: <553F3873.1020709@oracle.com>

+1

At some point we may need a finer-grained include mechanism but for now 
this suffices.

Thanks,
David

On 28/04/2015 3:52 AM, Staffan Larsen wrote:
> Looks good!
>
> Thanks,
> /Staffan
>
>> On 27 apr 2015, at 12:25, Ingemar Aberg <ingemar.aberg at oracle.com> wrote:
>>
>> Please review this small fix to hotspot's test makefile
>>
>> The file hotspot/test/Makefile provides '-include $(ALT_MAKE)/Makefile' close to the top (before most variables are set).
>> Move that line to after the variables are defined so they are available to the custom makefile.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074016
>>
>> Webrev: http://cr.openjdk.java.net/~sla/iaberg/8074016/webrev.00/
>>
>> /Ingemar
>


From sgehwolf at redhat.com  Tue Apr 28 09:41:32 2015
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 28 Apr 2015 11:41:32 +0200
Subject: Why does a fastdebug build compile with -O3 *and* -O0?
In-Reply-To: <553F4B1C.4070207@oracle.com>
References: <1430145195.3349.23.camel@redhat.com> <553F4B1C.4070207@oracle.com>
Message-ID: <1430214092.3399.18.camel@redhat.com>

Hi Mikael,

Adding in build-dev for input.

On Tue, 2015-04-28 at 10:55 +0200, Mikael Gerdin wrote:
> Severin,
> 
> On 2015-04-27 16:33, Severin Gehwolf wrote:
> > Hi,
> >
> > I've noticed that a fastdebug build of recent hs-rt compiles objects
> > with -O3 *and* -O0. Is this a bug or a feature? If it's a feature,
> > what's the rationale?
> 
> This does not appear to be the case when I build on my machine.
> I also don't get "-fstack-protector-all --param ssp-buffer-size=1"
> Those appear to be set in DEBUG_CFLAGS in gcc.make.
> The first line of fastdebug.make uses an interesting hack to set 
> FASTDEBUG_CFLAGS to DEBUG_CFLAGS unless FASTDEBUG_CFLAGS is already set.
> FASTDEBUG_CFLAGS is only set in gcc.make if ENABLE_FULL_DEBUG_SYMBOLS is 0.
> So I tried with:
> hs-rt-open/hotspot$ make -C make/ 
> ALT_BOOTDIR=/usr/lib/jvm/jdk-8-oracle-x64 HOTSPOT_BUILD_JOBS=24 
> ARCH_DATA_MODEL=64 ENABLE_FULL_DEBUG_SYMBOLS=0 fastdebug
> 
> And that reproduces your problem. This is most certainly a bug in the 
> build system.

OK, thanks. Any suggestions as to how to fix this? FWIW, I don't see
this problem for JDK 8 fastdebug builds. Example:
/usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DCHECK_UNHANDLED_OOPS -I. -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_RELEASE_VERSION="\"25.60-b12\"" -DHOTSPOT_BUILD_TARGET="\"fastdebug\"" -DHOTSPOT_BUILD_USER="\"sgehwolf\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""  -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGET_COMPILER_gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64  -pipe -fno-strict-aliasing  -g -fno-omit-frame-pointer -O3  -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value    -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/asParNewGeneration.o.d -fpch-deps -o asParNewGeneration.o /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk8u-dev/hotspot/src/share/vm/gc_implementation/parNew/asParNewGeneration.cpp

My make invocation does indeed have ENABLE_FULL_DEBUG_SYMBOLS=0. The
full make command line is (the comment says it all, but may be outdated
since it's a recurring issue for us distro people):

# In order to get correct debug symbols in libjvm.so we need
# DEBUG_BINARIES=true ENABLE_FULL_DEBUG_SYMBOLS=0 POST_STRIP_CMD=""
make \
 SCTP_WERROR= \
 DEBUG_BINARIES=true \
 ENABLE_FULL_DEBUG_SYMBOLS=0 \
 POST_STRIP_CMD="" \
 DISABLE_INTREE_EC=true \
 LOG=debug
 images

The rationale for DEBUG_BINARIES=true ENABLE_FULL_DEBUG_SYMBOLS=0
POST_STRIP_CMD="" is here (short version: we want full debug symbols in
object files and leave the stripping to rpm):
http://mail.openjdk.java.net/pipermail/build-dev/2014-March/012039.html

Thread started here:
http://mail.openjdk.java.net/pipermail/build-dev/2014-February/012019.html

A somewhat related bug I've filed about this a while ago:
https://bugs.openjdk.java.net/browse/JDK-8073461

If we could fix this proper, then we wouldn't have to use those
non-standard make variables...

Cheers,
Severin

> The hotspot makefiles are horrible.
> 
> /Mikael
> 
> 
> >
> > I'm not sure what GCC does with that, but it appears it just uses -O0
> > (last seen option?).
> >
> > Example:
> > /usr/bin/g++ -DLINUX -D_GNU_SOURCE -DAMD64 -DASSERT -DCHECK_UNHANDLED_OOPS -I. -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/prims -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/precompiled -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/cpu/x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os_cpu/linux_x86/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os/linux/vm -I/home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/os/posix/vm -I../generated -DHOTSPOT_BUILD_USER="\"sgehwolf\"" -DHOTSPOT_LIB_ARCH=\"amd64\" -DHOTSPOT_VM_DISTRO="\"OpenJDK\""  -DTARGET_OS_FAMILY_linux -DTARGET_ARCH_x86 -DTARGET_ARCH_MODEL_x86_64 -DTARGET_OS_ARCH_linux_x86 -DTARGET_OS_ARCH_MODEL_linux_x86_64 -DTARGE!
>  T_COMPILER
> _gcc -DCOMPILER2 -DCOMPILER1 -fPIC -fno-rtti -fno-exceptions -D_REENTRANT -fcheck-new -fvisibility=hidden -m64  -pipe -fno-strict-aliasing -g -fno-omit-frame-pointer -O3  -O0 -fstack-protector-all --param ssp-buffer-size=1 -DVM_LITTLE_ENDIAN -D_LP64=1 -Werror -Wpointer-arith -Wsign-compare -Wundef -Wunused-function -Wunused-value -Wformat=2 -Wreturn-type -Woverloaded-virtual -Wtype-limits   -DDTRACE_ENABLED -c -MMD -MP -MF ../generated/dependencies/virtualMemoryTracker.o.d -fpch-deps -o virtualMemoryTracker.o /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/services/virtualMemoryTracker.cpp
> > Compiling /home/sgehwolf/Documents/openjdk/upstream-sources/openjdk9-hs-rt/hotspot/src/share/vm/runtime/virtualspace.cpp
> >
> > Cheers,
> > Severin
> >





From semyon.sadetsky at oracle.com  Wed Apr 29 07:50:08 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 29 Apr 2015 10:50:08 +0300
Subject: 8u build failure win7/cygwin64
Message-ID: <55408D30.1030806@oracle.com>

Hello,

Please advise what is the source of the next issue:
(...libfdlibm/e_acos.obj file is really absent)


## Starting jdk
Importing CORBA classes.jar
Importing CORBA src.zip
Importing CORBA bin.zip
Importing JAXP classes.jar
Importing JAXP src.zip
Importing JAXWS src.zip
Importing JAXWS classes.jar
Importing LANGTOOLS src.zip
Importing LANGTOOLS classes.jar
Generating charsetmapping classes
Generating buffer classes
Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
Copyright (C) Microsoft Corporation.  All rights reserved.

Compiling 161 files for BUILD_TOOLS
Generating exceptions classes
genSocketOptionRegistry.c
Microsoft (R) Incremental Linker Version 10.00.40219.01
Copyright (C) Microsoft Corporation.  All rights reserved.

Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Copying and cleaning 53 properties
Compiling 521 properties into resource bundles
Creating sun/util/LocaleDataMetaInfo.java from 421 found resources.
Generating sun/misc/Version.java
Generating sun/misc/Version.java compact1
Generating sun/misc/Version.java compact3
Generating sun/misc/Version.java compact2
Aliases: Table size 1024 (10 bits), shift 0, max chain depth 3
Classes: Table size 32 (5 bits), shift 1, max chain depth 3
Cache: Table size 32 (5 bits), shift 1, max chain depth 3
Generating beaninfo
Generating Nimbus source files
[Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 11.0, 
16.0)
[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
[Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 15.0)
[Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 25.0)
[Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0)
Generating HTML DTD file
Compiling 4 files for BUILD_BREAKITERATOR
[Parsed DTD html32 in 159ms]
Compiling 9722 files for BUILD_JDK
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 235 files for BUILD_SECURITY
Compiling 2 files for BUILD_ACCESSBRIDGE_64
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Could not start process!  Failed with error 2: The system cannot find 
the file specified.

lib/CoreLibraries.gmk:37: recipe for target 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
failed
make[2]: *** 
[/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
Error 1
make[2]: *** Waiting for unfinished jobs....
Could not start process!  Failed with error 2: The system cannot find 
the file specified.

Could not start process!  Failed with error 2: The system cannot find 
the file specified.

lib/CoreLibraries.gmk:37: recipe for target 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
failed
make[2]: *** 
[/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
Error 1
lib/CoreLibraries.gmk:37: recipe for target 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
failed
make[2]: *** 
[/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
Error 1
BuildJdk.gmk:70: recipe for target 'libs-only' failed
make[1]: *** [libs-only] Error 2
/home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe for 
target 'jdk-only' failed
make: *** [jdk-only] Error 2





From magnus.ihse.bursie at oracle.com  Wed Apr 29 08:23:09 2015
From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie)
Date: Wed, 29 Apr 2015 10:23:09 +0200
Subject: 8u build failure win7/cygwin64
In-Reply-To: <55408D30.1030806@oracle.com>
References: <55408D30.1030806@oracle.com>
Message-ID: <554094ED.7080801@oracle.com>

On 2015-04-29 09:50, Semyon Sadetsky wrote:
> Hello,
>
> Please advise what is the source of the next issue:
> (...libfdlibm/e_acos.obj file is really absent)

Hi Semyon,

Please re-run with "make LOG=debug JOBS=1" to get a better log prior to 
the failure.

/Magnus

>
>
> ## Starting jdk
> Importing CORBA classes.jar
> Importing CORBA src.zip
> Importing CORBA bin.zip
> Importing JAXP classes.jar
> Importing JAXP src.zip
> Importing JAXWS src.zip
> Importing JAXWS classes.jar
> Importing LANGTOOLS src.zip
> Importing LANGTOOLS classes.jar
> Generating charsetmapping classes
> Generating buffer classes
> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> Compiling 161 files for BUILD_TOOLS
> Generating exceptions classes
> genSocketOptionRegistry.c
> Microsoft (R) Incremental Linker Version 10.00.40219.01
> Copyright (C) Microsoft Corporation.  All rights reserved.
>
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> Copying and cleaning 53 properties
> Compiling 521 properties into resource bundles
> Creating sun/util/LocaleDataMetaInfo.java from 421 found resources.
> Generating sun/misc/Version.java
> Generating sun/misc/Version.java compact1
> Generating sun/misc/Version.java compact3
> Generating sun/misc/Version.java compact2
> Aliases: Table size 1024 (10 bits), shift 0, max chain depth 3
> Classes: Table size 32 (5 bits), shift 1, max chain depth 3
> Cache: Table size 32 (5 bits), shift 1, max chain depth 3
> Generating beaninfo
> Generating Nimbus source files
> [Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 
> 11.0, 16.0)
> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
> 25.0)
> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 
> 15.0)
> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
> 25.0)
> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 
> 15.0)
> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
> 25.0)
> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
> 25.0)
> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 
> 15.0)
> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
> 25.0)
> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 
> 15.0)
> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
> 25.0)
> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
> 25.0)
> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 
> 15.0)
> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
> 25.0)
> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 14.0, 
> 15.0)
> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
> 25.0)
> [Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0)
> Generating HTML DTD file
> Compiling 4 files for BUILD_BREAKITERATOR
> [Parsed DTD html32 in 159ms]
> Compiling 9722 files for BUILD_JDK
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Note: Some input files use unchecked or unsafe operations.
> Note: Recompile with -Xlint:unchecked for details.
> Compiling 235 files for BUILD_SECURITY
> Compiling 2 files for BUILD_ACCESSBRIDGE_64
> Note: Some input files use or override a deprecated API.
> Note: Recompile with -Xlint:deprecation for details.
> Could not start process!  Failed with error 2: The system cannot find 
> the file specified.
>
> lib/CoreLibraries.gmk:37: recipe for target 
> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
> failed
> make[2]: *** 
> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
> Error 1
> make[2]: *** Waiting for unfinished jobs....
> Could not start process!  Failed with error 2: The system cannot find 
> the file specified.
>
> Could not start process!  Failed with error 2: The system cannot find 
> the file specified.
>
> lib/CoreLibraries.gmk:37: recipe for target 
> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
> failed
> make[2]: *** 
> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
> Error 1
> lib/CoreLibraries.gmk:37: recipe for target 
> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
> failed
> make[2]: *** 
> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
> Error 1
> BuildJdk.gmk:70: recipe for target 'libs-only' failed
> make[1]: *** [libs-only] Error 2
> /home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe for 
> target 'jdk-only' failed
> make: *** [jdk-only] Error 2
>
>
>



From semyon.sadetsky at oracle.com  Wed Apr 29 09:43:20 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 29 Apr 2015 12:43:20 +0300
Subject: 8u build failure win7/cygwin64
In-Reply-To: <554094ED.7080801@oracle.com>
References: <55408D30.1030806@oracle.com> <554094ED.7080801@oracle.com>
Message-ID: <5540A7B8.9030408@oracle.com>

Hi Magnus,

This is it:
...
  [14] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [15] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=jsdt.dll" -D "JDK_INTERNAL_NAME=jsdt" -D "JDK_FTYPE=0x2L"
  [16] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjsdt
  [17] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBINSTRUMENT)
  [2] LIBRARY := instrument
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/instrument 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/java/io 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/instrument
  [5] INCLUDE_FILES := EncodingSupport.c EncodingSupport_md.c 
FileSystemSupport_md.c InstrumentationImplNativeMethods.c 
InvocationAdapter.c JarFacade.c JPLISAgent.c JPLISAssert.c 
JavaExceptions.c PathCharsValidator.c Reentrancy.c Utilities.c 
canonicalize_md.c
  [6] LANG := C
  [7] OPTIMIZATION := LOW
  [8] CFLAGS := -nologo -Zi -Zc:wchar_t- -W3 -wd4800 -D_STATIC_CPPLIB 
-D_DISABLE_DEPRECATE_STATIC_CPPLIB -DWIN32_LEAN_AND_MEAN 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL 
-D_AMD64_ -Damd64 -D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' 
-Damd64 -DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/instrument 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/instrument 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/bin 
-Dstrcasecmp=stricmp
  [9] CFLAGS_debug := -DJPLIS_LOGGING
  [10] CFLAGS_release := -DNO_JPLIS_LOGGING
  [11] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libinstrument/mapfile-vers
  [12] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/jli_static.lib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib 
-export:Agent_OnAttach advapi32.lib
  [13] LDFLAGS_linux :=
  [14] LDFLAGS_solaris :=
  [15] LDFLAGS_macosx := -Xlinker -all_load 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjli_static.a 
-framework Cocoa -framework Security -framework ApplicationServices
  [16] LDFLAGS_SUFFIX :=
  [17] LDFLAGS_SUFFIX_macosx := -liconv
  [18] LDFLAGS_SUFFIX_solaris := -L 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin/jli 
-ljli -lc
  [19] LDFLAGS_SUFFIX_linux := -L 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin/jli 
-ljli
  [20] LDFLAGS_SUFFIX_aix := 
-L/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs 
-ljli_static
  [21] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [22] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=instrument.dll" -D "JDK_INTERNAL_NAME=instrument" -D 
"JDK_FTYPE=0x2L"
  [23] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libinstrument
  [24] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBMANAGEMENT)
  [2] LIBRARY := management
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/jdk/internal/cmm 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/management 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/management
  [5] EXCLUDE_FILES := SolarisOperatingSystem.c LinuxOperatingSystem.c 
MacosxOperatingSystem.c
  [6] LANG := C
  [7] OPTIMIZATION := HIGH
  [8] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/management
  [9] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libmanagement/mapfile
  [10] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [11] LDFLAGS_solaris := -lkstat
  [12] LDFLAGS_SUFFIX :=
  [13] LDFLAGS_SUFFIX_windows := jvm.lib psapi.lib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib 
advapi32.lib
  [14] LDFLAGS_SUFFIX_aix := -lperfstat
  [15] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [16] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=management.dll" -D "JDK_INTERNAL_NAME=management" -D 
"JDK_FTYPE=0x2L"
  [17] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libmanagement
  [18] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBHPROF)
  [2] LIBRARY := hprof
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/demo/jvmti/hprof 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/demo/jvmti/hprof
  [5] LANG := C
  [6] OPTIMIZATION := HIGHEST
  [7] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/demo/jvmti/hprof 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/npt 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/npt 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/demo/jvmti/java_crw_demo
  [8] CFLAGS_debug := -DHPROF_LOGGING
  [9] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libhprof/mapfile-vers
  [10] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [11] LDFLAGS_windows := wsock32.lib winmm.lib advapi32.lib
  [12] LDFLAGS_SUFFIX_linux :=
  [13] LDFLAGS_SUFFIX_macosx :=
  [14] LDFLAGS_SUFFIX_solaris := -lsocket -lnsl -lc
  [15] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [16] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=hprof.dll" -D "JDK_INTERNAL_NAME=hprof" -D "JDK_FTYPE=0x2L"
  [17] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libhprof_jvmti
  [18] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBJAVA_CRW_DEMO)
  [2] LIBRARY := java_crw_demo
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/demo/jvmti/java_crw_demo
  [5] LANG := C
  [6] OPTIMIZATION := LOW
  [7] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/demo/jvmti/java_crw_demo
  [8] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libjava_crw_demo/mapfile-vers
  [9] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [10] LDFLAGS_SUFFIX_solaris := -lc
  [11] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [12] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=java_crw_demo.dll" -D "JDK_INTERNAL_NAME=java_crw_demo" -D 
"JDK_FTYPE=0x2L"
  [13] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava_crw_demo
  [14] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBJFR)
  [2] LIBRARY := jfr
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/oracle/jfr
  [5] LANG := C
  [6] OPTIMIZATION := LOW
  [7] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/javavm/export
  [8] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libjfr/mapfile-vers
  [9] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [10] LDFLAGS_SUFFIX_solaris := -lc
  [11] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [12] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=jfr.dll" -D "JDK_INTERNAL_NAME=jfr" -D "JDK_FTYPE=0x2L"
  [13] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjfr
  [14] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBMLIB_IMAGE)
  [2] LIBRARY := mlib_image
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/medialib
  [5] EXCLUDE_FILES := awt_ImagingLib.c mlib_c_ImageBlendTable.c
  [6] LANG := C
  [7] OPTIMIZATION := HIGHEST
  [8] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-D__USE_J2D_NAMES -D__MEDIALIB_OLD_NAMES 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/medialib 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/awt/medialib 
-DMLIB_NO_LIBSUNMATH -DMLIB_OS64BIT
  [9] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libmlib_image/mapfile-vers
  [10] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [11] LDFLAGS_SUFFIX :=
  [12] LDFLAGS_SUFFIX_solaris := -lc
  [13] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [14] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=mlib_image.dll" -D "JDK_INTERNAL_NAME=mlib_image" -D 
"JDK_FTYPE=0x2L"
  [15] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libmlib_image
  [16] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBAWT)
  [2] LIBRARY := awt
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/awt 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/gif 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/cvutils 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/medialib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/debug 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/utility 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/loops 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/pipe 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/opengl 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d/opengl 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/font 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/windows 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d/windows 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d/d3d
  [5] INCLUDE_FILES := gifdecoder.c imageInitIDs.c img_globals.c 
SurfaceData.c Region.c BufImgSurfaceData.c Disposer.c Trace.c 
GraphicsPrimitiveMgr.c Blit.c BlitBg.c ScaledBlit.c FillRect.c 
FillSpans.c FillParallelogram.c DrawParallelogram.c DrawLine.c 
DrawRect.c DrawPolygons.c DrawPath.c FillPath.c ProcessPath.c MaskBlit.c 
MaskFill.c TransformHelper.c AlphaMath.c AlphaMacros.c AnyByte.c 
ByteBinary1Bit.c ByteBinary2Bit.c ByteBinary4Bit.c ByteIndexed.c 
ByteGray.c Index8Gray.c Index12Gray.c AnyShort.c Ushort555Rgb.c 
Ushort565Rgb.c Ushort4444Argb.c Ushort555Rgbx.c UshortGray.c 
UshortIndexed.c Any3Byte.c ThreeByteBgr.c AnyInt.c IntArgb.c 
IntArgbPre.c IntArgbBm.c IntRgb.c IntBgr.c IntRgbx.c Any4Byte.c 
FourByteAbgr.c FourByteAbgrPre.c BufferedMaskBlit.c BufferedRenderPipe.c 
ShapeSpanIterator.c SpanClipRenderer.c awt_ImageRep.c awt_ImagingLib.c 
awt_Mlib.c awt_parseImage.c DataBufferNative.c dither.c debug_assert.c 
debug_mem.c debug_trace.c debug_util.c MapAccelFunc.c AccelGlyphCache.c 
ShaderList.c CmdIDList.cpp Hashtable.cpp GDIHashtable.cpp Devices.cpp 
ObjectList.cpp GDIBlitLoops.cpp GDIRenderer.cpp GDIWindowSurfaceData.cpp 
WindowsFlags.cpp WPrinterJob.cpp awt_%.cpp D3DBlitLoops.cpp 
D3DBufImgOps.cpp D3DContext.cpp D3DGlyphCache.cpp D3DGraphicsDevice.cpp 
D3DMaskBlit.cpp D3DMaskCache.cpp D3DMaskFill.cpp D3DPipelineManager.cpp 
D3DPaints.cpp D3DRenderer.cpp D3DRenderQueue.cpp D3DResourceManager.cpp 
D3DSurfaceData.cpp D3DTextRenderer.cpp D3DVertexCacher.cpp 
ShellFolder2.cpp ThemeReader.cpp ComCtl32Util.cpp DllUtil.cpp 
initIDs.cpp MouseInfo.cpp rect.c OGLBlitLoops.c OGLBufImgOps.c 
OGLContext.c OGLFuncs.c OGLMaskBlit.c OGLMaskFill.c OGLPaints.c 
OGLRenderQueue.c OGLRenderer.c OGLSurfaceData.c OGLTextRenderer.c 
OGLVertexCache.c WGLGraphicsConfig.c WGLSurfaceData.c
  [6] LANG := C++
  [7] OPTIMIZATION := LOW
  [8] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-D__MEDIALIB_OLD_NAMES -D__USE_J2D_NAMES 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/awt 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/gif 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/cvutils 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/medialib 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/debug 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/utility 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/loops 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/pipe 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/opengl 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d/opengl 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d/d3d 
-DMLIB_NO_LIBSUNMATH -EHsc -DUNICODE -D_UNICODE -DMLIB_OS64BIT 
-DINTERNAL_BUILD
  [9] ASFLAGS :=
  [10] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libawt/mapfile-vers
  [11] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [12] LDFLAGS_solaris := -R/usr/dt/lib -R/lib
  [13] LDFLAGS_SUFFIX_linux := -ljvm -lm -ljava
  [14] LDFLAGS_SUFFIX_solaris := -ljvm -lm -ljava -lc
  [15] LDFLAGS_SUFFIX_aix :=-ljvm -lm -ljava -lm
  [16] LDFLAGS_SUFFIX_macosx := -lmlib_image -ljvm -lm -framework Cocoa 
-framework OpenGL -framework JavaNativeFoundation -framework 
JavaRuntimeSupport -framework ApplicationServices -framework 
AudioToolbox -ljava
  [17] LDFLAGS_SUFFIX_windows := kernel32.lib user32.lib gdi32.lib 
winspool.lib imm32.lib ole32.lib uuid.lib shell32.lib comdlg32.lib 
winmm.lib comctl32.lib shlwapi.lib delayimp.lib jvm.lib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib 
advapi32.lib -DELAYLOAD:user32.dll -DELAYLOAD:gdi32.dll 
-DELAYLOAD:shell32.dll -DELAYLOAD:winmm.dll -DELAYLOAD:winspool.drv 
-DELAYLOAD:imm32.dll -DELAYLOAD:ole32.dll -DELAYLOAD:comdlg32.dll 
-DELAYLOAD:comctl32.dll -DELAYLOAD:shlwapi.dll
  [18] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/windows/awt.rc
  [19] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -i 
"/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/windows/native/sun/windows" 
-D "JDK_FNAME=awt.dll" -D "JDK_INTERNAL_NAME=awt" -D "JDK_FTYPE=0x2L"
  [20] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libawt
  [21] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBLCMS)
  [2] LIBRARY := lcms
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/cmm/lcms
  [5] LANG := C
  [6] OPTIMIZATION := HIGHEST
  [7] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-LD 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/debug
  [8] CFLAGS_solaris := -xc99=no_lib
  [9] CFLAGS_windows := -DCMS_IS_WINDOWS_
  [10] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/liblcms/mapfile-vers
  [11] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [12] LDFLAGS_solaris := /usr/lib/libm.so.2
  [13] LDFLAGS_windows := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libawt/awt.lib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib
  [14] LDFLAGS_SUFFIX_solaris := -lawt -ljava -ljvm -lc
  [15] LDFLAGS_SUFFIX_macosx := -lm -lawt -ljava -ljvm
  [16] LDFLAGS_SUFFIX_linux := -lm -lawt -ljava -ljvm
  [17] LDFLAGS_SUFFIX_aix := -lm -lawt -ljava -ljvm
  [18] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [19] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=lcms.dll" -D "JDK_INTERNAL_NAME=lcms" -D "JDK_FTYPE=0x2L"
  [20] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/liblcms
  [21] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBJPEG)
  [2] LIBRARY := jpeg
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/awt/image/jpeg 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/jpeg
  [5] LANG := C
  [6] OPTIMIZATION := HIGHEST
  [7] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/awt/image/jpeg 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/jpeg
  [8] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libjpeg/mapfile-vers-closed
  [9] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [10] LDFLAGS_windows := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib 
jvm.lib
  [11] LDFLAGS_SUFFIX :=
  [12] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [13] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=jpeg.dll" -D "JDK_INTERNAL_NAME=jpeg" -D "JDK_FTYPE=0x2L"
  [14] REORDER :=
  [15] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjpeg
  [16] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBFONTMANAGER)
  [2] LIBRARY := fontmanager
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/font 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/font
  [5] EXCLUDE_FILES := freetypeScaler.c X11FontScaler.c 
X11TextRenderer.c AccelGlyphCache.c
  [6] LANG := C++
  [7] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-DLE_STANDALONE -DHEADLESS 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/font/t2k 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/font/layout 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/cvutils 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/awt 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/debug 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/loops 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/pipe 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d
  [8] CXXFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-DLE_STANDALONE -DHEADLESS 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/font/t2k 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/font/layout 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/cvutils 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/awt 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/debug 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/loops 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/pipe 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d
  [9] OPTIMIZATION := HIGHEST
  [10] CFLAGS_windows = 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/windows 
-DCC_NOEX
  [11] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libfontmanager/mapfile-vers
  [12] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [13] LDFLAGS_SUFFIX :=
  [14] LDFLAGS_SUFFIX_linux := -lawt -lm -ljava -ljvm -lc
  [15] LDFLAGS_SUFFIX_solaris := -lawt -lawt_headless -lc -lm -ljava -ljvm
  [16] LDFLAGS_SUFFIX_aix := -lawt -lawt_headless -lm -ljava -ljvm
  [17] LDFLAGS_SUFFIX_macosx := -lawt -lm -undefined dynamic_lookup 
-ljava -ljvm
  [18] LDFLAGS_SUFFIX_windows := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib 
advapi32.lib user32.lib gdi32.lib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libawt/awt.lib
  [19] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [20] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=fontmanager.dll" -D "JDK_INTERNAL_NAME=fontmanager" -D 
"JDK_FTYPE=0x2L"
  [21] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfontmanager
  [22] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBT2K)
  [2] LIBRARY := t2k
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/font 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/font/t2k 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/font/t2k/ttHints
  [5] EXCLUDE_FILES := orion.c
  [6] LANG := C++
  [7] OPTIMIZATION := HIGH
  [8] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/font/t2k 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/share/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/loops 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/pipe 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d
  [9] CXXFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/font/t2k 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/share/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/font 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/loops 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/pipe 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d
  [10] CFLAGS_windows = -DCC_NOEX
  [11] CXXFLAGS_windows = -DCC_NOEX
  [12] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libt2k/mapfile-vers
  [13] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [14] LDFLAGS_windows := user32.lib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfontmanager/fontmanager.lib
  [15] LDFLAGS_SUFFIX_posix := -lm -lfontmanager -ljava -ljvm -lc
  [16] LDFLAGS_SUFFIX_solaris := -lawt -lawt_xawt
  [17] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [18] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=t2k.dll" -D "JDK_INTERNAL_NAME=t2k" -D "JDK_FTYPE=0x2L"
  [19] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libt2k
  [20] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBJAWT)
  [2] LIBRARY := jawt
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/windows
  [5] INCLUDE_FILES := jawt.cpp
  [6] LANG := C++
  [7] OPTIMIZATION := LOW
  [8] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-EHsc -DUNICODE -D_UNICODE 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/debug 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/cvutils 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/java2d/windows
  [9] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib 
advapi32.lib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libawt/awt.lib
  [10] LDFLAGS_SUFFIX :=
  [11] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [12] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=jawt.dll" -D "JDK_INTERNAL_NAME=jawt" -D "JDK_FTYPE=0x2L"
  [13] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjawt
  [14] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBKCMS)
  [2] LIBRARY := kcms
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/java2d/cmm/kcms
  [5] LANG := C
  [6] EXCLUDE_FILES := ukcpmgr.c unixmem.c
  [7] OPTIMIZATION := LOW
  [8] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-DJAVACMM -DFUT_CALC_EX -DNO_FUT_GCONST
  [9] CFLAGS_linux := -Wno-missing-field-initializers
  [10] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libkcms/mapfile-vers
  [11] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [12] LDFLAGS_SUFFIX_linux := -lc -lpthread
  [13] LDFLAGS_SUFFIX_solaris := -lc
  [14] LDFLAGS_SUFFIX_windows := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib 
advapi32.lib user32.lib version.lib
  [15] LDFLAGS_SUFFIX_posix := -lm -ljava -ljvm
  [16] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/java2d/cmm/kcms/cmm.rc
  [17] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/java2d/cmm/kcms/cmm.rc
  [18] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=kcms.dll" -D "JDK_INTERNAL_NAME=kcms" -D "JDK_FTYPE=0x2L"
  [19] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libkcms
  [20] DEBUG_SYMBOLS := true
SetupNativeCompilation(LIBSPLASHSCREEN)
  [2] LIBRARY := splashscreen
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/jpeg 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/libpng 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/splashscreen 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/giflib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/awt/splashscreen 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/java/util/zip/zlib-1.2.8
  [5] EXCLUDE_FILES := imageioJPEG.c jpegdecoder.c pngtest.c
  [6] LANG := C
  [7] OPTIMIZATION := LOW
  [8] CFLAGS := -DSPLASHSCREEN -DPNG_NO_MMX_CODE 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/image/jpeg 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/libpng 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/splashscreen 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/giflib 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/sun/awt/splashscreen 
-DWITH_WIN32 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/java/util/zip/zlib-1.2.8 
-nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 -D_STATIC_CPPLIB 
-D_DISABLE_DEPRECATE_STATIC_CPPLIB -DWIN32_LEAN_AND_MEAN 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL 
-D_AMD64_ -Damd64 -D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' 
-Damd64 -DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/awt/giflib
  [9] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libsplashscreen/mapfile-vers
  [10] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [11] LDFLAGS_SUFFIX := kernel32.lib user32.lib gdi32.lib delayimp.lib 
-DELAYLOAD:user32.dll
  [12] LDFLAGS_SUFFIX_solaris := -lc
  [13] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [14] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=splashscreen.dll" -D "JDK_INTERNAL_NAME=splashscreen" -D 
"JDK_FTYPE=0x2L"
  [15] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libsplashscreen
  [16] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBDCPR)
  [2] LIBRARY := dcpr
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/dc/doe 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/dc/path 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/dc/pr 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/dc/util
  [5] LANG := C
  [6] OPTIMIZATION := LOW
  [7] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/dc/doe 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/dc/path 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/dc/pr 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/sun/dc/util 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/sun/java2d/pipe
  [8] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libdcpr/mapfile-vers
  [9] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [10] LDFLAGS_SUFFIX := -lm
  [11] LDFLAGS_SUFFIX_windows := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib
  [12] LDFLAGS_SUFFIX_posix := -lm
  [13] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [14] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=dcpr.dll" -D "JDK_INTERNAL_NAME=dcpr" -D "JDK_FTYPE=0x2L"
  [15] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libdcpr
  [16] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBJSOUND)
  [2] LIBRARY := jsound
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/com/sun/media/sound 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/com/sun/media/sound
  [5] INCLUDE_FILES := Utilities.c Platform.c 
PLATFORM_API_WinOS_MidiIn.cpp PLATFORM_API_WinOS_MidiOut.c 
PLATFORM_API_WinOS_Util.c PLATFORM_API_WinOS_Ports.c MidiInDevice.c 
MidiInDeviceProvider.c MidiOutDevice.c MidiOutDeviceProvider.c 
PlatformMidi.c PortMixerProvider.c PortMixer.c
  [6] LANG := C
  [7] OPTIMIZATION := LOW
  [8] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/com/sun/media/sound 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/com/sun/media/sound 
-DX_PLATFORM=X_WINDOWS -DUSE_PLATFORM_MIDI_OUT=TRUE 
-DUSE_PLATFORM_MIDI_IN=TRUE -DUSE_PORTS=TRUE -DX_ARCH=X_AMD64 
-DEXTRA_SOUND_JNI_LIBS='" jsoundds"'
  [9] CXXFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/com/sun/media/sound 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/com/sun/media/sound 
-DX_PLATFORM=X_WINDOWS -DUSE_PLATFORM_MIDI_OUT=TRUE 
-DUSE_PLATFORM_MIDI_IN=TRUE -DUSE_PORTS=TRUE -DX_ARCH=X_AMD64 
-DEXTRA_SOUND_JNI_LIBS='" jsoundds"'
  [10] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/mapfiles/libjsound/mapfile-vers
  [11] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [12] LDFLAGS_macosx := -framework CoreAudio -framework CoreFoundation 
-framework CoreServices -framework AudioUnit -framework CoreMIDI 
-framework AudioToolbox
  [13] LDFLAGS_windows := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib 
advapi32.lib winmm.lib
  [14] LDFLAGS_SUFFIX_posix := -ljava -ljvm
  [15] LDFLAGS_SUFFIX_solaris := -lc
  [16] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [17] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=jsound.dll" -D "JDK_INTERNAL_NAME=jsound" -D "JDK_FTYPE=0x2L"
  [18] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjsound
  [19] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBJSOUNDDS)
  [2] LIBRARY := jsoundds
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/com/sun/media/sound 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/com/sun/media/sound
  [5] INCLUDE_FILES := Utilities.c DirectAudioDeviceProvider.c 
DirectAudioDevice.c PLATFORM_API_WinOS_DirectSound.cpp
  [6] LANG := C++
  [7] OPTIMIZATION := LOW
  [8] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/com/sun/media/sound 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/com/sun/media/sound 
-DX_PLATFORM=X_WINDOWS -DUSE_PLATFORM_MIDI_OUT=TRUE 
-DUSE_PLATFORM_MIDI_IN=TRUE -DUSE_PORTS=TRUE -DX_ARCH=X_AMD64 
-DEXTRA_SOUND_JNI_LIBS='" jsoundds"' -DUSE_DAUDIO=TRUE
  [9] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [10] LDFLAGS_SUFFIX := dsound.lib winmm.lib user32.lib ole32.lib
  [11] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [12] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=jsoundds.dll" -D "JDK_INTERNAL_NAME=jsoundds" -D "JDK_FTYPE=0x2L"
  [13] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjsoundds
  [14] DEBUG_SYMBOLS := true
SetupNativeCompilation(BUILD_LIBRESOURCE)
  [2] LIBRARY := resource
  [3] OUTPUT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/bin
  [4] SRC := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/native/jdk/management/resource
  [5] LANG := C
  [6] OPTIMIZATION := LOW
  [7] CFLAGS := -nologo -Zi -MD -Zc:wchar_t- -W3 -wd4800 
-D_STATIC_CPPLIB -D_DISABLE_DEPRECATE_STATIC_CPPLIB 
-DWIN32_LEAN_AND_MEAN -D_CRT_SECURE_NO_DEPRECATE 
-D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL -D_AMD64_ -Damd64 
-D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' -Damd64 
-DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/closed/share/javavm/export
  [8] MAPFILE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make/closed/mapfiles/resource/mapfile-vers
  [9] LDFLAGS := -nologo -opt:ref -incremental:no -debug -dll 
-libpath:/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/lib
  [10] LDFLAGS_SUFFIX :=
  [11] LDFLAGS_SUFFIX_windows := jvm.lib 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libjava/java.lib
  [12] VERSIONINFO_RESOURCE := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/resource/version.rc
  [13] RC_FLAGS := -nologo -l 0x409 -r -d 
"JDK_BUILD_ID=1.8.0-internal-fastdebug-ssadetskrussadetsk_2015_04_29_10_24-b00" 
-d "JDK_COMPANY=Oracle Corporation" -d "JDK_COMPONENT=Java(TM) Platform 
SE binary" -d "JDK_VER=8.0.0.0" -d "JDK_COPYRIGHT=Copyright \xA9 2015" 
-d "JDK_NAME=Java(TM) Platform SE 8 " -d "JDK_FVER=8,0,0,0" -D 
"JDK_FNAME=resource.dll" -D "JDK_INTERNAL_NAME=resource" -D "JDK_FTYPE=0x2L"
  [14] OBJECT_DIR := 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libresource
  [15] DEBUG_SYMBOLS := true
(/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/fixpath.exe 
-c CCACHE_COMPRESS=1  CCACHE_SLOPPINESS=time_macros /usr/bin/ccache 
/cygdrive/c/progra~2/micros~1.0/vc/bin/amd64/cl -nologo -Zi -MD 
-Zc:wchar_t- -W3 -wd4800 -D_STATIC_CPPLIB 
-D_DISABLE_DEPRECATE_STATIC_CPPLIB -DWIN32_LEAN_AND_MEAN 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_NONSTDC_NO_DEPRECATE -DWIN32 -DIAL 
-D_AMD64_ -Damd64 -D_LITTLE_ENDIAN -DWINDOWS -DDEBUG -DARCH='"amd64"' 
-Damd64 -DRELEASE='"1.8.0-internal-fastdebug"' 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/include/windows 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/javavm/export 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/windows/native/common 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/gensrc_headers 
-I/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/java/lang/fdlibm/include 
-DLOGGING  -Od  -DTHIS_FILE='"e_acos.c"' -c -showIncludes 
-Fd/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.pdb 
-Fm/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.map 
-Fo/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/src/share/native/java/lang/fdlibm/src/e_acos.c 
; echo $? > 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.d.exitvalue) 
| /usr/bin/tee 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.d.raw 
| /usr/bin/grep -v "^Note: including file:" && exit `cat 
/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.d.exitvalue`
Could not start process!  Failed with error 2: The system cannot find 
the file specified.

lib/CoreLibraries.gmk:37: recipe for target 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
failed
make[2]: *** 
[/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
Error 1
make[2]: Leaving directory 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make'
make[1]: *** [libs-only] Error 2
BuildJdk.gmk:70: recipe for target 'libs-only' failed
make[1]: Leaving directory 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/jdk/make'
/home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe for 
target 'jdk-only' failed
make: *** [jdk-only] Error 2





--Semyon



On 4/29/2015 11:23 AM, Magnus Ihse Bursie wrote:
> On 2015-04-29 09:50, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please advise what is the source of the next issue:
>> (...libfdlibm/e_acos.obj file is really absent)
>
> Hi Semyon,
>
> Please re-run with "make LOG=debug JOBS=1" to get a better log prior 
> to the failure.
>
> /Magnus
>
>>
>>
>> ## Starting jdk
>> Importing CORBA classes.jar
>> Importing CORBA src.zip
>> Importing CORBA bin.zip
>> Importing JAXP classes.jar
>> Importing JAXP src.zip
>> Importing JAXWS src.zip
>> Importing JAXWS classes.jar
>> Importing LANGTOOLS src.zip
>> Importing LANGTOOLS classes.jar
>> Generating charsetmapping classes
>> Generating buffer classes
>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> Compiling 161 files for BUILD_TOOLS
>> Generating exceptions classes
>> genSocketOptionRegistry.c
>> Microsoft (R) Incremental Linker Version 10.00.40219.01
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> Copying and cleaning 53 properties
>> Compiling 521 properties into resource bundles
>> Creating sun/util/LocaleDataMetaInfo.java from 421 found resources.
>> Generating sun/misc/Version.java
>> Generating sun/misc/Version.java compact1
>> Generating sun/misc/Version.java compact3
>> Generating sun/misc/Version.java compact2
>> Aliases: Table size 1024 (10 bits), shift 0, max chain depth 3
>> Classes: Table size 32 (5 bits), shift 1, max chain depth 3
>> Cache: Table size 32 (5 bits), shift 1, max chain depth 3
>> Generating beaninfo
>> Generating Nimbus source files
>> [Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 
>> 11.0, 16.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0)
>> Generating HTML DTD file
>> Compiling 4 files for BUILD_BREAKITERATOR
>> [Parsed DTD html32 in 159ms]
>> Compiling 9722 files for BUILD_JDK
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> Compiling 235 files for BUILD_SECURITY
>> Compiling 2 files for BUILD_ACCESSBRIDGE_64
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> Could not start process!  Failed with error 2: The system cannot find 
>> the file specified.
>>
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
>> failed
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
>> Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> Could not start process!  Failed with error 2: The system cannot find 
>> the file specified.
>>
>> Could not start process!  Failed with error 2: The system cannot find 
>> the file specified.
>>
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
>> failed
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
>> Error 1
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
>> failed
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
>> Error 1
>> BuildJdk.gmk:70: recipe for target 'libs-only' failed
>> make[1]: *** [libs-only] Error 2
>> /home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe for 
>> target 'jdk-only' failed
>> make: *** [jdk-only] Error 2
>>
>>
>>
>



From gary.adams at oracle.com  Wed Apr 29 09:59:49 2015
From: gary.adams at oracle.com (gary.adams at oracle.com)
Date: Wed, 29 Apr 2015 05:59:49 -0400
Subject: 8u build failure win7/cygwin64
In-Reply-To: <554094ED.7080801@oracle.com>
References: <55408D30.1030806@oracle.com> <554094ED.7080801@oracle.com>
Message-ID: <5540AB95.8030209@oracle.com>

I've found that disable ccache fixes problems building e_acos ( the 
first native file in the jdk portion of the build).

On 4/29/15 4:23 AM, Magnus Ihse Bursie wrote:
> On 2015-04-29 09:50, Semyon Sadetsky wrote:
>> Hello,
>>
>> Please advise what is the source of the next issue:
>> (...libfdlibm/e_acos.obj file is really absent)
>
> Hi Semyon,
>
> Please re-run with "make LOG=debug JOBS=1" to get a better log prior 
> to the failure.
>
> /Magnus
>
>>
>>
>> ## Starting jdk
>> Importing CORBA classes.jar
>> Importing CORBA src.zip
>> Importing CORBA bin.zip
>> Importing JAXP classes.jar
>> Importing JAXP src.zip
>> Importing JAXWS src.zip
>> Importing JAXWS classes.jar
>> Importing LANGTOOLS src.zip
>> Importing LANGTOOLS classes.jar
>> Generating charsetmapping classes
>> Generating buffer classes
>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> Compiling 161 files for BUILD_TOOLS
>> Generating exceptions classes
>> genSocketOptionRegistry.c
>> Microsoft (R) Incremental Linker Version 10.00.40219.01
>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> Copying and cleaning 53 properties
>> Compiling 521 properties into resource bundles
>> Creating sun/util/LocaleDataMetaInfo.java from 421 found resources.
>> Generating sun/misc/Version.java
>> Generating sun/misc/Version.java compact1
>> Generating sun/misc/Version.java compact3
>> Generating sun/misc/Version.java compact2
>> Aliases: Table size 1024 (10 bits), shift 0, max chain depth 3
>> Classes: Table size 32 (5 bits), shift 1, max chain depth 3
>> Cache: Table size 32 (5 bits), shift 1, max chain depth 3
>> Generating beaninfo
>> Generating Nimbus source files
>> [Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 
>> 11.0, 16.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>> 14.0, 15.0)
>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 24.0, 
>> 25.0)
>> [Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0)
>> Generating HTML DTD file
>> Compiling 4 files for BUILD_BREAKITERATOR
>> [Parsed DTD html32 in 159ms]
>> Compiling 9722 files for BUILD_JDK
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> Note: Some input files use unchecked or unsafe operations.
>> Note: Recompile with -Xlint:unchecked for details.
>> Compiling 235 files for BUILD_SECURITY
>> Compiling 2 files for BUILD_ACCESSBRIDGE_64
>> Note: Some input files use or override a deprecated API.
>> Note: Recompile with -Xlint:deprecation for details.
>> Could not start process!  Failed with error 2: The system cannot find 
>> the file specified.
>>
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
>> failed
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
>> Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> Could not start process!  Failed with error 2: The system cannot find 
>> the file specified.
>>
>> Could not start process!  Failed with error 2: The system cannot find 
>> the file specified.
>>
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
>> failed
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
>> Error 1
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
>> failed
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
>> Error 1
>> BuildJdk.gmk:70: recipe for target 'libs-only' failed
>> make[1]: *** [libs-only] Error 2
>> /home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe for 
>> target 'jdk-only' failed
>> make: *** [jdk-only] Error 2
>>
>>
>>
>



From semyon.sadetsky at oracle.com  Wed Apr 29 10:46:21 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Wed, 29 Apr 2015 13:46:21 +0300
Subject: 8u build failure win7/cygwin64
In-Reply-To: <5540AB95.8030209@oracle.com>
References: <55408D30.1030806@oracle.com> <554094ED.7080801@oracle.com>
	<5540AB95.8030209@oracle.com>
Message-ID: <5540B67D.9050207@oracle.com>

I set CCACHE_DISABLE=1 and it still fails:

make[2]: *** 
[/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
Error 1
make[2]: *** Waiting for unfinished jobs....
make[2]: *** 
[/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atanh.obj] 
Error 1
lib/CoreLibraries.gmk:37: recipe for target 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
failed
lib/CoreLibraries.gmk:37: recipe for target 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atanh.obj' 
failed
make[2]: *** 
[/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
Error 1
lib/CoreLibraries.gmk:37: recipe for target 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
failed
lib/CoreLibraries.gmk:37: recipe for target 
'/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
failed
make[2]: *** 
[/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
Error 1
BuildJdk.gmk:70: recipe for target 'libs-only' failed
make[1]: *** [libs-only] Error 2
/home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe for 
target 'jdk-only' failed

--Semyon


On 4/29/2015 12:59 PM, gary.adams at oracle.com wrote:
> I've found that disable ccache fixes problems building e_acos ( the 
> first native file in the jdk portion of the build).
>
> On 4/29/15 4:23 AM, Magnus Ihse Bursie wrote:
>> On 2015-04-29 09:50, Semyon Sadetsky wrote:
>>> Hello,
>>>
>>> Please advise what is the source of the next issue:
>>> (...libfdlibm/e_acos.obj file is really absent)
>>
>> Hi Semyon,
>>
>> Please re-run with "make LOG=debug JOBS=1" to get a better log prior 
>> to the failure.
>>
>> /Magnus
>>
>>>
>>>
>>> ## Starting jdk
>>> Importing CORBA classes.jar
>>> Importing CORBA src.zip
>>> Importing CORBA bin.zip
>>> Importing JAXP classes.jar
>>> Importing JAXP src.zip
>>> Importing JAXWS src.zip
>>> Importing JAXWS classes.jar
>>> Importing LANGTOOLS src.zip
>>> Importing LANGTOOLS classes.jar
>>> Generating charsetmapping classes
>>> Generating buffer classes
>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>
>>> Compiling 161 files for BUILD_TOOLS
>>> Generating exceptions classes
>>> genSocketOptionRegistry.c
>>> Microsoft (R) Incremental Linker Version 10.00.40219.01
>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>
>>> Note: Some input files use unchecked or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> Copying and cleaning 53 properties
>>> Compiling 521 properties into resource bundles
>>> Creating sun/util/LocaleDataMetaInfo.java from 421 found resources.
>>> Generating sun/misc/Version.java
>>> Generating sun/misc/Version.java compact1
>>> Generating sun/misc/Version.java compact3
>>> Generating sun/misc/Version.java compact2
>>> Aliases: Table size 1024 (10 bits), shift 0, max chain depth 3
>>> Classes: Table size 32 (5 bits), shift 1, max chain depth 3
>>> Cache: Table size 32 (5 bits), shift 1, max chain depth 3
>>> Generating beaninfo
>>> Generating Nimbus source files
>>> [Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 
>>> 11.0, 16.0)
>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>> 24.0, 25.0)
>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>> 14.0, 15.0)
>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>> 24.0, 25.0)
>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>> 14.0, 15.0)
>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>> 24.0, 25.0)
>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>> 24.0, 25.0)
>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>> 14.0, 15.0)
>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>> 24.0, 25.0)
>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>> 14.0, 15.0)
>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>> 24.0, 25.0)
>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>> 24.0, 25.0)
>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>> 14.0, 15.0)
>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>> 24.0, 25.0)
>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>> 14.0, 15.0)
>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>> 24.0, 25.0)
>>> [Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0)
>>> Generating HTML DTD file
>>> Compiling 4 files for BUILD_BREAKITERATOR
>>> [Parsed DTD html32 in 159ms]
>>> Compiling 9722 files for BUILD_JDK
>>> Note: Some input files use or override a deprecated API.
>>> Note: Recompile with -Xlint:deprecation for details.
>>> Note: Some input files use unchecked or unsafe operations.
>>> Note: Recompile with -Xlint:unchecked for details.
>>> Compiling 235 files for BUILD_SECURITY
>>> Compiling 2 files for BUILD_ACCESSBRIDGE_64
>>> Note: Some input files use or override a deprecated API.
>>> Note: Recompile with -Xlint:deprecation for details.
>>> Could not start process!  Failed with error 2: The system cannot 
>>> find the file specified.
>>>
>>> lib/CoreLibraries.gmk:37: recipe for target 
>>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
>>> failed
>>> make[2]: *** 
>>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
>>> Error 1
>>> make[2]: *** Waiting for unfinished jobs....
>>> Could not start process!  Failed with error 2: The system cannot 
>>> find the file specified.
>>>
>>> Could not start process!  Failed with error 2: The system cannot 
>>> find the file specified.
>>>
>>> lib/CoreLibraries.gmk:37: recipe for target 
>>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
>>> failed
>>> make[2]: *** 
>>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
>>> Error 1
>>> lib/CoreLibraries.gmk:37: recipe for target 
>>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
>>> failed
>>> make[2]: *** 
>>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
>>> Error 1
>>> BuildJdk.gmk:70: recipe for target 'libs-only' failed
>>> make[1]: *** [libs-only] Error 2
>>> /home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe 
>>> for target 'jdk-only' failed
>>> make: *** [jdk-only] Error 2
>>>
>>>
>>>
>>
>



From erik.joelsson at oracle.com  Wed Apr 29 15:59:06 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 29 Apr 2015 08:59:06 -0700
Subject: 8u build failure win7/cygwin64
In-Reply-To: <5540B67D.9050207@oracle.com>
References: <55408D30.1030806@oracle.com> <554094ED.7080801@oracle.com>
	<5540AB95.8030209@oracle.com> <5540B67D.9050207@oracle.com>
Message-ID: <5540FFCA.6040802@oracle.com>

Hello Semyon,

To disable ccache explicitly, you need to run add --disable-ccache to 
the configure command line. I thought we had fixed this, but perhaps we 
still pick up ccache automatically in 8u even if it's not supported. 
Anyway, ccache is certainly not compatible with Visual Studio.

/Erik

On 2015-04-29 03:46, Semyon Sadetsky wrote:
> I set CCACHE_DISABLE=1 and it still fails:
>
> make[2]: *** 
> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
> Error 1
> make[2]: *** Waiting for unfinished jobs....
> make[2]: *** 
> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atanh.obj] 
> Error 1
> lib/CoreLibraries.gmk:37: recipe for target 
> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
> failed
> lib/CoreLibraries.gmk:37: recipe for target 
> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atanh.obj' 
> failed
> make[2]: *** 
> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
> Error 1
> lib/CoreLibraries.gmk:37: recipe for target 
> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
> failed
> lib/CoreLibraries.gmk:37: recipe for target 
> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
> failed
> make[2]: *** 
> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
> Error 1
> BuildJdk.gmk:70: recipe for target 'libs-only' failed
> make[1]: *** [libs-only] Error 2
> /home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe for 
> target 'jdk-only' failed
>
> --Semyon
>
>
> On 4/29/2015 12:59 PM, gary.adams at oracle.com wrote:
>> I've found that disable ccache fixes problems building e_acos ( the 
>> first native file in the jdk portion of the build).
>>
>> On 4/29/15 4:23 AM, Magnus Ihse Bursie wrote:
>>> On 2015-04-29 09:50, Semyon Sadetsky wrote:
>>>> Hello,
>>>>
>>>> Please advise what is the source of the next issue:
>>>> (...libfdlibm/e_acos.obj file is really absent)
>>>
>>> Hi Semyon,
>>>
>>> Please re-run with "make LOG=debug JOBS=1" to get a better log prior 
>>> to the failure.
>>>
>>> /Magnus
>>>
>>>>
>>>>
>>>> ## Starting jdk
>>>> Importing CORBA classes.jar
>>>> Importing CORBA src.zip
>>>> Importing CORBA bin.zip
>>>> Importing JAXP classes.jar
>>>> Importing JAXP src.zip
>>>> Importing JAXWS src.zip
>>>> Importing JAXWS classes.jar
>>>> Importing LANGTOOLS src.zip
>>>> Importing LANGTOOLS classes.jar
>>>> Generating charsetmapping classes
>>>> Generating buffer classes
>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for x64
>>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>>
>>>> Compiling 161 files for BUILD_TOOLS
>>>> Generating exceptions classes
>>>> genSocketOptionRegistry.c
>>>> Microsoft (R) Incremental Linker Version 10.00.40219.01
>>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>>
>>>> Note: Some input files use unchecked or unsafe operations.
>>>> Note: Recompile with -Xlint:unchecked for details.
>>>> Copying and cleaning 53 properties
>>>> Compiling 521 properties into resource bundles
>>>> Creating sun/util/LocaleDataMetaInfo.java from 421 found resources.
>>>> Generating sun/misc/Version.java
>>>> Generating sun/misc/Version.java compact1
>>>> Generating sun/misc/Version.java compact3
>>>> Generating sun/misc/Version.java compact2
>>>> Aliases: Table size 1024 (10 bits), shift 0, max chain depth 3
>>>> Classes: Table size 32 (5 bits), shift 1, max chain depth 3
>>>> Cache: Table size 32 (5 bits), shift 1, max chain depth 3
>>>> Generating beaninfo
>>>> Generating Nimbus source files
>>>> [Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 
>>>> 11.0, 16.0)
>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>> 24.0, 25.0)
>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>> 14.0, 15.0)
>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>> 24.0, 25.0)
>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>> 14.0, 15.0)
>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>> 24.0, 25.0)
>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>> 24.0, 25.0)
>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>> 14.0, 15.0)
>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>> 24.0, 25.0)
>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>> 14.0, 15.0)
>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>> 24.0, 25.0)
>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>> 24.0, 25.0)
>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>> 14.0, 15.0)
>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>> 24.0, 25.0)
>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>> 14.0, 15.0)
>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>> 24.0, 25.0)
>>>> [Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0)
>>>> Generating HTML DTD file
>>>> Compiling 4 files for BUILD_BREAKITERATOR
>>>> [Parsed DTD html32 in 159ms]
>>>> Compiling 9722 files for BUILD_JDK
>>>> Note: Some input files use or override a deprecated API.
>>>> Note: Recompile with -Xlint:deprecation for details.
>>>> Note: Some input files use unchecked or unsafe operations.
>>>> Note: Recompile with -Xlint:unchecked for details.
>>>> Compiling 235 files for BUILD_SECURITY
>>>> Compiling 2 files for BUILD_ACCESSBRIDGE_64
>>>> Note: Some input files use or override a deprecated API.
>>>> Note: Recompile with -Xlint:deprecation for details.
>>>> Could not start process!  Failed with error 2: The system cannot 
>>>> find the file specified.
>>>>
>>>> lib/CoreLibraries.gmk:37: recipe for target 
>>>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
>>>> failed
>>>> make[2]: *** 
>>>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
>>>> Error 1
>>>> make[2]: *** Waiting for unfinished jobs....
>>>> Could not start process!  Failed with error 2: The system cannot 
>>>> find the file specified.
>>>>
>>>> Could not start process!  Failed with error 2: The system cannot 
>>>> find the file specified.
>>>>
>>>> lib/CoreLibraries.gmk:37: recipe for target 
>>>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
>>>> failed
>>>> make[2]: *** 
>>>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
>>>> Error 1
>>>> lib/CoreLibraries.gmk:37: recipe for target 
>>>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
>>>> failed
>>>> make[2]: *** 
>>>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
>>>> Error 1
>>>> BuildJdk.gmk:70: recipe for target 'libs-only' failed
>>>> make[1]: *** [libs-only] Error 2
>>>> /home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe 
>>>> for target 'jdk-only' failed
>>>> make: *** [jdk-only] Error 2
>>>>
>>>>
>>>>
>>>
>>
>



From Sergey.Bylokhov at oracle.com  Wed Apr 29 17:46:55 2015
From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov)
Date: Wed, 29 Apr 2015 20:46:55 +0300
Subject: cygwin 2.0 is unsupported
Message-ID: <5541190F.4060901@oracle.com>

Hello.
Is that known issue that current version of cygwin 2.0 [1] is unsupported?

configure: Your cygwin is too old. You are running 2.0.0(0.287/5/3), but 
at least cygwin 1.7 is required. Please upgrade.
configure: error: Cannot continue

[1] https://cygwin.com/ml/cygwin-announce/2015-04/msg00046.html

-- 
Best regards, Sergey.



From erik.joelsson at oracle.com  Wed Apr 29 20:20:01 2015
From: erik.joelsson at oracle.com (Erik Joelsson)
Date: Wed, 29 Apr 2015 13:20:01 -0700
Subject: cygwin 2.0 is unsupported
In-Reply-To: <5541190F.4060901@oracle.com>
References: <5541190F.4060901@oracle.com>
Message-ID: <55413CF1.8050203@oracle.com>

Hello Sergey,

No, that wasn't known. I wasn't aware that Cygwin had bumped its version 
to 2.0. Thanks for pointing that out.

Filed: https://bugs.openjdk.java.net/browse/JDK-8079087

/Erik

On 2015-04-29 10:46, Sergey Bylokhov wrote:
> Hello.
> Is that known issue that current version of cygwin 2.0 [1] is 
> unsupported?
>
> configure: Your cygwin is too old. You are running 2.0.0(0.287/5/3), 
> but at least cygwin 1.7 is required. Please upgrade.
> configure: error: Cannot continue
>
> [1] https://cygwin.com/ml/cygwin-announce/2015-04/msg00046.html
>



From david.holmes at oracle.com  Thu Apr 30 05:26:34 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Apr 2015 15:26:34 +1000
Subject: aarch64: jdk9: 8078245: fails to build from source
In-Reply-To: <1430304750.8394.56.camel@mylittlepony.linaroharston>
References: <1429607797.4116.11.camel@mylittlepony.linaroharston>	
	<5539EC8E.1060507@oracle.com>
	<1430304750.8394.56.camel@mylittlepony.linaroharston>
Message-ID: <5541BD0A.3090305@oracle.com>

Hi Nevill,

Just realized this was sent to hotspot-dev (attempting bcc) but is not a 
hotspot issue. With your new approach this is a build issue so cc'ing 
build-dev.

The new approach seems better to me but build folk need to confirm the 
placement.

Thanks,
David

On 29/04/2015 8:52 PM, Edward Nevill wrote:
> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote:
>> Hi Ed,
>>
>> On 21/04/2015 7:16 PM, Edward Nevill wrote:
>>> Hi,
>>>
>>> The current jdk9 tip fails to build from source on aarch64 with the following error message
>>>
>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o: In function `png_init_filter_functions':
>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947: undefined reference to `png_init_filter_functions_neon'
>>> collect2: error: ld returned 1 exit status
>>>
>>> The following webrev gets it building again.
>>>
>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/
>>
>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm
>> also wondering how we would get __ARM_NEON defined but not __arm__?
>
> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon is specified. Since this is not specified as part of the OpenJDK build the symbol is not defined and the build succeeds.
>
> On aarch64 the symbol __ARM_NEON is always defined (the theory being that aarch64 always supports Neon). Personally I think this is borken as it causes builds to fail (and not just OpenJDK, several other projects have had the same build failure - try googling the above error message). But we are stuck with gcc as it is.
>
> However, I don't like the above fix because it not only modifies the jdk, it modifies an external component which is pulled into jdk, which means every time a new revision of linpng is pulled in, the patch will have to be applied again.
>
> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0 in the build (only if aarch64).
>
> The failing code in pngpriv.h reads
>
> #ifndef PNG_ARM_NEON_OPT
>
> ...
>
> #  if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \
>     defined(PNG_ALIGNED_MEMORY_SUPPORTED)
> #     define PNG_ARM_NEON_OPT 2
> #  else
> #     define PNG_ARM_NEON_OPT 0
> #  endif
> #endif
>
> So, if we just predefine PNG_ARM_NEON=0 in the build this will have the same effect as adding defined(__arm__) or !defined(__aarch64__) above.
>
> The following patch webrev does this:-
>
> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/
>
> If you are happy with this and if I could have another reviewer I will push this.
>
> All the best,
> Ed.
>
>


From david.holmes at oracle.com  Thu Apr 30 05:34:22 2015
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 30 Apr 2015 15:34:22 +1000
Subject: aarch64: jdk9: 8078245: fails to build from source
In-Reply-To: <5541BD0A.3090305@oracle.com>
References: <1429607797.4116.11.camel@mylittlepony.linaroharston>		<5539EC8E.1060507@oracle.com>	<1430304750.8394.56.camel@mylittlepony.linaroharston>
	<5541BD0A.3090305@oracle.com>
Message-ID: <5541BEDE.6020501@oracle.com>

On 30/04/2015 3:26 PM, David Holmes wrote:
> Hi Nevill,

Sorry Ed!

David

> Just realized this was sent to hotspot-dev (attempting bcc) but is not a
> hotspot issue. With your new approach this is a build issue so cc'ing
> build-dev.
>
> The new approach seems better to me but build folk need to confirm the
> placement.
>
> Thanks,
> David
>
> On 29/04/2015 8:52 PM, Edward Nevill wrote:
>> On Fri, 2015-04-24 at 17:11 +1000, David Holmes wrote:
>>> Hi Ed,
>>>
>>> On 21/04/2015 7:16 PM, Edward Nevill wrote:
>>>> Hi,
>>>>
>>>> The current jdk9 tip fails to build from source on aarch64 with the
>>>> following error message
>>>>
>>>> /home/ed/build/1504/dev/build/linux-aarch64-normal-server-release/support/native/java.desktop/libsplashscreen/pngrutil.o:
>>>> In function `png_init_filter_functions':
>>>> /home/ed/build/1504/dev/jdk/src/java.desktop/share/native/libsplashscreen/libpng/pngrutil.c:3947:
>>>> undefined reference to `png_init_filter_functions_neon'
>>>> collect2: error: ld returned 1 exit status
>>>>
>>>> The following webrev gets it building again.
>>>>
>>>> http://cr.openjdk.java.net/~enevill/8078245/webrev.00/
>>>
>>> Shouldn't the guard be Aarch64 specific rather than just __arm__ ? I'm
>>> also wondering how we would get __ARM_NEON defined but not __arm__?
>>
>> On arm 32 bit gcc defines the symbol __ARM_NEON if the flag -mfpu=neon
>> is specified. Since this is not specified as part of the OpenJDK build
>> the symbol is not defined and the build succeeds.
>>
>> On aarch64 the symbol __ARM_NEON is always defined (the theory being
>> that aarch64 always supports Neon). Personally I think this is borken
>> as it causes builds to fail (and not just OpenJDK, several other
>> projects have had the same build failure - try googling the above
>> error message). But we are stuck with gcc as it is.
>>
>> However, I don't like the above fix because it not only modifies the
>> jdk, it modifies an external component which is pulled into jdk, which
>> means every time a new revision of linpng is pulled in, the patch will
>> have to be applied again.
>>
>> A better approach I think is to define the symbol PNG_ARM_NEON_OPT=0
>> in the build (only if aarch64).
>>
>> The failing code in pngpriv.h reads
>>
>> #ifndef PNG_ARM_NEON_OPT
>>
>> ...
>>
>> #  if (defined(__ARM_NEON__) || defined(__ARM_NEON)) && \
>>     defined(PNG_ALIGNED_MEMORY_SUPPORTED)
>> #     define PNG_ARM_NEON_OPT 2
>> #  else
>> #     define PNG_ARM_NEON_OPT 0
>> #  endif
>> #endif
>>
>> So, if we just predefine PNG_ARM_NEON=0 in the build this will have
>> the same effect as adding defined(__arm__) or !defined(__aarch64__)
>> above.
>>
>> The following patch webrev does this:-
>>
>> http://cr.openjdk.java.net/~enevill/8078245/webrev.01/
>>
>> If you are happy with this and if I could have another reviewer I will
>> push this.
>>
>> All the best,
>> Ed.
>>
>>


From semyon.sadetsky at oracle.com  Thu Apr 30 06:29:51 2015
From: semyon.sadetsky at oracle.com (Semyon Sadetsky)
Date: Thu, 30 Apr 2015 09:29:51 +0300
Subject: 8u build failure win7/cygwin64
In-Reply-To: <5540FFCA.6040802@oracle.com>
References: <55408D30.1030806@oracle.com> <554094ED.7080801@oracle.com>
	<5540AB95.8030209@oracle.com> <5540B67D.9050207@oracle.com>
	<5540FFCA.6040802@oracle.com>
Message-ID: <5541CBDF.30909@oracle.com>

Thank you Erik, the last option has resolved my issue.

--Semyon


On 4/29/2015 6:59 PM, Erik Joelsson wrote:
> Hello Semyon,
>
> To disable ccache explicitly, you need to run add --disable-ccache to 
> the configure command line. I thought we had fixed this, but perhaps 
> we still pick up ccache automatically in 8u even if it's not 
> supported. Anyway, ccache is certainly not compatible with Visual Studio.
>
> /Erik
>
> On 2015-04-29 03:46, Semyon Sadetsky wrote:
>> I set CCACHE_DISABLE=1 and it still fails:
>>
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
>> Error 1
>> make[2]: *** Waiting for unfinished jobs....
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atanh.obj] 
>> Error 1
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
>> failed
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atanh.obj' 
>> failed
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
>> Error 1
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
>> failed
>> lib/CoreLibraries.gmk:37: recipe for target 
>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
>> failed
>> make[2]: *** 
>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
>> Error 1
>> BuildJdk.gmk:70: recipe for target 'libs-only' failed
>> make[1]: *** [libs-only] Error 2
>> /home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe for 
>> target 'jdk-only' failed
>>
>> --Semyon
>>
>>
>> On 4/29/2015 12:59 PM, gary.adams at oracle.com wrote:
>>> I've found that disable ccache fixes problems building e_acos ( the 
>>> first native file in the jdk portion of the build).
>>>
>>> On 4/29/15 4:23 AM, Magnus Ihse Bursie wrote:
>>>> On 2015-04-29 09:50, Semyon Sadetsky wrote:
>>>>> Hello,
>>>>>
>>>>> Please advise what is the source of the next issue:
>>>>> (...libfdlibm/e_acos.obj file is really absent)
>>>>
>>>> Hi Semyon,
>>>>
>>>> Please re-run with "make LOG=debug JOBS=1" to get a better log 
>>>> prior to the failure.
>>>>
>>>> /Magnus
>>>>
>>>>>
>>>>>
>>>>> ## Starting jdk
>>>>> Importing CORBA classes.jar
>>>>> Importing CORBA src.zip
>>>>> Importing CORBA bin.zip
>>>>> Importing JAXP classes.jar
>>>>> Importing JAXP src.zip
>>>>> Importing JAXWS src.zip
>>>>> Importing JAXWS classes.jar
>>>>> Importing LANGTOOLS src.zip
>>>>> Importing LANGTOOLS classes.jar
>>>>> Generating charsetmapping classes
>>>>> Generating buffer classes
>>>>> Microsoft (R) C/C++ Optimizing Compiler Version 16.00.40219.01 for 
>>>>> x64
>>>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>>>
>>>>> Compiling 161 files for BUILD_TOOLS
>>>>> Generating exceptions classes
>>>>> genSocketOptionRegistry.c
>>>>> Microsoft (R) Incremental Linker Version 10.00.40219.01
>>>>> Copyright (C) Microsoft Corporation.  All rights reserved.
>>>>>
>>>>> Note: Some input files use unchecked or unsafe operations.
>>>>> Note: Recompile with -Xlint:unchecked for details.
>>>>> Copying and cleaning 53 properties
>>>>> Compiling 521 properties into resource bundles
>>>>> Creating sun/util/LocaleDataMetaInfo.java from 421 found resources.
>>>>> Generating sun/misc/Version.java
>>>>> Generating sun/misc/Version.java compact1
>>>>> Generating sun/misc/Version.java compact3
>>>>> Generating sun/misc/Version.java compact2
>>>>> Aliases: Table size 1024 (10 bits), shift 0, max chain depth 3
>>>>> Classes: Table size 32 (5 bits), shift 1, max chain depth 3
>>>>> Cache: Table size 32 (5 bits), shift 1, max chain depth 3
>>>>> Generating beaninfo
>>>>> Generating Nimbus source files
>>>>> [Error] encoded value was less than 0: encode(-8.326673E-17, 5.0, 
>>>>> 11.0, 16.0)
>>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>>> 24.0, 25.0)
>>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>>> 14.0, 15.0)
>>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>>> 24.0, 25.0)
>>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>>> 14.0, 15.0)
>>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>>> 24.0, 25.0)
>>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>>> 24.0, 25.0)
>>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>>> 14.0, 15.0)
>>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>>> 24.0, 25.0)
>>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>>> 14.0, 15.0)
>>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>>> 24.0, 25.0)
>>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>>> 24.0, 25.0)
>>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>>> 14.0, 15.0)
>>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>>> 24.0, 25.0)
>>>>> [Error] encoded value was greater than 3: encode(15.029411, 1.0, 
>>>>> 14.0, 15.0)
>>>>> [Error] encoded value was less than 0: encode(-0.05882353, 1.0, 
>>>>> 24.0, 25.0)
>>>>> [Error] Encountered Infinity: encode(-0.00877193, 0.0, 7.0, 7.0)
>>>>> Generating HTML DTD file
>>>>> Compiling 4 files for BUILD_BREAKITERATOR
>>>>> [Parsed DTD html32 in 159ms]
>>>>> Compiling 9722 files for BUILD_JDK
>>>>> Note: Some input files use or override a deprecated API.
>>>>> Note: Recompile with -Xlint:deprecation for details.
>>>>> Note: Some input files use unchecked or unsafe operations.
>>>>> Note: Recompile with -Xlint:unchecked for details.
>>>>> Compiling 235 files for BUILD_SECURITY
>>>>> Compiling 2 files for BUILD_ACCESSBRIDGE_64
>>>>> Note: Some input files use or override a deprecated API.
>>>>> Note: Recompile with -Xlint:deprecation for details.
>>>>> Could not start process!  Failed with error 2: The system cannot 
>>>>> find the file specified.
>>>>>
>>>>> lib/CoreLibraries.gmk:37: recipe for target 
>>>>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj' 
>>>>> failed
>>>>> make[2]: *** 
>>>>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_acos.obj] 
>>>>> Error 1
>>>>> make[2]: *** Waiting for unfinished jobs....
>>>>> Could not start process!  Failed with error 2: The system cannot 
>>>>> find the file specified.
>>>>>
>>>>> Could not start process!  Failed with error 2: The system cannot 
>>>>> find the file specified.
>>>>>
>>>>> lib/CoreLibraries.gmk:37: recipe for target 
>>>>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj' 
>>>>> failed
>>>>> make[2]: *** 
>>>>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_atan2.obj] 
>>>>> Error 1
>>>>> lib/CoreLibraries.gmk:37: recipe for target 
>>>>> '/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj' 
>>>>> failed
>>>>> make[2]: *** 
>>>>> [/cygdrive/c/cygwin64/home/ssadetsk/projects/jdk8/jdk8u-dev/build/windows-x86_64-normal-server-fastdebug/jdk/objs/libfdlibm/e_asin.obj] 
>>>>> Error 1
>>>>> BuildJdk.gmk:70: recipe for target 'libs-only' failed
>>>>> make[1]: *** [libs-only] Error 2
>>>>> /home/ssadetsk/projects/jdk8/jdk8u-dev//make/Main.gmk:115: recipe 
>>>>> for target 'jdk-only' failed
>>>>> make: *** [jdk-only] Error 2
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>



From geekinthelead at gmail.com  Sun Apr 26 20:44:36 2015
From: geekinthelead at gmail.com (Kingsley Osime)
Date: Sun, 26 Apr 2015 20:44:36 -0000
Subject: make[2]: *** No rule to make target..'/home/*/...needed by jtreg_tests
Message-ID: <CAGQ2jNBUvpzgBjeht62Zp=Yaxafkc0Z6HY3-tTpW2L=+6aG_Zg@mail.gmail.com>

I am trying to build openjdk and everything seems to have gone ok except
when I test i get make[2]: *** No rule to make target
`/home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/images/j2sdk-image',
needed by `jtreg_tests'.

I also notice my build does not produce the j2sdk-image directory even
after several tries and can not understand why?

Perhaps someone can cast an expert eye over my build log ?

Thanks

Compiling 5 files for BUILD_GENMODULESLIST
Compiling 8 files for BUILD_TOOLS_LANGTOOLS
Compiling 20 properties into resource bundles for jdk.compiler
Parsing 1 properties into enum-like class for jdk.compiler
Compiling 5 properties into resource bundles for jdk.dev
Compiling 10 properties into resource bundles for jdk.javadoc
Compiling 821 files for BUILD_INTERIM_LANGTOOLS
Creating buildtools/interim_langtools.jar
Compiling 23 files for BUILD_INTERIM_JIMAGE
Compiling 161 files for BUILD_TOOLS_JDK
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Creating sun/util/locale/provider/EnLocaleDataMetaInfo.java from 424 found
resources.
Generating sun/misc/Version.java
Creating genSocketOptionRegistry from 1 file(s)
Creating genUnixConstants from 1 file(s)
Generating buffer classes
Generating exceptions classes
Compiling 11 properties into resource bundles for java.base
Compiling 22 properties into resource bundles for java.base
Compiling 2752 files for java.base
Compiling 1814 files for java.xml
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 13 files for java.prefs
Compiling 131 files for jdk.charsets
Compiling 16 files for java.datatransfer
Compiling 11 properties into resource bundles for java.logging
Compiling 32 files for java.logging
Generating icon classes
Generating X11 wrapper (64-bit version)
Verifying
/home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/support/gensrc/java.desktop/_x11wrappers/sizes.64.verification.tmp
to
/home/hellofadude/dev/openjdk/jdk9/build/linux-x86_64-normal-server-release/support/gensrc/java.desktop/_x11wrappers/sizes.64
Generating beaninfo
Generating Nimbus source files
Compiling 100 properties into resource bundles for java.desktop
Compiling 2755 files for java.desktop
Compiling 24 files for java.activation
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 5 files for java.annotations.common
Compiling 4 files for BUILD_BREAKITERATOR
Generating blacklisted certs
Creating support/jce/policy/unlimited/US_export_policy.jar
Creating support/jce/policy/limited/local_policy.jar
Creating support/jce/policy/unlimited/local_policy.jar
Generating java.security
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
All done.
Generating linux_amd64_docs/jvmti.html
Creating libverify.so from 2 file(s)
Creating libjava.so from 60 file(s)
Creating libfdlibm.a from 62 file(s)
Creating libzip.so from 21 file(s)
Creating libjli.so from 15 file(s)
Creating libnet.so from 21 file(s)
Creating libnio.so from 25 file(s)
Creating java from 1 file(s)
Creating keytool from 1 file(s)
Creating jexec from 1 file(s)
Compiling 114 files for java.compiler
Compiling 141 files for BUILD_IDLJ
Note:
/home/hellofadude/dev/openjdk/jdk9/corba/src/java.corba/share/classes/com/sun/tools/corba/se/idl/som/idlemit/MetaPragma.java
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 6 files for BUILD_TOOLS_CORBA
Compiling 133 files for java.rmi
Compiling 3 files for java.transaction
Compiling 29 files for java.security.sasl
Compiling 191 files for java.naming
Compiling 1476 files for java.corba
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Creating idlj from 1 file(s)
Creating orbd from 1 file(s)
Creating servertool from 1 file(s)
Creating tnameserv from 1 file(s)
Generating HTML DTD file
[Parsed DTD html32 in 897ms]
Creating libmlib_image.so from 55 file(s)
Creating libawt.so from 72 file(s)
Creating libawt_xawt.so from 53 file(s)
/home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/common/awt/awt_Font.c:
In function ?awtJNI_GetFontData?:
/home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/common/awt/awt_Font.c:643:23:
warning: comparison between pointer and integer [enabled by default]
             if (xfont == (Font) NULL || xfont->ascent < 0) {
                       ^
/home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:69:0:
warning: "MIN" redefined [enabled by default]
 #define MIN(a, b)  (((a) < (b)) ? (a) : (b))
 ^
In file included from
/home/hellofadude/dev/openjdk/jdk9/jdk/src/java.base/unix/native/include/jvm_md.h:35:0,
                 from
/home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/unix/native/libawt_xawt/awt/gtk2_interface.c:33:
/usr/include/x86_64-linux-gnu/sys/param.h:99:0: note: this is the location
of the previous definition
 #define MIN(a,b) (((a)<(b))?(a):(b))
 ^
Creating liblcms.so from 26 file(s)
Creating libjavajpeg.so from 46 file(s)
Creating libawt_headless.so from 26 file(s)
Creating libfontmanager.so from 94 file(s)
cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++
but not for C [enabled by default]
cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid
for C++/ObjC++ but not for C [enabled by default]
cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++
but not for C [enabled by default]
cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid
for C++/ObjC++ but not for C [enabled by default]
cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++
but not for C [enabled by default]
cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid
for C++/ObjC++ but not for C [enabled by default]
cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++
but not for C [enabled by default]
cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid
for C++/ObjC++ but not for C [enabled by default]
cc1: warning: command line option ?-Wno-reorder? is valid for C++/ObjC++
but not for C [enabled by default]
cc1: warning: command line option ?-Wno-delete-non-virtual-dtor? is valid
for C++/ObjC++ but not for C [enabled by default]
/home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/share/native/libfontmanager/sunFont.c:
In function ?freeLayoutTableCache?:
/home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/share/native/libfontmanager/sunFont.c:357:7:
warning: passing argument 1 of ?free? discards ?const? qualifier from
pointer target type [enabled by default]
       if(ltc->entries[i].ptr) free (ltc->entries[i].ptr);
       ^
In file included from
/home/hellofadude/dev/openjdk/jdk9/jdk/src/java.desktop/share/native/libfontmanager/sunFont.c:26:0:
/usr/include/stdlib.h:483:13: note: expected ?void *? but argument is of
type ?const void *?
 extern void free (void *__ptr) __THROW;
             ^
Creating libjawt.so from 1 file(s)
Creating libsplashscreen.so from 84 file(s)
Creating libjsound.so from 2 file(s)
Creating libjsoundalsa.so from 17 file(s)
Creating appletviewer from 1 file(s)
Compiling 7 files for java.instrument
Creating libinstrument.so from 12 file(s)
Compiling 11 properties into resource bundles for java.management
Compiling 393 files for java.management
Compiling 1688 files for BUILD_INTERIM_CORBA
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Creating buildtools/interim_corba.jar
Compiling 198 files for BUILD_INTERIM_RMIC
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and
static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and
static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
Creating libmanagement.so from 16 file(s)
Creating libprefs.so from 1 file(s)
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and
static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and
static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
Creating rmid from 1 file(s)
Creating rmiregistry from 1 file(s)
Compiling 13 files for java.scripting
Creating jrunscript from 1 file(s)
Compiling 211 files for java.security.jgss
Creating libj2gss.so from 3 file(s)
Compiling 20 files for java.smartcardio
Creating libj2pcsc.so from 2 file(s)
Compiling 72 files for java.sql
Compiling 50 files for java.sql.rowset
Compiling 745 files for java.xml.bind
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 281 files for java.xml.crypto
Compiling 43 files for jdk.httpserver
Compiling 1224 files for java.xml.ws
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 17 files for jdk.accessibility
Compiling 68 files for jdk.jvmstat
Compiling 14 files for jdk.attach
Creating libattach.so from 1 file(s)
Compiling 442 files for jdk.compiler
Creating javac from 1 file(s)
Creating javah from 1 file(s)
Creating javap from 1 file(s)
Creating serialver from 1 file(s)
Compiling 8 files for jdk.crypto.ec
Creating libsunec.so from 28 file(s)
Compiling 66 files for jdk.crypto.pkcs11
Creating libj2pkcs11.so from 14 file(s)
Compiling 1 properties into resource bundles for jdk.dev
Compiling 90 files for jdk.dev
Compiling 1 files for jdk.hprof.agent
Compiling 11 properties into resource bundles for jdk.jartool
Compiling 25 files for jdk.jartool
Compiling 252 files for jdk.javadoc
Compiling 36 files for jdk.jcmd
Compiling 63 files for jdk.jconsole
Compiling 3 properties into resource bundles for jdk.jdi
Compiling 246 files for jdk.jdi
Creating sun/util/resources/provider/NonEnLocaleDataMetaInfo.java from 424
found resources.
Compiling 209 properties into resource bundles for jdk.localedata
Compiling 1569 files for jdk.localedata
Compiling 16 files for jdk.naming.dns
Compiling 6 files for jdk.naming.rmi
Compiling 13 files for jdk.policytool
Compiling 226 files for jdk.rmic
Note:
/home/hellofadude/dev/openjdk/jdk9/corba/src/jdk.rmic/share/classes/sun/rmi/rmic/iiop/DirectoryLoader.java
uses or overrides a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 605 files for BUILD_NASHORN
Compiling 111 files for BUILD_NASGEN
Running nasgen
Creating version.properties
Compiling 32 files for jdk.sctp
Compiling 36 files for jdk.security.auth
Compiling 12 files for jdk.security.jgss
Compiling 777 files for jdk.xml.bind
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 89 files for jdk.xml.dom
Compiling 234 files for jdk.xml.ws
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Compiling 12 files for jdk.zipfs
Warning: generation and use of skeletons and static stubs for JRMP
is deprecated. Skeletons are unnecessary, and static stubs have
been superseded by dynamically generated stubs. Users are
encouraged to migrate away from using rmic to generate skeletons and
static
stubs. See the documentation for java.rmi.server.UnicastRemoteObject.
Creating jdeps from 1 file(s)
Creating jimage from 1 file(s)
Creating jhat from 1 file(s)
Creating native2ascii from 1 file(s)
Creating jsadebugd from 1 file(s)
Creating libhprof.so from 26 file(s)
Creating libjava_crw_demo.so from 1 file(s)
Creating jar from 1 file(s)
Creating jarsigner from 1 file(s)
Creating javadoc from 1 file(s)
Creating jinfo from 1 file(s)
Creating jmap from 1 file(s)
Creating jps from 1 file(s)
Creating jstack from 1 file(s)
Creating jstat from 1 file(s)
Creating jcmd from 1 file(s)
Creating jconsole from 1 file(s)
Creating jdb from 1 file(s)
Creating libdt_socket.so from 2 file(s)
Creating libjdwp.so from 41 file(s)
Creating jstatd from 1 file(s)
Creating libunpack.so from 7 file(s)
Creating pack200 from 1 file(s)
Creating unpack200 from 7 file(s)
/home/hellofadude/dev/openjdk/jdk9/jdk/src/jdk.pack200/share/native/unpack200/main.cpp:
In static member function ?static int unpacker::run(int, char**)?:
/home/hellofadude/dev/openjdk/jdk9/jdk/src/jdk.pack200/share/native/unpack200/main.cpp:438:55:
warning: ignoring return value of ?size_t fread(void*, size_t, size_t,
FILE*)?, declared with attribute warn_unused_result [-Wunused-result]
       fread(&filecrc, sizeof(filecrc), 1, u.infileptr);
                                                       ^
Creating policytool from 1 file(s)
Creating rmic from 1 file(s)
Creating jjs from 1 file(s)
Creating libsctp.so from 3 file(s)
Creating libjaas_unix.so from 1 file(s)
Creating schemagen from 1 file(s)
Creating xjc from 1 file(s)
Creating wsgen from 1 file(s)
Creating wsimport from 1 file(s)
Updating support/src.zip
Compiling 1 files for BUILD_DEMO_APPLET_ArcTest
Compiling 1 files for BUILD_DEMO_APPLET_BarChart
Compiling 1 files for BUILD_DEMO_APPLET_Blink
Compiling 1 files for BUILD_DEMO_APPLET_CardTest
Compiling 1 files for BUILD_DEMO_APPLET_Clock
Compiling 1 files for BUILD_DEMO_APPLET_DitherTest
Compiling 1 files for BUILD_DEMO_APPLET_DrawTest
Compiling 1 files for BUILD_DEMO_APPLET_Fractal
Compiling 2 files for BUILD_DEMO_APPLET_GraphicsTest
Compiling 1 files for BUILD_DEMO_APPLET_NervousText
Compiling 1 files for BUILD_DEMO_APPLET_SimpleGraph
Compiling 5 files for BUILD_DEMO_APPLET_SortDemo
Compiling 1 files for BUILD_DEMO_APPLET_SpreadSheet
Compiling 3 files for BUILD_DEMO_CodePointIM
Creating support/demo/image/jfc/CodePointIM/src.zip
Updating support/demo/image/jfc/CodePointIM/src.zip
Compiling 2 files for BUILD_DEMO_MoleculeViewer
Creating support/demo/image/applets/MoleculeViewer/src.zip
Updating support/demo/image/applets/MoleculeViewer/src.zip
Compiling 2 files for BUILD_DEMO_WireFrame
Creating support/demo/image/applets/WireFrame/src.zip
Updating support/demo/image/applets/WireFrame/src.zip
Compiling 1 files for BUILD_DEMO_SwingApplet
Creating support/demo/image/jfc/SwingApplet/src.zip
Updating support/demo/image/jfc/SwingApplet/src.zip
Compiling 3 files for BUILD_DEMO_FileChooserDemo
Note:
/home/hellofadude/dev/openjdk/jdk9/jdk/src/demo/share/jfc/FileChooserDemo/FileChooserDemo.java
uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Creating support/demo/image/jfc/FileChooserDemo/src.zip
Updating support/demo/image/jfc/FileChooserDemo/src.zip
Compiling 4 files for BUILD_DEMO_Font2DTest
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Creating support/demo/image/jfc/Font2DTest/src.zip
Updating support/demo/image/jfc/Font2DTest/src.zip
Compiling 15 files for BUILD_DEMO_Metalworks
Note:
/home/hellofadude/dev/openjdk/jdk9/jdk/src/demo/share/jfc/Metalworks/MetalworksPrefs.java
uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Creating support/demo/image/jfc/Metalworks/src.zip
Updating support/demo/image/jfc/Metalworks/src.zip
Compiling 2 files for BUILD_DEMO_Notepad
Creating support/demo/image/jfc/Notepad/src.zip
Updating support/demo/image/jfc/Notepad/src.zip
Compiling 5 files for BUILD_DEMO_SampleTree
Creating support/demo/image/jfc/SampleTree/src.zip
Updating support/demo/image/jfc/SampleTree/src.zip
Compiling 8 files for BUILD_DEMO_TableExample
Note:
/home/hellofadude/dev/openjdk/jdk9/jdk/src/demo/share/jfc/TableExample/TableExample4.java
uses unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.
Creating support/demo/image/jfc/TableExample/src.zip
Updating support/demo/image/jfc/TableExample/src.zip
Compiling 1 files for BUILD_DEMO_TransparentRuler
Creating support/demo/image/jfc/TransparentRuler/src.zip
Updating support/demo/image/jfc/TransparentRuler/src.zip
Compiling 3 files for BUILD_DEMO_jconsole-plugin
Creating support/demo/image/scripting/jconsole-plugin/src.zip
Updating support/demo/image/scripting/jconsole-plugin/src.zip
Compiling 3 files for BUILD_DEMO_FullThreadDump
Creating support/demo/image/management/FullThreadDump/src.zip
Updating support/demo/image/management/FullThreadDump/src.zip
Compiling 2 files for BUILD_DEMO_JTop
Creating support/demo/image/management/JTop/src.zip
Updating support/demo/image/management/JTop/src.zip
Compiling 1 files for BUILD_DEMO_MemoryMonitor
Creating support/demo/image/management/MemoryMonitor/src.zip
Updating support/demo/image/management/MemoryMonitor/src.zip
Compiling 2 files for BUILD_DEMO_VerboseGC
Creating support/demo/image/management/VerboseGC/src.zip
Updating support/demo/image/management/VerboseGC/src.zip
Creating libcompiledMethodLoad.so from 2 file(s)
Updating support/demo/image/jvmti/compiledMethodLoad/src.zip
Creating libgctest.so from 2 file(s)
Updating support/demo/image/jvmti/gctest/src.zip
Compiling 1 files for BUILD_DEMO_JVMTI_heapTracker_JAVA
Creating support/demo/image/jvmti/heapTracker/heapTracker.jar
Creating libheapTracker.so from 3 file(s)
Updating support/demo/image/jvmti/heapTracker/src.zip
Creating libheapViewer.so from 2 file(s)
Updating support/demo/image/jvmti/heapViewer/src.zip
Compiling 1 files for BUILD_DEMO_JVMTI_minst_JAVA
Creating support/demo/image/jvmti/minst/minst.jar
Creating libminst.so from 3 file(s)
Updating support/demo/image/jvmti/minst/src.zip
Compiling 1 files for BUILD_DEMO_JVMTI_mtrace_JAVA
Creating support/demo/image/jvmti/mtrace/mtrace.jar
Creating libmtrace.so from 3 file(s)
Updating support/demo/image/jvmti/mtrace/src.zip
Creating libwaiters.so from 5 file(s)
Updating support/demo/image/jvmti/waiters/src.zip
Creating libversionCheck.so from 2 file(s)
Updating support/demo/image/jvmti/versionCheck/src.zip
Creating support/jrt-fs.jar
Creating jre jimage
Creating jdk jimage
duplicate resource "META-INF/services/com.sun.jdi.connect.Connector",
skipping
Updating images/sec-bin.zip
## Starting verify-modules
Checking dependencies across JDK modules
Access verification succeeded.
## Finished verify-modules (build time 00:01:33)

----- Build times -------
Start 2015-04-25 16:14:07
End   2015-04-25 21:54:24
00:01:33 verify-modules
05:40:17 TOTAL
-------------------------
Finished building targets 'clean images' in configuration
'linux-x86_64-normal-server-release'