Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

[Tim Bell]

Erik:

Looks good.

Tim


This is a fix for a problem brought up on this list [1]. The main issue
is that when cross compiling, and creating a buildjdk during the build,
the UnixConstants.java cannot necessarily be reused between the target
JDK and the buildjdk. While investigating this, I came to the conclusion
that we really should stop trying to reuse anything between the buildjdk
and target JDK. It's just becoming too complex to maintain (due to the
intricate interactions with the interim-image, generate-link-opt-data
and exploded-image-optimize targets, causing circular dependencies and
endless incremental rebuilds).

So this fix simply removes all the reuse of buildtools, gensrc and java
compilation when creating a buildjdk. Hopefully this is making Main.gmk
a bit less convoluted.

While working on this, I came up with the idea of adding a log prefix
functionality, to more easily discern which log lines were printed by
the buildjdk build and which were part of the normal build. I liked this
a lot so including that in the same fix, and applied it to the bootcycle
build as well.

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

Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html

/Erik

[1]
http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html

Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

[Erik Joelsson]

Thanks!

During testing, I found an intermittent race issue. The command line 
that runs the interim langtools version of javac still always points to 
the buildtools/interim-langtools dir of the normal build. This variable 
also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only 
changed in buildjdk-spec.gmk.in:


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

/Erik

On 2019-06-04 07:53, Tim Bell wrote:

Erik:

Looks good.

Tim


This is a fix for a problem brought up on this list [1]. The main issue
is that when cross compiling, and creating a buildjdk during the build,
the UnixConstants.java cannot necessarily be reused between the target
JDK and the buildjdk. While investigating this, I came to the conclusion
that we really should stop trying to reuse anything between the buildjdk
and target JDK. It's just becoming too complex to maintain (due to the
intricate interactions with the interim-image, generate-link-opt-data
and exploded-image-optimize targets, causing circular dependencies and
endless incremental rebuilds).

So this fix simply removes all the reuse of buildtools, gensrc and java
compilation when creating a buildjdk. Hopefully this is making Main.gmk
a bit less convoluted.

While working on this, I came up with the idea of adding a log prefix
functionality, to more easily discern which log lines were printed by
the buildjdk build and which were part of the normal build. I liked this
a lot so including that in the same fix, and applied it to the bootcycle
build as well.

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

Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html

/Erik

[1]
http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html 

Re: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017

[Moshe Zuisman]

Hi. Thank for your recomendation!
Although I did not success to run "hg update -r jdk-11.0.2-ga" - got :
"abort: no repository found in '/cygdrive/c/jdk11u-11.0.2-ga' (.hg not
found)!"
But since I from begining cloned jdk-11.0.2 label form site - I suppose it
gives equavalent result.

And finally I was able to pass compilation (make)
But "make test" fails any where:
to get it clear form begening - I donladed latest stabel jtreg and
configured with it:
 ./configure --with-jtreg=/cygdrive/c/jtreg






















































*$ make testBuilding target 'test' in configuration
'windows-x86_64-normal-server-release'Warning: No mercurial configuration
present and no .src-revCompiling 31 files for BUILD_JRTFSCompiling 27 files
for BUILD_FAILURE_HANDLERCreating
support/test/failure_handler/timeoutHandler.dll from 1 file(s)Creating
support/modules_libs/java.base/jrt-fs.jarc:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123:
error: no suitable method found for save(Map)
rp.save(map);  ^method InterviewParameters.save(File) is not
applicable  (argument mismatch; Map cannot be converted to
File)method InterviewParameters.save(Map) is not
applicable  (argument mismatch; Map cannot be converted to
Map)  where CAP#1,CAP#2 are fresh type-variables:CAP#1
extends Object from capture of ?CAP#2 extends Object from capture of
?Note: Some input files use or override a deprecated API.Note: Recompile
with -Xlint:deprecation for details.Note: Some messages have been
simplified; recompile with -Xdiags:verbose to get full output1
errormake[3]: *** [BuildFailureHandler.gmk:54:
/cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/support/test/failure_handler/classes/_the.BUILD_FAILURE_HANDLER_batch]
Error 1make[2]: *** [make/Main.gmk:516: build-test-failure-handler] Error
2make[2]: *** Waiting for unfinished jobsERROR: Build failed for target
'test' in configuration 'windows-x86_64-normal-server-release' (exit code
2)Stopping sjavac server=== Output from failing command(s) repeated here
===* For target
support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch:c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123:
error: no suitable method found for save(Map)
rp.save(map);  ^method InterviewParameters.save(File) is not
applicable  (argument mismatch; Map cannot be converted to
File)method InterviewParameters.save(Map) is not
applicable  (argument mismatch; Map cannot be converted to
Map)  where CAP#1,CAP#2 are fresh type-variables:CAP#1
extends Object from capture of ?CAP#2 extends Object from capture of
?Note: Some input files use or override a deprecated API.Note: Recompile
with -Xlint:deprecation for details.   ... (rest of output omitted)* All
command lines available in
/cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/make-support/failure-logs.===
End of repeated output ===No indication of failed target found.Hint: Try
searching the build log for '] Error'.Hint: See
doc/building.html#troubleshooting for assistance.make[1]: ***
[/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:305: main] Error 2make: ***
[/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:186: test] Error 2*

пн, 3 июн. 2019 г. в 10:20, David Holmes :

> On 3/06/2019 5:06 pm, Moshe Zuisman wrote:
> > Hi.
> > Probably I do not understand something in source control system of Open
> > JDK projeck.
> > I have gone to :
> > https://hg.openjdk.java.net/jdk/jdk11
> > and clicked last label:
> > "9 months ago jwilhelm Added tag jdk-11+28 for changeset
> > 76072a077ee1default tip"
> > arrived to:
> > https://hg.openjdk.java.net/jdk/jdk11/rev/1ddf9a99e4ad
> > and downloaded zip with sources.
>
> Thats JDK 11 GA version.
>
> > How have I to download latest fixed source of JDK 11.0.2?
>
> 11.0.2 is one of the JDK 11 update releases. You previously indicated
> that you were using 11u sources at:
>
>   http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281
>
> which seems to be a somewhat arbitrary point in 11u development. If you
> want a specific release, rather than latest dev sources then use the
> appropriate tag to update your sources to that level:
>
> http://hg.openjdk.java.net/jdk-updates/jdk11u/tags
>
> So if you clone
>
> http://hg.openjdk.java.net/jdk-updates/jdk11u/
>
> then do:
>
> hg update -r jdk-11.0.2-ga
>
> that should get you to the final 11.0.2 sources.
>
> That all said, the fix Kim was referring to appears to have gone into
> 11u 3 months before the date of the sources you indicated you were using.
>
> Hope that helps.
>
> David
> -
>
> >
> > пн, 3 июн. 2019 г. в 00:34, Kim Barrett  > >:
> >
> >  > On Jun 2, 2019, at 4:20 PM, Moshe Zuisman  > > wrote:
> >  >
> >  > Hi David.
> >  > I have up

RFR: JDK-8209381: Default CDS classlist generation should run with an explicit locale setting

[Erik Joelsson]

Hello,

Please review this fix for the default CDS classlist generation. This 
patch adds an explicit English locale to the generation command to make 
the build less dependent on the locale it is running in, and produce the 
same classlist regardless.


Thanks to Ioi who helped me verify that the patch actually works.

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

Webrev: http://cr.openjdk.java.net/~erikj/8209381/webrev.01/index.html

/Erik

Re: Failure buiilding OPEN JDK 11 on windows cygwin with VC 2017

[David Holmes]

On 5/06/2019 2:20 am, Moshe Zuisman wrote:

Hi. Thank for your recomendation!
Although I did not success to run "hg update -r jdk-11.0.2-ga" - got : 
"abort: no repository found in '/cygdrive/c/jdk11u-11.0.2-ga' (.hg not 
found)!"


I don't know how you are "cloning" things but you are not getting an 
actual mercurial repository out of the process!


But since I from begining cloned jdk-11.0.2 label form site - I suppose 
it gives equavalent result.


And finally I was able to pass compilation (make)
But "make test" fails any where:
to get it clear form begening - I donladed latest stabel jtreg and 
configured with it:

  ./configure --with-jtreg=/cygdrive/c/jtreg


Latest jtreg may not be suitable for 11u. The specified version 
(make/conf/jib-profiles.js) is 4.2-b12


David
-


/$ make test
Building target 'test' in configuration 
'windows-x86_64-normal-server-release'

Warning: No mercurial configuration present and no .src-rev
Compiling 31 files for BUILD_JRTFS
Compiling 27 files for BUILD_FAILURE_HANDLER
Creating support/test/failure_handler/timeoutHandler.dll from 1 file(s)
Creating support/modules_libs/java.base/jrt-fs.jar
c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123: 
error: no suitable method found for save(Map)

         rp.save(map);
           ^
     method InterviewParameters.save(File) is not applicable
       (argument mismatch; Map cannot be converted to File)
     method InterviewParameters.save(Map) is not applicable
       (argument mismatch; Map cannot be converted to 
Map)

   where CAP#1,CAP#2 are fresh type-variables:
     CAP#1 extends Object from capture of ?
     CAP#2 extends Object from capture of ?
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some messages have been simplified; recompile with -Xdiags:verbose 
to get full output

1 error
make[3]: *** [BuildFailureHandler.gmk:54: 
/cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/support/test/failure_handler/classes/_the.BUILD_FAILURE_HANDLER_batch] 
Error 1

make[2]: *** [make/Main.gmk:516: build-test-failure-handler] Error 2
make[2]: *** Waiting for unfinished jobs

ERROR: Build failed for target 'test' in configuration 
'windows-x86_64-normal-server-release' (exit code 2)

Stopping sjavac server

=== Output from failing command(s) repeated here ===
* For target 
support_test_failure_handler_classes__the.BUILD_FAILURE_HANDLER_batch:
c:\jdk11u-11.0.2-ga\test\failure_handler\src\share\classes\jdk\test\failurehandler\jtreg\GatherDiagnosticInfoObserver.java:123: 
error: no suitable method found for save(Map)

         rp.save(map);
           ^
     method InterviewParameters.save(File) is not applicable
       (argument mismatch; Map cannot be converted to File)
     method InterviewParameters.save(Map) is not applicable
       (argument mismatch; Map cannot be converted to 
Map)

   where CAP#1,CAP#2 are fresh type-variables:
     CAP#1 extends Object from capture of ?
     CAP#2 extends Object from capture of ?
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
    ... (rest of output omitted)

* All command lines available in 
/cygdrive/c/jdk11u-11.0.2-ga/build/windows-x86_64-normal-server-release/make-support/failure-logs.

=== End of repeated output ===

No indication of failed target found.
Hint: Try searching the build log for '] Error'.
Hint: See doc/building.html#troubleshooting for assistance.

make[1]: *** [/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:305: main] Error 2
make: *** [/cygdrive/c/jdk11u-11.0.2-ga/make/Init.gmk:186: test] Error 2
/

пн, 3 июн. 2019 г. в 10:20, David Holmes >:


On 3/06/2019 5:06 pm, Moshe Zuisman wrote:
 > Hi.
 > Probably I do not understand something in source control system
of Open
 > JDK projeck.
 > I have gone to :
 > https://hg.openjdk.java.net/jdk/jdk11
 > and clicked last label:
 > "9 months ago jwilhelm Added tag jdk-11+28 for changeset
 > 76072a077ee1default tip"
 > arrived to:
 > https://hg.openjdk.java.net/jdk/jdk11/rev/1ddf9a99e4ad
 > and downloaded zip with sources.

Thats JDK 11 GA version.

 > How have I to download latest fixed source of JDK 11.0.2?

11.0.2 is one of the JDK 11 update releases. You previously indicated
that you were using 11u sources at:

http://hg.openjdk.java.net/jdk-updates/jdk11u/rev/a23d4b4ea281

which seems to be a somewhat arbitrary point in 11u development. If you
want a specific release, rather than latest dev sources then use the
appropriate tag to update your sources to that level:

http://hg.openjdk.java.net/jdk-updates/jdk11u/tags

So if you clone

http://hg.openjdk.java.net/jdk-updates/jdk11u/

then do:

hg update -r jdk-11.0.2-ga

that should get you to the final 11.0.2 

Re: RFR: JDK-8209381: Default CDS classlist generation should run with an explicit locale setting

[Ioi Lam]

Looks good! Thanks for the patch.

Ioi

> On Jun 4, 2019, at 2:53 PM, Erik Joelsson  wrote:
> 
> Hello,
> 
> Please review this fix for the default CDS classlist generation. This patch 
> adds an explicit English locale to the generation command to make the build 
> less dependent on the locale it is running in, and produce the same classlist 
> regardless.
> 
> Thanks to Ioi who helped me verify that the patch actually works.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8209381
> 
> Webrev: http://cr.openjdk.java.net/~erikj/8209381/webrev.01/index.html
> 
> /Erik
> 

Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

[Tim Bell]

Erik:

OK - version 2 looks good.

Tim



Thanks!

During testing, I found an intermittent race issue. The command line
that runs the interim langtools version of javac still always points to
the buildtools/interim-langtools dir of the normal build. This variable
also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
changed in buildjdk-spec.gmk.in:

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

/Erik

On 2019-06-04 07:53, Tim Bell wrote:

Erik:

Looks good.

Tim


This is a fix for a problem brought up on this list [1]. The main issue
is that when cross compiling, and creating a buildjdk during the build,
the UnixConstants.java cannot necessarily be reused between the target
JDK and the buildjdk. While investigating this, I came to the conclusion
that we really should stop trying to reuse anything between the buildjdk
and target JDK. It's just becoming too complex to maintain (due to the
intricate interactions with the interim-image, generate-link-opt-data
and exploded-image-optimize targets, causing circular dependencies and
endless incremental rebuilds).

So this fix simply removes all the reuse of buildtools, gensrc and java
compilation when creating a buildjdk. Hopefully this is making Main.gmk
a bit less convoluted.

While working on this, I came up with the idea of adding a log prefix
functionality, to more easily discern which log lines were printed by
the buildjdk build and which were part of the normal build. I liked this
a lot so including that in the same fix, and applied it to the bootcycle
build as well.

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

Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html

/Erik

[1]
http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html

Re: RFR: JDK-8209381: Default CDS classlist generation should run with an explicit locale setting

[Tim Bell]

Erik:

Looks good to me as well.

Tim

On 06/04/19 16:59, Ioi Lam wrote:

Looks good! Thanks for the patch.

Ioi


On Jun 4, 2019, at 2:53 PM, Erik Joelsson  wrote:

Hello,

Please review this fix for the default CDS classlist generation. This patch 
adds an explicit English locale to the generation command to make the build 
less dependent on the locale it is running in, and produce the same classlist 
regardless.

Thanks to Ioi who helped me verify that the patch actually works.

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

Webrev: http://cr.openjdk.java.net/~erikj/8209381/webrev.01/index.html

/Erik

Re: RFR: JDK-8217739: Cannot reuse java.base UnixConstants.java from target in BuildJDK when cross compiling

[Ao Qi]

Hi Erik,

Thank you a lot for taking care of this. I mainly like your approach.
I tested the patch by cross building mips64-zero, by which we found
this problem. However, it seems the problem still exists. The reason I
found is that UnixConstants.java of buildjdk is generated by cross
compiler, so the macro definitions are defined by the target. Here is
a preliminary workaround for your reference only (only worked for
gcc):

$ hg diff make/gensrc/GensrcMisc.gmk
diff -r f4df9d4201cc make/gensrc/GensrcMisc.gmk
--- a/make/gensrc/GensrcMisc.gmk Tue Jun 04 16:50:25 2019 -0700
+++ b/make/gensrc/GensrcMisc.gmk Wed Jun 05 12:39:43 2019 +0800
@@ -61,6 +61,13 @@
   CPP_FLAGS += -nologo
 endif

+ifeq ($(CREATING_BUILDJDK), true)
+  # Only worked for gcc
+  TEMP_CPP=gcc -E
+else
+  TEMP_CPP=$(CPP)
+endif
+
 # Generate a java source file from a template through the C
preprocessor for the
 # target system. First extract the copyright notice at the start of the file.
 # Run the preprocessor. Filter out the default compiler stderr output on
@@ -71,7 +78,7 @@
 define generate-preproc-src
  $(call MakeDir, $(@D))
  ( $(NAWK) '/@@END_COPYRIGHT@@/{exit}1' $< && \
-   $(CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
+   $(TEMP_CPP) $(CPP_FLAGS) $(SYSROOT_CFLAGS) $(CFLAGS_JDKLIB) $< \
2> >($(GREP) -v '^$(&2) \
| $(NAWK) '/@@START_HERE@@/,0' \
|  $(SED) -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED
FILE - DO NOT EDIT/' \


Cheers,
Ao Qi

On Wed, Jun 5, 2019 at 12:00 AM Erik Joelsson  wrote:
>
> Thanks!
>
> During testing, I found an intermittent race issue. The command line
> that runs the interim langtools version of javac still always points to
> the buildtools/interim-langtools dir of the normal build. This variable
> also needs to be rewritten in buildjdk-spec.gmk.in. New webrev, only
> changed in buildjdk-spec.gmk.in:
>
> http://cr.openjdk.java.net/~erikj/8217739/webrev.02/
>
> /Erik
>
> On 2019-06-04 07:53, Tim Bell wrote:
> > Erik:
> >
> > Looks good.
> >
> > Tim
> >
> >> This is a fix for a problem brought up on this list [1]. The main issue
> >> is that when cross compiling, and creating a buildjdk during the build,
> >> the UnixConstants.java cannot necessarily be reused between the target
> >> JDK and the buildjdk. While investigating this, I came to the conclusion
> >> that we really should stop trying to reuse anything between the buildjdk
> >> and target JDK. It's just becoming too complex to maintain (due to the
> >> intricate interactions with the interim-image, generate-link-opt-data
> >> and exploded-image-optimize targets, causing circular dependencies and
> >> endless incremental rebuilds).
> >>
> >> So this fix simply removes all the reuse of buildtools, gensrc and java
> >> compilation when creating a buildjdk. Hopefully this is making Main.gmk
> >> a bit less convoluted.
> >>
> >> While working on this, I came up with the idea of adding a log prefix
> >> functionality, to more easily discern which log lines were printed by
> >> the buildjdk build and which were part of the normal build. I liked this
> >> a lot so including that in the same fix, and applied it to the bootcycle
> >> build as well.
> >>
> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8217739
> >>
> >> Webrev: http://cr.openjdk.java.net/~erikj/8217739/webrev.01/index.html
> >>
> >> /Erik
> >>
> >> [1]
> >> http://mail.openjdk.java.net/pipermail/build-dev/2019-January/024729.html
> >>
> >
> >
> >