From doko at ubuntu.com Wed Nov 1 06:37:21 2017 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 1 Nov 2017 07:37:21 +0100 Subject: version numbers for distribution builds? In-Reply-To: <1e1cb94c-f9c3-e655-6beb-159b8b315b1a@oracle.com> References: <85a1bac3-a933-c48b-080a-0525657cf080@ubuntu.com> <544dc6f7-d9fa-6a50-258a-d596b4aa11c7@ubuntu.com> <1e1cb94c-f9c3-e655-6beb-159b8b315b1a@oracle.com> Message-ID: <960adab7-9579-1fa5-40fd-50b6fe30642a@ubuntu.com> On 27.10.2017 12:46, Magnus Ihse Bursie wrote: > > On 2017-10-27 12:21, David Holmes wrote: >> Adding build-dev. >> >> David >> >> On 27/10/2017 9:13 AM, Matthias Klose wrote: >>> On 27.10.2017 00:56, Matthias Klose wrote: >>>> Hi, >>>> >>>> I recently learned that I should configure an openjdk build with an empty >>>> -with-version-pre string, and with any package information stuffed into the >>>> --with-version-opt argument. >>>> >>>> ?? --with-version-pre='' --with-version-opt='Debian-9.0.1+11-1' >>>> >>>> 9.0.1+11 is what I call the upstream version, directly derived from the tag in >>>> the mercurial repository.? The part after the dash is the packaging release and >>>> gets incremented when more than upload to the distribution is based on the same >>>> upstream version. >>>> >>>> However using that I get >>>> >>>> configure: WARNING: --with-version-opt value has been sanitized from >>>> 'Debian-9.0.1+11-1' to 'Debian-9.0.111-1' >>>> >>>> which makes the version string somehow cryptic.? Why is there a reason that the >>>> version string is mangled?? Is there a recommendation how to form the version >>>> for a source release? >>> >>> $ java -version >>> openjdk version "9.0.1" >>> OpenJDK Runtime Environment (build 9.0.1+0-Debian-9.0.111-1) >>> OpenJDK 64-Bit Server VM (build 9.0.1+0-Debian-9.0.111-1, mixed mode) >>> >>> Omar suggested on irc to use >>> >>> ?? --with-version-pre='' --with-version-build=11 --with-version-opt='Debian.1 >>> >>> however that will lead to 9.0.1+11-Debian.1, which doesn't match the package >>> version either.? It looks like this whole versioning schema is only fit for >>> upstream builds, and doesn't address any versioning in the downstream builds. >>> >>> Maybe I'm missing something, but how can I include the string Debian-9.0.1+11-1 >>> into that build information? > Unfortunately, you can't. JEP 223 specifices what a valid Java version string > looks like: http://openjdk.java.net/jeps/223 > > I believe your intention is correct to add the distribution versioning to the > "opt" part, but that is limited to containing ([-a-zA-Z0-9\.]+) according to JEP > 223, so it cannot contain a "+". (This is due to the fact that "+" has a special > meaning as the build prefix, and without this restriction, version strings could > become ambigious to parse. > > If you want the full version number repeated in the opt string, I recommend > replacing the "+" with a "-". This is error prone on the Debian side, because the additional "-" is getting interpreted as the Debian release number, if you don't include it explicitly, so something like 9.0.1-11 is interpreted as upstream 9.0.1. > Otherwise I'd recommend Omar's suggestion. I believe that was the intention of > the JEP 223 design. It will contain the version number of the JDK, the build > number, and the additional (opt) part saying that this is a Debian build, with a > Debian-specific version numbering of 1. so while discussing the new date based versioning schema, can we amend that with a downstream versioning schema? Note that other projects provide the ability to include downstream versioning without any mangling: $ gcc --version gcc (Debian 7.2.0-12) 7.2.1 20171025 configured with --with-pkgversion='Debian 7.2.0-12' Matthias From daniel.daugherty at oracle.com Wed Nov 1 16:51:16 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 1 Nov 2017 12:51:16 -0400 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> Message-ID: <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Just one comment about the location of "jvm.h". On 10/30/17 8:07 AM, coleen.phillimore at oracle.com wrote: > > > On 10/28/17 3:46 AM, David Holmes wrote: >> On 28/10/2017 3:47 AM, mandy chung wrote: >>> On 10/27/17 7:08 AM, coleen.phillimore at oracle.com wrote: >>>> >>>> >>>> On 10/27/17 9:37 AM, David Holmes wrote: >>>>> >>>>> The one file that is needed is a hotspot file - jvm.h defines the >>>>> interface that hotspot exports via jvm.cpp. >>>>> >>>>> If you leave jvm.h in hotspot/prims then a very large chunk of >>>>> your boilerplate changes are not needed. The JDK code doesn't care >>>>> what the name of the directory is - whatever it is just gets added >>>>> as a -I directive (the JDK code will include "jvm.h" not >>>>> "prims/jvm.h" the way hotspot sources do. >>>>> >>>>> This isn't something we want to change back or move again later. >>>>> Whatever we do now we live with. >>>> >>>> I think it belongs with jni.h and I think the core libraries group >>>> would agree.?? It seems more natural there than buried in the >>>> hotspot prims directory.? I guess this is on hold while we have >>>> this debate.?? Sigh. >>>> >>>> Actually with -I directives, changing to jvm.h from prims/jvm.h >>>> would still work.?? Maybe we should change the name to jvm.hpp >>>> since it's jvm.cpp though??? Or maybe just have two divergent >>>> copies and close this as WNF. >>> >>> I also think hotspot/prims is not a good location. >>> src/java.base/share/include is a well-defined location for native >>> header files.? Maybe internal header files could be placed in >>> include/internal but this is a separate issue .? I should create an >>> issue for jvm.h and jmm.h (I looked at the files under the include >>> directory and jvm.h and jmm.h are the only two internal header files >>> in the include directory). >> >> Keeping it in prims avoids the need to touch many hotspot files, and >> with no changes needed on the JDK side because we use a -I directive >> to set the include path anyway. This is the exported VM interface so >> it makes sense to me for it to be located in the VM sources. >> >> But I'm not going to oppose this either way so it's up to Coleen. > > I've already disagreed that this file belongs in > src/hotspot/share/prims, so the include directive without prims is > preferred.? This allows putting jvm.h in a new place if/when that is > agreed upon. The jvm.h file describes the internal JVM_* API implemented by prims/jvm.cpp. Because this is an internal interface, the jvm.h file would traditionally be co-located with the implementation (jvm.cpp) (and not in an include directory). So I disagree with the proposal to move jvm.h and believe the single copy should be in prims/jvm.h. Dan >> >>> I do think removing the duplicated copy of jvm.h is a good change. >>> This is finally possible with the consolidated repository and we no >>> longer need to update two copies of jvm.h for any change to the JVM >> >> Unfortunately we did not do this though - hence the divergence >> between the two. The use of int versus long for jint is causing a >> real problem. >> >> Coleen also hit the other issue on the head. The JNI and JVM >> interfaces are C interfaces, not C++. The JDK code that uses them is >> compiled as C - so all good. But the JVM code that implements them is >> compiled as C++, and that is why we are getting issues with differing >> linkage directives. > > Well, there is now one source file for jvm.h and jni.h and their > machine dependent counterparts and 2500 lines of duplicated code is > removed with this change.? The issues with jint and linkages are > resolved and tested as well with this changeset. > > Thanks, > Coleen >> >> David >> ----- >> >>> interface.?? This change will work with -I directive setting to the >>> new location, if changed later. >>> >>> What do you think? >>> >>> Mandy > From coleen.phillimore at oracle.com Wed Nov 1 18:09:58 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 1 Nov 2017 14:09:58 -0400 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Message-ID: On 11/1/17 12:51 PM, Daniel D. Daugherty wrote: > Just one comment about the location of "jvm.h". > > > On 10/30/17 8:07 AM, coleen.phillimore at oracle.com wrote: >> >> >> On 10/28/17 3:46 AM, David Holmes wrote: >>> On 28/10/2017 3:47 AM, mandy chung wrote: >>>> On 10/27/17 7:08 AM, coleen.phillimore at oracle.com wrote: >>>>> >>>>> >>>>> On 10/27/17 9:37 AM, David Holmes wrote: >>>>>> >>>>>> The one file that is needed is a hotspot file - jvm.h defines the >>>>>> interface that hotspot exports via jvm.cpp. >>>>>> >>>>>> If you leave jvm.h in hotspot/prims then a very large chunk of >>>>>> your boilerplate changes are not needed. The JDK code doesn't >>>>>> care what the name of the directory is - whatever it is just gets >>>>>> added as a -I directive (the JDK code will include "jvm.h" not >>>>>> "prims/jvm.h" the way hotspot sources do. >>>>>> >>>>>> This isn't something we want to change back or move again later. >>>>>> Whatever we do now we live with. >>>>> >>>>> I think it belongs with jni.h and I think the core libraries group >>>>> would agree.?? It seems more natural there than buried in the >>>>> hotspot prims directory.? I guess this is on hold while we have >>>>> this debate.?? Sigh. >>>>> >>>>> Actually with -I directives, changing to jvm.h from prims/jvm.h >>>>> would still work.?? Maybe we should change the name to jvm.hpp >>>>> since it's jvm.cpp though??? Or maybe just have two divergent >>>>> copies and close this as WNF. >>>> >>>> I also think hotspot/prims is not a good location. >>>> src/java.base/share/include is a well-defined location for native >>>> header files.? Maybe internal header files could be placed in >>>> include/internal but this is a separate issue .? I should create an >>>> issue for jvm.h and jmm.h (I looked at the files under the include >>>> directory and jvm.h and jmm.h are the only two internal header >>>> files in the include directory). >>> >>> Keeping it in prims avoids the need to touch many hotspot files, and >>> with no changes needed on the JDK side because we use a -I directive >>> to set the include path anyway. This is the exported VM interface so >>> it makes sense to me for it to be located in the VM sources. >>> >>> But I'm not going to oppose this either way so it's up to Coleen. >> >> I've already disagreed that this file belongs in >> src/hotspot/share/prims, so the include directive without prims is >> preferred.? This allows putting jvm.h in a new place if/when that is >> agreed upon. > > The jvm.h file describes the internal JVM_* API implemented by > prims/jvm.cpp. > Because this is an internal interface, the jvm.h file would > traditionally be > co-located with the implementation (jvm.cpp) (and not in an include > directory). > > So I disagree with the proposal to move jvm.h and believe the single copy > should be in prims/jvm.h. So, we have a variety of opinions.?? Please open another ticket to discuss this. thanks, Coleen > > Dan > > >>> >>>> I do think removing the duplicated copy of jvm.h is a good change. >>>> This is finally possible with the consolidated repository and we no >>>> longer need to update two copies of jvm.h for any change to the JVM >>> >>> Unfortunately we did not do this though - hence the divergence >>> between the two. The use of int versus long for jint is causing a >>> real problem. >>> >>> Coleen also hit the other issue on the head. The JNI and JVM >>> interfaces are C interfaces, not C++. The JDK code that uses them is >>> compiled as C - so all good. But the JVM code that implements them >>> is compiled as C++, and that is why we are getting issues with >>> differing linkage directives. >> >> Well, there is now one source file for jvm.h and jni.h and their >> machine dependent counterparts and 2500 lines of duplicated code is >> removed with this change.? The issues with jint and linkages are >> resolved and tested as well with this changeset. >> >> Thanks, >> Coleen >>> >>> David >>> ----- >>> >>>> interface.?? This change will work with -I directive setting to the >>>> new location, if changed later. >>>> >>>> What do you think? >>>> >>>> Mandy >> > From daniel.daugherty at oracle.com Wed Nov 1 18:34:25 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Wed, 1 Nov 2017 14:34:25 -0400 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Message-ID: > So, we have a variety of opinions.?? Please open another ticket to > discuss this. Sorry, I didn't realize that this fix pushed yesterday. I'm not completely caught up on all of the email. It's not worth another bug report (and more changes). Dan On 11/1/17 2:09 PM, coleen.phillimore at oracle.com wrote: > > > On 11/1/17 12:51 PM, Daniel D. Daugherty wrote: >> Just one comment about the location of "jvm.h". >> >> >> On 10/30/17 8:07 AM, coleen.phillimore at oracle.com wrote: >>> >>> >>> On 10/28/17 3:46 AM, David Holmes wrote: >>>> On 28/10/2017 3:47 AM, mandy chung wrote: >>>>> On 10/27/17 7:08 AM, coleen.phillimore at oracle.com wrote: >>>>>> >>>>>> >>>>>> On 10/27/17 9:37 AM, David Holmes wrote: >>>>>>> >>>>>>> The one file that is needed is a hotspot file - jvm.h defines >>>>>>> the interface that hotspot exports via jvm.cpp. >>>>>>> >>>>>>> If you leave jvm.h in hotspot/prims then a very large chunk of >>>>>>> your boilerplate changes are not needed. The JDK code doesn't >>>>>>> care what the name of the directory is - whatever it is just >>>>>>> gets added as a -I directive (the JDK code will include "jvm.h" >>>>>>> not "prims/jvm.h" the way hotspot sources do. >>>>>>> >>>>>>> This isn't something we want to change back or move again later. >>>>>>> Whatever we do now we live with. >>>>>> >>>>>> I think it belongs with jni.h and I think the core libraries >>>>>> group would agree.?? It seems more natural there than buried in >>>>>> the hotspot prims directory.? I guess this is on hold while we >>>>>> have this debate.?? Sigh. >>>>>> >>>>>> Actually with -I directives, changing to jvm.h from prims/jvm.h >>>>>> would still work.?? Maybe we should change the name to jvm.hpp >>>>>> since it's jvm.cpp though??? Or maybe just have two divergent >>>>>> copies and close this as WNF. >>>>> >>>>> I also think hotspot/prims is not a good location. >>>>> src/java.base/share/include is a well-defined location for native >>>>> header files.? Maybe internal header files could be placed in >>>>> include/internal but this is a separate issue . I should create an >>>>> issue for jvm.h and jmm.h (I looked at the files under the include >>>>> directory and jvm.h and jmm.h are the only two internal header >>>>> files in the include directory). >>>> >>>> Keeping it in prims avoids the need to touch many hotspot files, >>>> and with no changes needed on the JDK side because we use a -I >>>> directive to set the include path anyway. This is the exported VM >>>> interface so it makes sense to me for it to be located in the VM >>>> sources. >>>> >>>> But I'm not going to oppose this either way so it's up to Coleen. >>> >>> I've already disagreed that this file belongs in >>> src/hotspot/share/prims, so the include directive without prims is >>> preferred.? This allows putting jvm.h in a new place if/when that is >>> agreed upon. >> >> The jvm.h file describes the internal JVM_* API implemented by >> prims/jvm.cpp. >> Because this is an internal interface, the jvm.h file would >> traditionally be >> co-located with the implementation (jvm.cpp) (and not in an include >> directory). >> >> So I disagree with the proposal to move jvm.h and believe the single >> copy >> should be in prims/jvm.h. > > So, we have a variety of opinions.?? Please open another ticket to > discuss this. > thanks, > Coleen >> >> Dan >> >> >>>> >>>>> I do think removing the duplicated copy of jvm.h is a good change. >>>>> This is finally possible with the consolidated repository and we >>>>> no longer need to update two copies of jvm.h for any change to the >>>>> JVM >>>> >>>> Unfortunately we did not do this though - hence the divergence >>>> between the two. The use of int versus long for jint is causing a >>>> real problem. >>>> >>>> Coleen also hit the other issue on the head. The JNI and JVM >>>> interfaces are C interfaces, not C++. The JDK code that uses them >>>> is compiled as C - so all good. But the JVM code that implements >>>> them is compiled as C++, and that is why we are getting issues with >>>> differing linkage directives. >>> >>> Well, there is now one source file for jvm.h and jni.h and their >>> machine dependent counterparts and 2500 lines of duplicated code is >>> removed with this change.? The issues with jint and linkages are >>> resolved and tested as well with this changeset. >>> >>> Thanks, >>> Coleen >>>> >>>> David >>>> ----- >>>> >>>>> interface.?? This change will work with -I directive setting to >>>>> the new location, if changed later. >>>>> >>>>> What do you think? >>>>> >>>>> Mandy >>> >> > > From mandy.chung at oracle.com Wed Nov 1 18:41:08 2017 From: mandy.chung at oracle.com (mandy chung) Date: Wed, 1 Nov 2017 11:41:08 -0700 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Message-ID: On 11/1/17 11:09 AM, coleen.phillimore at oracle.com wrote: > > So, we have a variety of opinions.?? Please open another ticket to > discuss this. https://bugs.openjdk.java.net/browse/JDK-8190484 Mandy From coleen.phillimore at oracle.com Wed Nov 1 18:51:42 2017 From: coleen.phillimore at oracle.com (coleen.phillimore at oracle.com) Date: Wed, 1 Nov 2017 14:51:42 -0400 Subject: RFR (L, tedious again, sorry) 8189610: Reconcile jvm.h and all jvm_md.h between java.base and hotspot In-Reply-To: References: <8671321f-398c-5f7f-634d-9d9664e04d87@oracle.com> <05bf853a-52f8-c450-4171-89f6b64d793a@oracle.com> <72f2aac7-ed20-c995-913b-ee4341a2a978@oracle.com> <55ec3559-c593-bcb6-51b0-4639da126068@oracle.com> <4509dce7-10f8-4558-2adb-90d4745e054e@oracle.com> <396ab0f7-3710-3f76-675a-5108bcb50af5@oracle.com> <51f09db9-06f5-ad01-bc92-1d73e1113f86@oracle.com> <66b590da-f94c-6d87-cf61-e269bf1afc0d@oracle.com> <0b049cc8-b3dc-cdfb-d71a-3e43274a1b9a@oracle.com> Message-ID: <35a4976e-7133-244e-a73b-4eab93f4f788@oracle.com> On 11/1/17 2:41 PM, mandy chung wrote: > > > On 11/1/17 11:09 AM, coleen.phillimore at oracle.com wrote: >> >> So, we have a variety of opinions.?? Please open another ticket to >> discuss this. > > https://bugs.openjdk.java.net/browse/JDK-8190484 > > Mandy Thanks Mandy!? There were arguments for and against these locations, and some alternate suggestions.? The way the sources are, they can be moved.? It may be a build system change to get the include directives correct for the _md.h files. I think the discussion should carry forward in the bug report so that the resulting code change matches what people have decided. thanks, Coleen From erik.joelsson at oracle.com Thu Nov 2 00:07:22 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 1 Nov 2017 17:07:22 -0700 Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: <87472397-d1a6-e804-eb02-6fabdd2bbae2@oracle.com> <1727F532-B9DA-42AC-9B3E-6AB93DF349C7@oracle.com> <44d6d053-0666-c6f1-343e-87dc074543fb@oracle.com> <4da0c111-f13f-a814-09e2-906a02eaacb6@oracle.com> <5D41C052-D10F-4E7C-B6A7-4759274D5753@oracle.com> <565779B5-B2EE-40DC-8587-0B21AC788406@oracle.com> Message-ID: I would say a few hours is way too long for tier1, but it of course depends on the hardware used. We typically run it on windows in less than 30 minutes with concurrency set to 6. Not sure what concurrency you used by default. /Erik On 2017-10-27 04:33, Peter Budai wrote: > Hi Magnus, after a little poking I managed to install and use jtreg, thanks for the guidance. > > Make run-test-tier1 resulted a pretty OK result for a first try, at least for run-test-jdk: > Test results: passed: 1,610; failed: 34; error: 1 > It took a few hors to run ? is that normal? > > I?ll review the patchset, and then share that with you. > > P. > > From: Magnus Ihse Bursie > Sent: Thursday, October 26, 2017 11:00 AM > To: Peter Budai > Cc: build-dev at openjdk.java.net > Subject: Re: Building OpenJDK9 on MSYS2 > > > On 2017-10-26 00:01, Peter Budai wrote: > OK, I have found what was missing, it was actually my fault with a missing exception handler. > > So finally OpenJDK build has finished on Windows using gcc toolchain running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it looks promising: > ./build/windows-x86_64-normal-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher.exe --jdk=/home/peterbud/jdk9/build/windows-x86_64-normal-server-fastdebug/jdk > ?. > ?. > ?. > > [----------] Global test environment tear-down > [==========] 346 tests from 54 test cases ran. (3859 ms total) > [ PASSED ] 346 tests. > I'm impressed! :-) > > Would you care to share your current patchset, just to still my curiosity? :-) > > > > What is the best way to test the current build more thoroughly? > "make run-test-tier1". As Erik says, you'll need jtreg, and call "configure --with-jtreg=...". You can get it from the Adopt OpenJDK group here: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > > /Magnus > > > P. > > From: Bob Vandette > Sent: Tuesday, October 24, 2017 8:10 PM > To: Peter Budai > Cc: David Holmes; Erik Joelsson; Magnus Ihse Bursie; build-dev at openjdk.java.net > Subject: Re: Building OpenJDK9 on MSYS2 > > Can you provide some details about your toolchain, processor and os plus > a dump of the native instructions around the SEGV. This might give us > enough info to be able to figure out what?s going on. > > Bob. > > On Oct 24, 2017, at 1:21 PM, Peter Budai > wrote: > > I get that error running in the debugger but also running without/outside of the debugger as well. > > I saw the comment in the code about generating SEGV in function generate_get_cpu_info(), however the debugger can execute that, and the SEGV I experience is coming later in the VM_Version::get_processor_features() function > > Peter > > From: Bob Vandette > Sent: Tuesday, October 24, 2017 6:28 PM > To: Peter Budai > Cc: David Holmes; Erik Joelsson; Magnus Ihse Bursie; build-dev at openjdk.java.net > Subject: Re: Building OpenJDK9 on MSYS2 > > Was this a SEGV while you were running the debugger? > > There is an intentional SEGV generated. This is used to determine if we can use some of newer > CPU features. Try to allow the SEGV to continue to see if you run normally. > > Bob. > > >> On Oct 24, 2017, at 11:37 AM, Peter Budai > wrote: >> >> It seems that the compile is progressing well, I have 49 executables/tools and 38 compiled shared libraries already in the JDK folder. >> >> I have tried to run the product with the simplest ?java -version? command, however I get a SIGSEGV at get_cpu_info_stub() in vm_version_x86.cpp, VM_Version::get_processor_features() >> >> get_cpu_info_stub(&_cpuid_info); >> >> Thread 5 received signal SIGSEGV, Segmentation fault. >> 0x000000002d9a072f in ?? () >> >> I can debug using gdb, but unfortunately this is pure ASM, and my knowledge on this is close to 0. >> >> Any idea help or pointer how could I tackle this? >> >> Peter >> >> From: David Holmes >> Sent: Sunday, October 15, 2017 10:37 PM >> To: Peter Budai; Erik Joelsson; Magnus Ihse Bursie >> Cc: build-dev at openjdk.java.net >> Subject: Re: Building OpenJDK9 on MSYS2 >> >> On 16/10/2017 12:41 AM, Peter Budai wrote: >>> A quick status update: >>> >>> * Hotspot successfully compiled without warnings >>> * I?d like to run the unit tests, but as I see ?make check? does not work, and gtestlauncher expects a command line parameter jdk. Tried to look up some documentation on this, but have not found. So the question is: how can I run unit tests for hotspot? Do I need also JDK compiled for that? Or the bootJDK is good enough? Any help would be appreciated. >> Hotspot has to be tested as part of a full JDK - you can't load the JVM >> without having the "J" part :) >> >> You should be able to drop your built dll into an existing JDK 9 windows >> JDK and test it that way. >> >> David >> ----- >> >>> * Also I?m making progress on compiling jdk, but there are some very interesting solutions on windows linking which makes a bit more difficult to compile with gcc: LIBS_windows contains sometimes simple library names (which I believe is correct) and other times library names with full path (which I believe is not the best solution). I?m trying to rework those places and use simple library names and passing search path for libraries -L (for gcc toolchain) and /LIBPATH: (for Microsoft toolchain). Also I was surprised by a few manual function name exports? >>> * jdk code base contains apparently more MSVC specific part, many places casts/lack of casts are generating errors, static attributes were missing etc. a bit tedious work. >>> >>> P. >>> >>> From: Erik Joelsson >>> Sent: Wednesday, October 11, 2017 4:16 PM >>> To: Magnus Ihse Bursie; Peter Budai >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> Hello, >>> >>> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: >>> >>> For gcc, we let the compiler generate the .d file. For the Microsoft tool chain, we use a clever sed script to extract and create it ourself. >>> >>> I think that logic is checking for "Windows", not "Microsoft". That might be your cause of trouble. >>> >>> Look in NativeCompilation.gmk. >>> >>> That was my initial thought as well, but we do correctly check for microsoft. Also it's not the .d files that are the problem. As Peter just wrote, they look fine. It's the .d.target files which we create using the same technique on all platforms. What we don't account for is the compiler putting Windows mixed paths in the .d files. >>> >>> /Magnus >>> >>> 11 okt. 2017 kl. 14:43 skrev Peter Budai >: >>> Hi Erik, >>> >>> The .d file looks like this: >>> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: \ >>> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp \ >>> >>> I have checked .d.targets file, and looks like it has the first line has not been deleted, and the file names below are also wrong: >>> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj : : >>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp : >>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : >>> >>> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by the ?C:/? >>> -e 's/^[^:]*: *//' >>> >>> Yes, that does indeed look like the problem. I suppose the regexp is unnecessarily strict. It should be ok to rewrite it as something like this: >>> -e 's/^.*: *//' >>> >>> Basically just make sure it ends with : and any number of spaces. >>> >>> /Erik >>> >>> >>> >>> Peter >>> >>> Sent from Mail for Windows 10 >>> >>> From: Erik Joelsson >>> Sent: Wednesday, October 11, 2017 12:16 PM >>> To: Peter Budai; Magnus Ihse Bursie; build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> >>> Hello Peter, >>> >>> On 2017-10-11 00:18, Peter Budai wrote: >>> Thanks Magnus & Erik >>> >>> First thanks for your support and kind words! >>> >>> Magnus, I have checked .bash_profile, .bashrc but they seem to be empty (everything is commented out). You can check with a default MSYS2 install, I have not changed these files at all. If you find thee something specific I can give a try here as well. >>> >>> Let me give also a quick status update, where am I with building hotspot: >>> ? I guess its still the beginning, but I have managed to compile jvm.dll with almost 700 object file: with debug info the dll is around 700 MB ? >>> ? I made only surgical, minimal changes to the source, and so far it looks reasonable. I have encountered 3 scenarios where changes were necessary: >>> o When in makefiles conditionals were using assuming that if target_os is windows then it is visual studio compiler/linker. Obviously these conditionals had to be reviewed in a few places and if necessary were changes to check the toolchain=Microsoft >>> These are not surprising and should be pretty straight forward to fix and it seems you know what to do. >>> >>> >>> ? >>> o I got a few warnings as gcc 7.2 uncovered some code problems in windows specific codes, where before that MSVC I guess did not say a word? >>> To get around this you can configure with --disable-warnings-as-errors until you get things working properly. This is commonly needed when using compiler versions that we normally don't use. >>> >>> >>> ? >>> o And I had like 6-7 places where the code was using MSVC specific __try ? __except structures which gcc does not know. Do you have a suggestion how to approach them? I can do ugly #ifdefs (I would avoid that) but I have also seen some solutions to replace them with a code which gcc can compile (http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh ) ? but before doing that though I would ask first you on the purpose of those >>> This kind of question is probably best to bring to the hotspot mailing list. >>> ? What bothers me is that I was not able to do incremental builds: when an error occurs, and build stops, then after making change in the CPP source the build cannot continue, I always got an error message: >>> >>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.d.targets:1: *** missing target pattern. Stop. >>> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 >>> >>> If I do a ?make clean? and restart the build then it nicely compiles. >>> >>> Question 1: Is there a way to resume such builds without ?make clean?? >>> Well, incremental builds is supposed to work well. We have several extra tricks in there to handle cases where normal make builds would fail. The *.d.targets files is one such trick and it seems to backfire for you. The contents of that file should be something like: >>> >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : >>> >>> Basically an empty rule for each dependency for the corresponding object file. Declaring these rules makes it possible to delete source files without having to build clean. It seems your file is not generated correctly so please have a look inside it. The file is in make/common/NativeCompilation.gmk, look for DEPENDENCY_TARGET_SED_PATTERN. >>> >>> >>> >>> Question 2: What would be the best way to submit/share the patches for your thorough review? >>> >>> Well, first of all, have you signed the OCA? >>> >>> As for publishing patches and reviews, there is a bit of chicken and egg problem. Once you become an "author" in any of the OpenJDK projects, you get a user name and should be able to publish reviews on cr.openjdk.java.net>. Before that, if the patch is small, it can be posted inline in an email to the list. If it's large, you will need a current OpenJDK user to host it for you. At least that's how I understand it. Hopefully someone who knows the process better can chime in here. >>> >>> I should also let you know that getting this into JDK 9 is most likely not going to happen. AFAIK we are only doing security updates for 9. It would have to go into the currently active release. I should also warn you that new ports generally need a certain amount of backing to be accepted. It may be that this would have to live in a porting side project. Hopefully someone who knows this better can chime in here as well. >>> >>> /Erik >>> >>> >>> P. >>> >>> Sent from Mail for Windows 10 >>> >>> From: Magnus Ihse Bursie >>> Sent: Tuesday, October 10, 2017 10:04 AM >>> To: Peter Budai; Erik Joelsson; build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> On 2017-10-07 10:14, Peter Budai wrote: >>> The configure of OpenJDK overwrites the SHELL. Actually it is using bash, but for the arguments it was using ?-e -o pipefail?. I have figured that for MSYS2 bash what is needed as bash arguments is ?-e -l -c -o pipefail? >>> >>> That looks like solving this problem, and now the real issues are surfacing. >>> >>> FWIW, "-l" makes bash behave like a login shell. Most likely you are changing bash's behavior in one of your login scripts, and that change is what's really needed. >>> >>> /Magnus >>> >>> >>> >>> >>> >>> Peter >>> >>> From: Peter Budai >>> Sent: Friday, October 6, 2017 6:43 PM >>> To: Magnus Ihse Bursie; Erik Joelsson; build-dev at openjdk.java.net >>> Subject: RE: Building OpenJDK9 on MSYS2 >>> >>> Magnus, >>> >>> I have followed your suggestion and removed the fixpath prefixes from gcc related compile tools, and left only the fixpath prefix _only_ for the Boot JDK related tools in place. >>> >>> 1) As I follow the process, all java and javac related compile steps are running properly >>> 2) When the process reaches gcc related steps I got the error message at the same place as before (no fixpath). If I execute that command from the bash prompt, it creates the output: >>> >>> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template && /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java >>> >>> As I have mentioned the parameters are replaced by the bash automatically >>> 3) Then build continues, then little later stops at a super simple command: >>> >>> mv /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBuffer.java >>> Needless to say, the ByteBuffer.java.tmp file DOES exist. And running the above command from the bash works, and build continues. >>> 4) A few similar cases (stops) with DirectByteBuffer and DirectByteBufferR >>> >>> >>> Currently I try to explore how that might relate to the MSYS2 bash and make, somehow it behaves differently >>> >>> If you have any other suggestion, let me know. >>> >>> Best regards, >>> >>> Peter >>> >>> From: Peter Budai >>> Sent: Thursday, October 5, 2017 3:52 PM >>> To: Magnus Ihse Bursie; Erik Joelsson; build-dev at openjdk.java.net >>> Subject: RE: Building OpenJDK9 on MSYS2 >>> >>> Hi Magnus, >>> >>> So first of all, here is the current patch, which I was not able to attach: https://pastebin.com/pwT4Ynxc >>> >>>>> That's surprising, since gcc is prefixed with fixpath, which it should not. >>> Actually you DO need fixpath IMHO. >>> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), which is a fully functional Windows executable, which expects Windows formatted path arguments. >>> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see that patch), none of the command line arguments are converted from the unix path to Windows, but fixpath does that conversion. There is a wiki describing more details on this: >>> https://github.com/msys2/msys2/wiki/Porting#user-content-filesystem-namespaces >>> >>> >>> >>>>> I have a hard time believing this is a race condition. On the other hand, this stuff is weird, we're misusing the C preprocessor to process defines in java code, so I'm not surprised it breaks down. >>>>> I don't know why it succeeded when run on the command line, though. >>> When I execute that command from the bash command line there is no EXPORT MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic conversion of the arguments. Maybe it has something to do how fixpath does CreateProcess? >>> >>> Does that help? >>> >>> Best regards, >>> >>> Peter >>> >>> Sent from Mail for Windows 10 >>> >>> From: Magnus Ihse Bursie >>> Sent: Thursday, October 5, 2017 12:13 PM >>> To: Peter Budai; Erik Joelsson; build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> >>> On 2017-10-05 11:59, Peter Budai wrote: >>> Hi Magnus and Erik, >>> >>> I really appreciate your quick feedback. I assumed that it won?t be easy, but I just don?t feel I should give up now - maybe later when I see the real scale of work. So bear with me for a time being. >>> >>> Attached is a patch which already includes Magnus? changes, plus a few which I have added: >>> ? basically enabling gcc for windows, >>> ? and modifying a logic for compiling fixpath (before that it was using hard-coded MS VSC compile flags) >>> >>> Actually, you must make sure fixpath is *not* used for the toolchain, since gcc uses unix style paths. >>> (However, other tools such as java will still need it.) >>> >>> >>> >>> >>> >>> >>> So here is what I have as the result of configure: >>> ==================================================== >>> The existing configuration has been successfully updated in >>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release >>> using configure arguments '--disable-freetype-bundling --disable-javac-server'. >>> >>> Configuration summary: >>> * Debug level: release >>> * HS debug level: product >>> * JDK variant: normal >>> * JVM variants: server >>> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 >>> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) >>> >>> Tools summary: >>> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) >>> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) >>> * Toolchain: gcc (GNU Compiler Collection) >>> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) >>> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) >>> >>> Build performance summary: >>> * Cores to use: 4 >>> * Memory limit: 16216 MB >>> >>> Its clear says that the toolchain is gcc 7.2 (BTW there is no Visual Studio on this machine) >>> >>> Now for the details of the config log, you can see here: https://pastebin.com/MN2ZYcHH >>> >>> And about the build process and the error I get: >>> >>> $ make JOBS=1 >>> Building target 'default (exploded-image)' in configuration 'windows-x86_64-normal-server-release' >>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >>> Compiling 17 properties into resource bundles for jdk.compiler >>> Parsing 1 properties into enum-like class for jdk.compiler >>> Compiling 19 properties into resource bundles for jdk.javadoc >>> Compiling 12 properties into resource bundles for jdk.jdeps >>> Compiling 7 properties into resource bundles for jdk.jshell >>> Compiling 117 files for BUILD_INTERIM_java.compiler >>> Compiling 396 files for BUILD_INTERIM_jdk.compiler >>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps >>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc >>> Note: Some input files use or override a deprecated API. >>> Note: Recompile with -Xlint:deprecation for details. >>> Compiling 159 files for BUILD_TOOLS_JDK >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>> make[3]: *** Deleting file '/C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java' >>> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 >>> >>> ERROR: Build failed for target 'default (exploded-image)' in configuration 'windows-x86_64-normal-server-release' (exit code 2) >>> >>> No indication of failed target found. >>> Hint: Try searching the build log for '] Error'. >>> Hint: See common/doc/building.html#troubleshooting for assistance. >>> >>> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 >>> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 >>> >>> If I run here >>> make JOBS=1 LOG=debug >>> The failing line seems to be this: >>> >>> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template && /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java >>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>> >>> Now the interesting is: if I copy this line above to the bash prompt, it runs without problem, and the file support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java >>> That's surprising, since gcc is prefixed with fixpath, which it should not. >>> >>> I have a hard time believing this is a race condition. On the other hand, this stuff is weird, we're misusing the C preprocessor to process defines in java code, so I'm not suprised it breaks down. I don't know why it succeeded when run on the command line, though. My suggestion is to just do some quick and dirty hack around this: take the file you manage to generate and just copy it in during the build instead. If you can get round this, you might start seeing some *real* problems. :-) >>> >>> Also, my suggestion is that you try running "make hotspot" to cut to the chase. Compiling hotspot will likely be the hardest thing. Or even "make -k hotspot" to get an assessment of the amount of work ahead of you. >>> >>> /Magnus >>> Is produced. >>> >>> Then I can again issue >>> make JOBS=1 LOG=debug >>> >>> And the compile process is being continued, until a similar error pops up with a different generated file. I have an assumption that this happens because make is still running parallel jobs, despite JOBS=1 but I?m not sure. >>> >>> How could I best tackle this? >>> >>> Thank you and best regards, >>> >>> Peter >>> >>> Sent from Mail for Windows 10 >>> >>> From: Magnus Ihse Bursie >>> Sent: Thursday, October 5, 2017 11:33 AM >>> To: Erik Joelsson; Peter Budai; build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> On 2017-10-05 10:10, Erik Joelsson wrote: >>>> Hello Peter, >>>> >>>> >>>> On 2017-10-04 21:15, Peter Budai wrote: >>>>> Hi Magnus, >>>>> >>>>> Thanks for the quick reply I?ll check these patches with msys2. >>>>> >>>>> Let me specify with more details what I?d like to achieve: I?d like >>>>> to build OpenJDK9 with MSYS2 MINGW64 environment using gcc toolchain. >>>>> (I?m not sure how familiar are you with MSYS2, but there are 3 >>>>> different environments: MSYS2, MINGW32 and MINGW64). In theory >>>>> MINGW64 with gcc is the closes you can get on Windows platform as a >>>>> gcc unix like build environment, which produces still a native 64-bit >>>>> executable on Windows. >>>>> >>>>> I?m not very familiar with OpenJDK yet, so therefore I?d like to hear >>>>> your opinion: how realistic is that? >>>> Sorry to disappoint, but I would say that requires major work. There >>>> is a strong historic assumption that windows builds are done using >>>> Visual Studio. We have abstracted away some of it in configure (see >>>> TOOLCHAIN_TYPE), but it's very far from enough to change compiler >>>> environment for a Windows build. The native sources are also bound to >>>> make a lot of such assumptions. I would expect the changes needed to >>>> be in the thousands of lines of code. >>> I agree that it requires hard work (even if "thousands" might be an >>> overestimation I think, but "hundreds" is not enough, so it's the right >>> magnitude). On the other hand, it would be really good if we did sort >>> things out, so that we had proper conditions based on OS vs >>> compiler/toolchain. >>> >>> If you really want to start, the first thing is to patch toolchain.m4 to >>> VALID_TOOLCHAINS_windows="microsoft gcc" >>> and then call configure using "bash configure --with-toolchain-type=gcc". >>> >>> As Erik, I doubt you will come very far before things starts tumbling down. >>> >>>> When we say supporting the build in msys2 instead of cygwin, we just >>>> mean using msys2 as the unix emulating layer for our tools like >>>> make/bash/grep/sed etc. >>>> >>>> One think I have done successfully is running the build in WSL >>>> (Windows Subsystem for Linux), but that isn't all that helpful as WSL >>>> for practical purposes is more or less like running Linux in a VM, so >>>> the build sees a Linux system and builds a Linux binary. >>>>> As a side note: with MINGW64 I have managed to run configure phase >>>>> successfully for OpenJDK. The compile process has also started and >>>>> went for a while, but interestingly I run into some kind of race >>>>> conditions as make stopped with an error. Using LOG=debug I have fond >>>>> the failing line and then copying the failed command and pasting it >>>>> to the bash prompt it successfully generated the output target, and >>>>> then the build process run further when a similar situation happened. >>>>> Also pasting the failed command run in the bash without any problem, >>>>> and build continued? until the next. >>>> Without seeing the errors I can't say much. I very much doubt that you >>>> are running with gcc as the compiler though. Configure isn't easily >>>> fooled into using a different compiler to what it prefers, and I would >>>> expect things to crash and burn pretty early if you actually did. >>>> >>>> /Erik >>>>> I have tried to run make JOBS=1, but did not help, strangely I have >>>>> still seen in the log make[3] and make[4] logs which suggested that >>>>> there are more than one make jobs were running. Also tried .configure >>>>> --with-output-sync=recurse without success (same symptoms) >>>>> >>>>> Let me know your thoughts. >>>>> >>>>> Best regards, >>>>> >>>>> Peter >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Magnus Ihse Bursie >>>>> Sent: Wednesday, October 4, 2017 1:04 AM >>>>> To: Peter Budai; >>>>> build-dev at openjdk.java.net >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> Actually, it wasn't so much remaining trouble. :-) I fired up msys2 and >>>>> checked out where I left off. It turned out that the remaining snag was >>>>> that msys2 tries to convert command lines automatically, from "unix" >>>>> style paths to "windows" style paths. Unfortunately, it does not do this >>>>> very well and it breaks all sorts of things. We already have a FIXPATH >>>>> solution in place which deals with this, so basically all I had to do >>>>> was disable this (by setting MSYS2_ARG_CONV_EXCL to "*"). However, this >>>>> broke our cygpath replacement hack (!) so I had to disable it there. >>>>> Sigh. Anyway, with those fixes it ran and worked well. (I also >>>>> discovered and fixed a bug related to how we set up the FIXPATH variable >>>>> on msys, but it only triggers in certain circumstances). >>>>> >>>>> With this patch I now jdk9 seems to build fine on msys2. It should apply >>>>> cleanly on jdk9/jdk9. Since it turned out to be so trivial, I'll try to >>>>> get it in in jdk10. >>>>> >>>>> Here's the patch if you want to apply it yourself: >>>>> >>>>> diff -r a08cbfc0e4ec common/autoconf/basics_windows.m4 >>>>> --- a/common/autoconf/basics_windows.m4 Thu Aug 03 18:56:56 2017 >>>>> +0000 >>>>> +++ b/common/autoconf/basics_windows.m4 Wed Oct 04 00:53:58 2017 >>>>> +0200 >>>>> @@ -42,7 +42,7 @@ >>>>> windows_path=`$CYGPATH -m "$unix_path"` >>>>> $1="$windows_path" >>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then >>>>> - windows_path=`cmd //c echo $unix_path` >>>>> + windows_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $unix_path` >>>>> $1="$windows_path" >>>>> fi >>>>> ]) >>>>> @@ -136,6 +136,16 @@ >>>>> fi >>>>> ]) >>>>> >>>>> +AC_DEFUN([BASIC_MSYS_UPDATE_FIXPATH], >>>>> +[ >>>>> + # Take all collected prefixes and turn them into a >>>>> -m/c/foo@/c/bar at ... command line >>>>> + # @ was chosen as separator to minimize risk of other tools messing >>>>> around with it >>>>> + all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >>>>> + | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>> + fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >>>>> + FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>> +]) >>>>> + >>>>> AC_DEFUN([BASIC_FIXUP_PATH_MSYS], >>>>> [ >>>>> path="[$]$1" >>>>> @@ -143,7 +153,7 @@ >>>>> new_path="$path" >>>>> if test "x$has_colon" = x; then >>>>> # Not in mixed or Windows style, start by that. >>>>> - new_path=`cmd //c echo $path` >>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $path` >>>>> fi >>>>> >>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>> @@ -155,6 +165,8 @@ >>>>> >>>>> # Save the first 10 bytes of this path to the storage, so fixpath >>>>> can work. >>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>> "${new_path:0:10}") >>>>> + # We might need to re-evaluate FIXPATH. >>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>> ]) >>>>> >>>>> AC_DEFUN([BASIC_FIXUP_EXECUTABLE_CYGWIN], >>>>> @@ -293,7 +305,7 @@ >>>>> # Do not save /bin paths to all_fixpath_prefixes! >>>>> else >>>>> # Not in mixed or Windows style, start by that. >>>>> - new_path=`cmd //c echo $new_path` >>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $new_path` >>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>> # Output is in $new_path >>>>> BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(new_path) >>>>> @@ -302,6 +314,8 @@ >>>>> >>>>> # Save the first 10 bytes of this path to the storage, so fixpath >>>>> can work. >>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>> "${new_path:0:10}") >>>>> + # We might need to re-evaluate FIXPATH. >>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>> fi >>>>> ]) >>>>> >>>>> @@ -347,6 +361,10 @@ >>>>> WINDOWS_ENV_VENDOR='msys' >>>>> WINDOWS_ENV_VERSION="$MSYS_VERSION" >>>>> >>>>> + # Prohibit msys2 path conversion from trying to be "intelligent", >>>>> and rely >>>>> + # on fixpath instead. >>>>> + export MSYS2_ARG_CONV_EXCL="*" >>>>> + >>>>> AC_MSG_CHECKING([msys root directory as unix-style path]) >>>>> # The cmd output ends with Windows line endings (CR/LF), the grep >>>>> command will strip that away >>>>> MSYS_ROOT_PATH=`cd / ; cmd /c cd | $GREP ".*"` >>>>> @@ -391,10 +409,7 @@ >>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.msys; then >>>>> # Take all collected prefixes and turn them into a >>>>> -m/c/foo@/c/bar at ... command line >>>>> # @ was chosen as separator to minimize risk of other tools >>>>> messing around with it >>>>> - all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >>>>> - | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>> - fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >>>>> - FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>> fi >>>>> FIXPATH_SRC_W="$FIXPATH_SRC" >>>>> FIXPATH_BIN_W="$FIXPATH_BIN" >>>>> diff -r a08cbfc0e4ec common/autoconf/build-aux/config.sub >>>>> --- a/common/autoconf/build-aux/config.sub Thu Aug 03 18:56:56 >>>>> 2017 +0000 >>>>> +++ b/common/autoconf/build-aux/config.sub Wed Oct 04 00:53:58 >>>>> 2017 +0200 >>>>> @@ -30,7 +30,7 @@ >>>>> DIR=`dirname $0` >>>>> >>>>> # First, filter out everything that doesn't begin with "aarch64-" >>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>> . $DIR/autoconf-config.sub "$@" >>>>> # autoconf-config.sub exits, so we never reach here, but just in >>>>> # case we do: >>>>> @@ -38,13 +38,17 @@ >>>>> fi >>>>> >>>>> while test $# -gt 0 ; do >>>>> - case $1 in >>>>> + case $1 in >>>>> -- ) # Stop option processing >>>>> shift; break ;; >>>>> aarch64-* ) >>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>> sub_args="$sub_args $config" >>>>> shift; ;; >>>>> + *-msys ) >>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>> + sub_args="$sub_args $config" >>>>> + shift; ;; >>>>> - ) # Use stdin as input. >>>>> sub_args="$sub_args $1" >>>>> shift; break ;; >>>>> diff -r a08cbfc0e4ec common/autoconf/spec.gmk.in >>>>> --- a/common/autoconf/spec.gmk.in Thu Aug 03 18:56:56 2017 +0000 >>>>> +++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 +0200 >>>>> @@ -120,6 +120,13 @@ >>>>> # On Windows, the Visual Studio toolchain needs the PATH to be >>>>> adjusted >>>>> # to include Visual Studio tools (this needs to be in cygwin/msys >>>>> style). >>>>> export PATH:=@VS_PATH@ >>>>> + >>>>> +endif >>>>> + >>>>> +ifeq ($(OPENJDK_TARGET_OS_ENV), windows.msys) >>>>> + # On msys2, prohibit msys path conversion from trying to be >>>>> + # "intelligent", and rely on fixpath instead. >>>>> + export MSYS2_ARG_CONV_EXCL:=* >>>>> endif >>>>> >>>>> SYSROOT_CFLAGS := @SYSROOT_CFLAGS@ >>>>> >>>>> /Magnus >>>>> >>>>> On 2017-10-03 22:34, Magnus Ihse Bursie wrote: >>>>>> I gave msys2 a shot some time ago, but it ended up too much trouble. >>>>>> I'll share some of my notes from that attempt, for what it's worth. >>>>>> >>>>>> To install package X/Y, run "pacman -S X/Y". Missing tools and >>>>>> packages where to find them: >>>>>> cmp: msys/diffutils >>>>>> tar: msys/tar >>>>>> make: msys/make >>>>>> unzip: msys/unzip >>>>>> zip: msys/zip >>>>>> >>>>>> config.sub reports msys as "x86_64-pc-mingw32" but msys2 as >>>>>> "x86_64-pc-msys". This patch adds postprocessing in "our" config.sub >>>>>> to report msys2 similar to msys. (Opinions, including my own :-) may >>>>>> vary if this really is the best way..) >>>>>> >>>>>> diff -r b88023f46daa common/autoconf/build-aux/config.sub >>>>>> --- a/common/autoconf/build-aux/config.sub Fri Jan 27 10:15:41 >>>>>> 2017 +0100 >>>>>> +++ b/common/autoconf/build-aux/config.sub Fri Feb 03 05:00:25 >>>>>> 2017 -0700 >>>>>> @@ -30,7 +30,7 @@ >>>>>> DIR=`dirname $0` >>>>>> >>>>>> # First, filter out everything that doesn't begin with "aarch64-" >>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>> . $DIR/autoconf-config.sub "$@" >>>>>> # autoconf-config.sub exits, so we never reach here, but just in >>>>>> # case we do: >>>>>> @@ -45,6 +45,10 @@ >>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>> sub_args="$sub_args $config" >>>>>> shift; ;; >>>>>> + *-msys ) >>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>> + sub_args="$sub_args $config" >>>>>> + shift; ;; >>>>>> - ) # Use stdin as input. >>>>>> sub_args="$sub_args $1" >>>>>> shift; break ;; >>>>>> >>>>>> If I remember correctly, this got me past the configure stage at the >>>>>> time. >>>>>> >>>>>> I don't think it's very hard to get it to work on msys2, I just ran >>>>>> into one snag too many and didn't think msys2 would be used by anyone. >>>>>> >>>>>> /Magnus >>>>>> >>>>>> On 2017-10-03 17:20, Peter Budai wrote: >>>>>>> Hello, >>>>>>> >>>>>>> According to >>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/common/doc/building.html >>>>>>> >>>>>>> ?msys2 and the new Windows Subsystem for Linux (WSL) would likely be >>>>>>> possible to support in a future version but that would require a >>>>>>> community effort to implement? >>>>>>> >>>>>>> I?d like to help making the OpenJDK 9 build working on msys2. What is >>>>>>> the best way to move forward? Is there a similar effort in progress? >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > > > From erik.joelsson at oracle.com Thu Nov 2 00:13:51 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 1 Nov 2017 17:13:51 -0700 Subject: RFR: JDK-8190410 Help.gmk is not updated after consolidation In-Reply-To: <57ff5d11-ba76-3817-15db-3ac3fcc5c805@oracle.com> References: <57ff5d11-ba76-3817-15db-3ac3fcc5c805@oracle.com> Message-ID: Looks good. /Erik On 2017-10-31 06:13, Magnus Ihse Bursie wrote: > The help text for "make help" still mentions the old repos. > > Also fixed some other minor issues. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190410 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8190410-update-make-help/webrev.01 > > /Magnus From erik.joelsson at oracle.com Fri Nov 3 20:34:25 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 3 Nov 2017 13:34:25 -0700 Subject: RFR: JDK-8190725: Freetype license file provided with configure not included in images Message-ID: <5d66fd8f-f60e-c226-b191-79728db771e2@oracle.com> The inclusion of the freetype license file has stopped working. For the -ri windows profile, we set --with-freetype-license, but the makefile logic for creating the java.desktop jmod is broken and doesn't pick it up. This patch fixes the FindModuleLegalDirs macro so that support/modules_legal/$MODULE gets included as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8190725 Webrev: http://cr.openjdk.java.net/~erikj/8190725/webrev.01/ /Erik From tim.bell at oracle.com Fri Nov 3 21:40:10 2017 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 03 Nov 2017 14:40:10 -0700 Subject: RFR: JDK-8190725: Freetype license file provided with configure not included in images In-Reply-To: <5d66fd8f-f60e-c226-b191-79728db771e2@oracle.com> References: <5d66fd8f-f60e-c226-b191-79728db771e2@oracle.com> Message-ID: <59FCE23A.4040205@oracle.com> Erik: > The inclusion of the freetype license file has stopped working. For the > -ri windows profile, we set --with-freetype-license, but the makefile > logic for creating the java.desktop jmod is broken and doesn't pick it > up. This patch fixes the FindModuleLegalDirs macro so that > support/modules_legal/$MODULE gets included as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190725 > > Webrev: http://cr.openjdk.java.net/~erikj/8190725/webrev.01/ Looks good. /Tim From adsun701 at gmail.com Sat Nov 4 23:26:42 2017 From: adsun701 at gmail.com (Andrew Sun) Date: Sat, 4 Nov 2017 19:26:42 -0400 Subject: Support building OpenJDK on Windows using MSYS2 and MinGW-w64 GCC? Message-ID: Hi everyone, I'm just wondering if OpenJDK could be modified to build on Windows using MSYS2 (free Windows development environment that includes MinGW-w64 and GCC). Currently MSYS2's MinGW-w64 toolchain (including GCC) is unsupported for building OpenJDK, and Visual Studio is required; however, on Linux, GCC is supported. Would there be any implications to such a method? If not, I would be very pleased. MSYS2 uses PKGBUILDs similar to the ones on Arch Linux. Adding a MinGW-w64 PKGBUILD for mingw-w64-jdk*version*-openjdk would be very beneficial to the MSYS2 project. Thanks, Andrew Sun From philip.race at oracle.com Sat Nov 4 23:39:53 2017 From: philip.race at oracle.com (Philip Race) Date: Sat, 04 Nov 2017 16:39:53 -0700 Subject: Support building OpenJDK on Windows using MSYS2 and MinGW-w64 GCC? In-Reply-To: References: Message-ID: <59FE4FC9.50308@oracle.com> Some issues I see here are that - the code has lots of things like #ifdef _MSC_VER .. fixable perhaps, but .. - the Windows SDK which includes the compiler is needed anyway - no one is likely to maintain this .. - Oracle is unlikely to use this for its own builds. So probably not something Oracle would invest in and not sure who would do it and keep it working .. whilst ensuring the VC code is still needed. -phil. On 11/4/17, 4:26 PM, Andrew Sun wrote: > Hi everyone, > > I'm just wondering if OpenJDK could be modified to build on Windows using > MSYS2 (free Windows development environment that includes MinGW-w64 and > GCC). Currently MSYS2's MinGW-w64 toolchain (including GCC) is unsupported > for building OpenJDK, and Visual Studio is required; however, on Linux, GCC > is supported. > Would there be any implications to such a method? If not, I would be very > pleased. MSYS2 uses PKGBUILDs similar to the ones on Arch Linux. Adding a > MinGW-w64 PKGBUILD for mingw-w64-jdk*version*-openjdk would be very > beneficial to the MSYS2 project. > > Thanks, > > Andrew Sun From adsun701 at gmail.com Sun Nov 5 13:20:45 2017 From: adsun701 at gmail.com (Andrew Sun) Date: Sun, 5 Nov 2017 08:20:45 -0500 Subject: Support building OpenJDK on Windows using MSYS2 and MinGW-w64 GCC? In-Reply-To: References: <59FE4FC9.50308@oracle.com> Message-ID: Okay, but MinGW-w64 offers much of the same headers and functions that the Windows SDK includes. The goal of MinGW-w64 is to track as many Windows APIs as possible, which includes those found in the Windows SDK, and implement them in GCC, so that instead of the Windows SDK, GCC can be used. The second point you mentioned could be solved this way. The only potential problem is that bootstrapping OpenJDK would require a previous, presumably Visual Studio compiled JDK, which would probably lead to ABI incompatability and name-mangling. MinGW-w64, however, includes libmangle, which can mitigate this problem. Accidentally sent this message to individual instead of mailing list, sorry. Thanks, Andrew Sun On Sun, Nov 5, 2017 at 8:14 AM, Andrew Sun wrote: > Okay, but MinGW-w64 offers much of the same headers and functions that the > Windows SDK includes. The goal of MinGW-w64 is to track as many Windows > APIs as possible, which includes those found in the Windows SDK, and > implement them in GCC, so that instead of the Windows SDK, GCC can be used. > The second point you mentioned could be solved this way. The only potential > problem is that bootstrapping OpenJDK would require a previous, presumably > Visual Studio compiled JDK, which would probably lead to ABI > incompatability and name-mangling. MinGW-w64, however, includes libmangle, > which can mitigate this problem. > > Thanks, > > Andrew Sun > > On Sat, Nov 4, 2017 at 7:39 PM, Philip Race > wrote: > >> Some issues I see here are that >> - the code has lots of things like #ifdef _MSC_VER .. fixable perhaps, >> but .. >> - the Windows SDK which includes the compiler is needed anyway >> - no one is likely to maintain this .. >> - Oracle is unlikely to use this for its own builds. >> >> So probably not something Oracle would invest in and not sure who would >> do it and keep it working .. whilst ensuring the VC code is still needed. >> >> -phil. >> >> >> On 11/4/17, 4:26 PM, Andrew Sun wrote: >> >>> Hi everyone, >>> >>> I'm just wondering if OpenJDK could be modified to build on Windows using >>> MSYS2 (free Windows development environment that includes MinGW-w64 and >>> GCC). Currently MSYS2's MinGW-w64 toolchain (including GCC) is >>> unsupported >>> for building OpenJDK, and Visual Studio is required; however, on Linux, >>> GCC >>> is supported. >>> Would there be any implications to such a method? If not, I would be very >>> pleased. MSYS2 uses PKGBUILDs similar to the ones on Arch Linux. Adding a >>> MinGW-w64 PKGBUILD for mingw-w64-jdk*version*-openjdk would be very >>> beneficial to the MSYS2 project. >>> >>> Thanks, >>> >>> Andrew Sun >>> >> > From david.holmes at oracle.com Mon Nov 6 03:38:05 2017 From: david.holmes at oracle.com (David Holmes) Date: Mon, 6 Nov 2017 13:38:05 +1000 Subject: Support building OpenJDK on Windows using MSYS2 and MinGW-w64 GCC? In-Reply-To: References: Message-ID: Hi Andrew, Check the build-dev archives for October for a thread "Building OpenJDK9 on MSYS2". This is actively being worked on. David On 5/11/2017 9:26 AM, Andrew Sun wrote: > Hi everyone, > > I'm just wondering if OpenJDK could be modified to build on Windows using > MSYS2 (free Windows development environment that includes MinGW-w64 and > GCC). Currently MSYS2's MinGW-w64 toolchain (including GCC) is unsupported > for building OpenJDK, and Visual Studio is required; however, on Linux, GCC > is supported. > Would there be any implications to such a method? If not, I would be very > pleased. MSYS2 uses PKGBUILDs similar to the ones on Arch Linux. Adding a > MinGW-w64 PKGBUILD for mingw-w64-jdk*version*-openjdk would be very > beneficial to the MSYS2 project. > > Thanks, > > Andrew Sun > From adsun701 at gmail.com Tue Nov 7 12:18:27 2017 From: adsun701 at gmail.com (Andrew Sun) Date: Tue, 7 Nov 2017 05:18:27 -0700 (MST) Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: <4da0c111-f13f-a814-09e2-906a02eaacb6@oracle.com> <5D41C052-D10F-4E7C-B6A7-4759274D5753@oracle.com> <565779B5-B2EE-40DC-8587-0B21AC788406@oracle.com> Message-ID: <1510057107376-0.post@n7.nabble.com> I tried Peter Budai's patches from mingw-w64-openjdk branch, but it failed due to using dlfcn.h instead of windows.h in jdk9-jdk-9+181/hotspot/src/share/vm/utilities/globalDefinitions_gcc.hpp. After guarding dlfcn.h with #ifdef linux #endif and adding the windows.h include, it compiled fine until a symlink error, "File name too long", failing the ZipSource.gmk and the entire build. Andrew Sun -- Sent from: http://openjdk.5641.n7.nabble.com/OpenJDK-Build-Infrastructure-f75522.html From jesper.wilhelmsson at oracle.com Tue Nov 7 17:05:43 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 7 Nov 2017 18:05:43 +0100 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 In-Reply-To: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> References: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Message-ID: Including build-dev. > On 7 Nov 2017, at 17:56, jesper.wilhelmsson at oracle.com wrote: > > Hi, > > Please review this minor change to use the latest jtreg version in HotSpot testing. > This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 > > Patch: > > diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js > --- a/make/conf/jib-profiles.js > +++ b/make/conf/jib-profiles.js > @@ -1060,7 +1060,7 @@ > jtreg: { > server: "javare", > revision: "4.2", > - build_number: "b09", > + build_number: "b10", > checksum_file: "MD5_VALUES", > file: "jtreg_bin-4.2.zip", > environment_name: "JT_HOME", > > Thanks, > /Jesper > From jesper.wilhelmsson at oracle.com Tue Nov 7 17:06:24 2017 From: jesper.wilhelmsson at oracle.com (jesper.wilhelmsson at oracle.com) Date: Tue, 7 Nov 2017 18:06:24 +0100 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 In-Reply-To: References: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Message-ID: <54B25C39-892B-47CA-A697-D23B484E5709@oracle.com> Thanks! /Jesper > On 7 Nov 2017, at 18:05, Daniel D. Daugherty wrote: > > Thumbs up! > > Dan > > > On 11/7/17 11:56 AM, jesper.wilhelmsson at oracle.com wrote: >> Hi, >> >> Please review this minor change to use the latest jtreg version in HotSpot testing. >> This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 >> >> Patch: >> >> diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js >> --- a/make/conf/jib-profiles.js >> +++ b/make/conf/jib-profiles.js >> @@ -1060,7 +1060,7 @@ >> jtreg: { >> server: "javare", >> revision: "4.2", >> - build_number: "b09", >> + build_number: "b10", >> checksum_file: "MD5_VALUES", >> file: "jtreg_bin-4.2.zip", >> environment_name: "JT_HOME", >> >> Thanks, >> /Jesper >> > From erik.joelsson at oracle.com Tue Nov 7 18:22:42 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 Nov 2017 10:22:42 -0800 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 In-Reply-To: References: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Message-ID: <93da0fac-e7f4-b79c-51b9-a9b16f696166@oracle.com> Looks good. /Erik On 11/7/17 9:05 AM, jesper.wilhelmsson at oracle.com wrote: > Including build-dev. > >> On 7 Nov 2017, at 17:56, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> Please review this minor change to use the latest jtreg version in HotSpot testing. >> This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 >> >> Patch: >> >> diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js >> --- a/make/conf/jib-profiles.js >> +++ b/make/conf/jib-profiles.js >> @@ -1060,7 +1060,7 @@ >> jtreg: { >> server: "javare", >> revision: "4.2", >> - build_number: "b09", >> + build_number: "b10", >> checksum_file: "MD5_VALUES", >> file: "jtreg_bin-4.2.zip", >> environment_name: "JT_HOME", >> >> Thanks, >> /Jesper >> From erik.joelsson at oracle.com Wed Nov 8 00:46:50 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 Nov 2017 16:46:50 -0800 Subject: RFR: JDK-8190735: Define all base artifacts for all open/open-debug profiles Message-ID: When first defining artifacts for build profiles in Jib, I only defined those that we are actually publishing in promoted builds. With Mach 5 we now have requirements on being able to test open only builds as well as their debug variants.This patch removes the special case definitions of artifacts for the open and open-debug profiles and instead derives them from the main profiles. I also removed the no longer needed "compact-profiles" target from linux-x86-open. Webrev: http://cr.openjdk.java.net/~erikj/8190735/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8190735 /Erik From erik.joelsson at oracle.com Wed Nov 8 00:58:27 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 7 Nov 2017 16:58:27 -0800 Subject: RFR: JDK-8190744: xattr: No such file LICENSE files Message-ID: <49dcbce5-8628-fd0d-d6a7-3afd92baf57a@oracle.com> After my recent changes to the install-file macro and using of SetupCopyFiles to generate the mac specific images, we have started seeing errors like this in the build on mac: xattr: No such file: /d/jdk/open/build/macosx-x86_64-normal-server-release/images/jre-bundle/jre-10.jre/Contents/Home/legal/java.activation/LICENSE This is caused by xattr being run on a symlink whose target does not yet exist, which in turn is caused by concurrent execution. The simple fix is to tell xattr to process the symlink itself rather than the target, using the -s switch. Bug: https://bugs.openjdk.java.net/browse/JDK-8190744 Patch: diff -r be620a591379 make/common/MakeBase.gmk --- a/make/common/MakeBase.gmk Mon Oct 30 21:23:10 2017 +0100 +++ b/make/common/MakeBase.gmk Tue Nov 07 16:55:19 2017 -0800 @@ -529,7 +529,7 @@ $(call MakeDir, $(@D)) $(RM) '$(call DecodeSpace, $@)' $(CP) -fRP '$(call DecodeSpace, $<)' '$(call DecodeSpace, $@)' - if [ -n "`$(XATTR) -l '$(call DecodeSpace, $@)'`" ]; then $(XATTR) -c '$(call DecodeSpace, $@)'; fi + if [ -n "`$(XATTR) -ls '$(call DecodeSpace, $@)'`" ]; then $(XATTR) -cs '$(call DecodeSpace, $@)'; fi endef else define install-file /Erik From david.holmes at oracle.com Wed Nov 8 02:04:04 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 8 Nov 2017 12:04:04 +1000 Subject: RFR(xs): JDK-8190865 - Require jtreg 4.2 b10 In-Reply-To: References: <5580A648-9E19-4412-BC07-CB7F16667FED@oracle.com> Message-ID: On 8/11/2017 3:05 AM, jesper.wilhelmsson at oracle.com wrote: > Including build-dev. > >> On 7 Nov 2017, at 17:56, jesper.wilhelmsson at oracle.com wrote: >> >> Hi, >> >> Please review this minor change to use the latest jtreg version in HotSpot testing. >> This should get rid of the SocketTimeoutExceptions that we currently see in the HotSpot nightly. More importantly it fixes the java/time TCK test failures caused by jtreg b09! But that fix needs to go into jdk/jdk not jdk/hs as CI is broken since the hs integration! David >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190865 >> >> Patch: >> >> diff --git a/make/conf/jib-profiles.js b/make/conf/jib-profiles.js >> --- a/make/conf/jib-profiles.js >> +++ b/make/conf/jib-profiles.js >> @@ -1060,7 +1060,7 @@ >> jtreg: { >> server: "javare", >> revision: "4.2", >> - build_number: "b09", >> + build_number: "b10", >> checksum_file: "MD5_VALUES", >> file: "jtreg_bin-4.2.zip", >> environment_name: "JT_HOME", >> >> Thanks, >> /Jesper >> > From me at md-5.net Wed Nov 8 06:31:57 2017 From: me at md-5.net (Michael D) Date: Wed, 8 Nov 2017 06:31:57 +0000 Subject: Build documentation (building.md) needs updating as a result of 8170681 Message-ID: <0100015f9a5400ec-1470e583-eaf3-4d1f-8dfc-c6a3d174ee3f-000000@email.amazonses.com> Hi All, Couldn't find a documentation mailing list so I figured I'd drop this here since it seems most relevant to the build system. As a result of last weeks change for 8170681 - removal of fontconfig from the source tree, fontconfig was introduced as a build depend (libfontconfig1-dev on Debian). As such doc/building.md should be updated to include some of this info. I've prepared a cookie cutter patch here https://patch-diff.githubusercontent.com/raw/md-5/OpenJDK/pull/2.patch but you are more than welcome to DIY. Thanks Michael From Alan.Bateman at oracle.com Wed Nov 8 07:05:13 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 8 Nov 2017 07:05:13 +0000 Subject: RFR: JDK-8190744: xattr: No such file LICENSE files In-Reply-To: <49dcbce5-8628-fd0d-d6a7-3afd92baf57a@oracle.com> References: <49dcbce5-8628-fd0d-d6a7-3afd92baf57a@oracle.com> Message-ID: On 08/11/2017 00:58, Erik Joelsson wrote: > After my recent changes to the install-file macro and using of > SetupCopyFiles to generate the mac specific images, we have started > seeing errors like this in the build on mac: > > xattr: No such file: > /d/jdk/open/build/macosx-x86_64-normal-server-release/images/jre-bundle/jre-10.jre/Contents/Home/legal/java.activation/LICENSE > > This is caused by xattr being run on a symlink whose target does not > yet exist, which in turn is caused by concurrent execution. The simple > fix is to tell xattr to process the symlink itself rather than the > target, using the -s switch. I've seen this several times so good to have this fixed. The change looks good. -Alan From tim.bell at oracle.com Wed Nov 8 18:41:53 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 08 Nov 2017 10:41:53 -0800 Subject: RFR: JDK-8190744: xattr: No such file LICENSE files In-Reply-To: References: <49dcbce5-8628-fd0d-d6a7-3afd92baf57a@oracle.com> Message-ID: <5A034FF1.0@oracle.com> Erik: On 11/07/17 23:05, Alan Bateman wrote: > > > On 08/11/2017 00:58, Erik Joelsson wrote: >> After my recent changes to the install-file macro and using of >> SetupCopyFiles to generate the mac specific images, we have started >> seeing errors like this in the build on mac: >> >> xattr: No such file: >> /d/jdk/open/build/macosx-x86_64-normal-server-release/images/jre-bundle/jre-10.jre/Contents/Home/legal/java.activation/LICENSE >> >> >> This is caused by xattr being run on a symlink whose target does not >> yet exist, which in turn is caused by concurrent execution. The simple >> fix is to tell xattr to process the symlink itself rather than the >> target, using the -s switch. > I've seen this several times so good to have this fixed. The change > looks good. > > -Alan Looks good to me as well. /Tim From tim.bell at oracle.com Wed Nov 8 18:49:14 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 08 Nov 2017 10:49:14 -0800 Subject: RFR: JDK-8190735: Define all base artifacts for all open/open-debug profiles In-Reply-To: References: Message-ID: <5A0351AA.1080209@oracle.com> Erik: > When first defining artifacts for build profiles in Jib, I only defined > those that we are actually publishing in promoted builds. With Mach 5 we > now have requirements on being able to test open only builds as well as > their debug variants.This patch removes the special case definitions of > artifacts for the open and open-debug profiles and instead derives them > from the main profiles. I also removed the no longer needed > "compact-profiles" target from linux-x86-open. > > Webrev: http://cr.openjdk.java.net/~erikj/8190735/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190735 Looks good. /Tim From thomas.stuefe at gmail.com Thu Nov 9 06:32:58 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 9 Nov 2017 07:32:58 +0100 Subject: Default value for -with_native_debug_symbols on Windows useful? Message-ID: Hi all, I could reframe the subject matter as "how do you internally at Oracle build the Windows JDK"? I had several discussions with people from Oracle about missing callstacks in hs-err files on Windows generated in tests which run at Oracle. I recently did JDK-8185712, which improves the Windows symbol decoder, so I feel somewhat responsible. However, I was never able to reproduce anything - here at SAP, we get nice callstacks and all works well. A simple explanation may be that you at Oracle either remove the debug info (pdb files) from the images before testing and/or build with -with_native_debug_symbols=zipped . The latter zips the pdb files, which in that form are useless. Which is it? For that matter, do you think -with_native_debug_symbols=zipped makes sense on Windows? Would it not make more sense to make the default -with_native_debug_symbols=external on Windows, to have pdb files ready for debugging and testing? Thanks, Thomas From erik.joelsson at oracle.com Thu Nov 9 18:58:22 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 9 Nov 2017 10:58:22 -0800 Subject: Default value for -with_native_debug_symbols on Windows useful? In-Reply-To: References: Message-ID: <9e3ed379-5ecb-3c4a-a555-9d1304d6f64d@oracle.com> I agree that the zipped debug symbols are just annoying and should be removed. /Erik On 2017-11-08 22:32, Thomas St?fe wrote: > Hi all, > > I could reframe the subject matter as "how do you internally at Oracle > build the Windows JDK"? > > I had several discussions with people from Oracle about missing callstacks > in hs-err files on Windows generated in tests which run at Oracle. > > I recently did JDK-8185712, which improves the Windows symbol decoder, so I > feel somewhat responsible. However, I was never able to reproduce anything > - here at SAP, we get nice callstacks and all works well. > > A simple explanation may be that you at Oracle either remove the debug info > (pdb files) from the images before testing and/or build > with -with_native_debug_symbols=zipped . The latter zips the pdb files, > which in that form are useless. Which is it? > > For that matter, do you think -with_native_debug_symbols=zipped makes sense > on Windows? Would it not make more sense to make the default > -with_native_debug_symbols=external on Windows, to have pdb files ready for > debugging and testing? > > Thanks, Thomas From thomas.stuefe at gmail.com Thu Nov 9 23:26:52 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 09 Nov 2017 23:26:52 +0000 Subject: Default value for -with_native_debug_symbols on Windows useful? In-Reply-To: <9e3ed379-5ecb-3c4a-a555-9d1304d6f64d@oracle.com> References: <9e3ed379-5ecb-3c4a-a555-9d1304d6f64d@oracle.com> Message-ID: Do you think this for all platforms or just for Windows? With removed, do you really mean the feature removed, not just the default changed? Thomas On Thu 9. Nov 2017 at 19:58, Erik Joelsson wrote: > I agree that the zipped debug symbols are just annoying and should be > removed. > > /Erik > > > On 2017-11-08 22:32, Thomas St?fe wrote: > > Hi all, > > > > I could reframe the subject matter as "how do you internally at Oracle > > build the Windows JDK"? > > > > I had several discussions with people from Oracle about missing > callstacks > > in hs-err files on Windows generated in tests which run at Oracle. > > > > I recently did JDK-8185712, which improves the Windows symbol decoder, > so I > > feel somewhat responsible. However, I was never able to reproduce > anything > > - here at SAP, we get nice callstacks and all works well. > > > > A simple explanation may be that you at Oracle either remove the debug > info > > (pdb files) from the images before testing and/or build > > with -with_native_debug_symbols=zipped . The latter zips the pdb files, > > which in that form are useless. Which is it? > > > > For that matter, do you think -with_native_debug_symbols=zipped makes > sense > > on Windows? Would it not make more sense to make the default > > -with_native_debug_symbols=external on Windows, to have pdb files ready > for > > debugging and testing? > > > > Thanks, Thomas > > From erik.joelsson at oracle.com Thu Nov 9 23:52:24 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 9 Nov 2017 15:52:24 -0800 Subject: Default value for -with_native_debug_symbols on Windows useful? In-Reply-To: References: <9e3ed379-5ecb-3c4a-a555-9d1304d6f64d@oracle.com> Message-ID: <54909f49-5f51-2d15-fdc7-d4ceb5dacdd1@oracle.com> Hello, On 2017-11-09 15:26, Thomas St?fe wrote: > Do you think this for all platforms or just for Windows? With removed, > do you really mean the feature removed, not just the default changed? > I mean for all platforms. I don't see any point in the build wasting time on zipping up the debug symbols which also makes them unusable. If someone cries out we could leave the feature in, but I would much rather not. Note that the bundle target has to unzip them again to put them in the symbols bundle, which is the final deliverable of the symbols. Historically there have been various reasons for this zipping internally to Oracle, but I don't think any of those reasons hold up anymore in our current JDK 10 infrastructure. /Erik > Thomas > > On Thu 9. Nov 2017 at 19:58, Erik Joelsson > wrote: > > I agree that the zipped debug symbols are just annoying and should be > removed. > > /Erik > > > On 2017-11-08 22:32, Thomas St?fe wrote: > > Hi all, > > > > I could reframe the subject matter as "how do you internally at > Oracle > > build the Windows JDK"? > > > > I had several discussions with people from Oracle about missing > callstacks > > in hs-err files on Windows generated in tests which run at Oracle. > > > > I recently did JDK-8185712, which improves the Windows symbol > decoder, so I > > feel somewhat responsible. However, I was never able to > reproduce anything > > - here at SAP, we get nice callstacks and all works well. > > > > A simple explanation may be that you at Oracle either remove the > debug info > > (pdb files) from the images before testing and/or build > > with -with_native_debug_symbols=zipped . The latter zips the pdb > files, > > which in that form are useless. Which is it? > > > > For that matter, do you think -with_native_debug_symbols=zipped > makes sense > > on Windows? Would it not make more sense to make the default > > -with_native_debug_symbols=external on Windows, to have pdb > files ready for > > debugging and testing? > > > > Thanks, Thomas > From thomas.stuefe at gmail.com Fri Nov 10 08:01:26 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 10 Nov 2017 09:01:26 +0100 Subject: Default value for -with_native_debug_symbols on Windows useful? In-Reply-To: <54909f49-5f51-2d15-fdc7-d4ceb5dacdd1@oracle.com> References: <9e3ed379-5ecb-3c4a-a555-9d1304d6f64d@oracle.com> <54909f49-5f51-2d15-fdc7-d4ceb5dacdd1@oracle.com> Message-ID: Hi Erik, On Fri, Nov 10, 2017 at 12:52 AM, Erik Joelsson wrote: > Hello, > > On 2017-11-09 15:26, Thomas St?fe wrote: > > Do you think this for all platforms or just for Windows? With removed, do > you really mean the feature removed, not just the default changed? > > I mean for all platforms. I don't see any point in the build wasting time > on zipping up the debug symbols which also makes them unusable. If someone > cries out we could leave the feature in, but I would much rather not. Note > that the bundle target has to unzip them again to put them in the symbols > bundle, which is the final deliverable of the symbols. > > Historically there have been various reasons for this zipping internally > to Oracle, but I don't think any of those reasons hold up anymore in our > current JDK 10 infrastructure. > I am all for it. We never really used that feature. Best Regards, Thomas > > > /Erik > > Thomas > > On Thu 9. Nov 2017 at 19:58, Erik Joelsson > wrote: > >> I agree that the zipped debug symbols are just annoying and should be >> removed. >> >> /Erik >> >> >> On 2017-11-08 22:32, Thomas St?fe wrote: >> > Hi all, >> > >> > I could reframe the subject matter as "how do you internally at Oracle >> > build the Windows JDK"? >> > >> > I had several discussions with people from Oracle about missing >> callstacks >> > in hs-err files on Windows generated in tests which run at Oracle. >> > >> > I recently did JDK-8185712, which improves the Windows symbol decoder, >> so I >> > feel somewhat responsible. However, I was never able to reproduce >> anything >> > - here at SAP, we get nice callstacks and all works well. >> > >> > A simple explanation may be that you at Oracle either remove the debug >> info >> > (pdb files) from the images before testing and/or build >> > with -with_native_debug_symbols=zipped . The latter zips the pdb files, >> > which in that form are useless. Which is it? >> > >> > For that matter, do you think -with_native_debug_symbols=zipped makes >> sense >> > on Windows? Would it not make more sense to make the default >> > -with_native_debug_symbols=external on Windows, to have pdb files >> ready for >> > debugging and testing? >> > >> > Thanks, Thomas >> >> > From erik.helin at oracle.com Fri Nov 10 14:50:41 2017 From: erik.helin at oracle.com (Erik Helin) Date: Fri, 10 Nov 2017 15:50:41 +0100 Subject: Default value for -with_native_debug_symbols on Windows useful? In-Reply-To: References: <9e3ed379-5ecb-3c4a-a555-9d1304d6f64d@oracle.com> <54909f49-5f51-2d15-fdc7-d4ceb5dacdd1@oracle.com> Message-ID: On 11/10/2017 09:01 AM, Thomas St?fe wrote: > Hi Erik, > > On Fri, Nov 10, 2017 at 12:52 AM, Erik Joelsson > wrote: > >> Hello, >> >> On 2017-11-09 15:26, Thomas St?fe wrote: >> >> Do you think this for all platforms or just for Windows? With removed, do >> you really mean the feature removed, not just the default changed? >> >> I mean for all platforms. I don't see any point in the build wasting time >> on zipping up the debug symbols which also makes them unusable. If someone >> cries out we could leave the feature in, but I would much rather not. Note >> that the bundle target has to unzip them again to put them in the symbols >> bundle, which is the final deliverable of the symbols. >> >> Historically there have been various reasons for this zipping internally >> to Oracle, but I don't think any of those reasons hold up anymore in our >> current JDK 10 infrastructure. >> > > I am all for it. We never really used that feature. Could we start by changing the default (for all platforms) to be either 'external' or 'internal' and then work on eventually removing 'zipped'? Thanks, Erik > Best Regards, Thomas > > >> >> >> /Erik >> >> Thomas >> >> On Thu 9. Nov 2017 at 19:58, Erik Joelsson >> wrote: >> >>> I agree that the zipped debug symbols are just annoying and should be >>> removed. >>> >>> /Erik >>> >>> >>> On 2017-11-08 22:32, Thomas St?fe wrote: >>>> Hi all, >>>> >>>> I could reframe the subject matter as "how do you internally at Oracle >>>> build the Windows JDK"? >>>> >>>> I had several discussions with people from Oracle about missing >>> callstacks >>>> in hs-err files on Windows generated in tests which run at Oracle. >>>> >>>> I recently did JDK-8185712, which improves the Windows symbol decoder, >>> so I >>>> feel somewhat responsible. However, I was never able to reproduce >>> anything >>>> - here at SAP, we get nice callstacks and all works well. >>>> >>>> A simple explanation may be that you at Oracle either remove the debug >>> info >>>> (pdb files) from the images before testing and/or build >>>> with -with_native_debug_symbols=zipped . The latter zips the pdb files, >>>> which in that form are useless. Which is it? >>>> >>>> For that matter, do you think -with_native_debug_symbols=zipped makes >>> sense >>>> on Windows? Would it not make more sense to make the default >>>> -with_native_debug_symbols=external on Windows, to have pdb files >>> ready for >>>> debugging and testing? >>>> >>>> Thanks, Thomas >>> >>> >> From thomas.stuefe at gmail.com Fri Nov 10 18:16:14 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Fri, 10 Nov 2017 19:16:14 +0100 Subject: Default value for -with_native_debug_symbols on Windows useful? In-Reply-To: References: <9e3ed379-5ecb-3c4a-a555-9d1304d6f64d@oracle.com> <54909f49-5f51-2d15-fdc7-d4ceb5dacdd1@oracle.com> Message-ID: On Fri, Nov 10, 2017 at 3:50 PM, Erik Helin wrote: > On 11/10/2017 09:01 AM, Thomas St?fe wrote: > >> Hi Erik, >> >> On Fri, Nov 10, 2017 at 12:52 AM, Erik Joelsson > > >> wrote: >> >> Hello, >>> >>> On 2017-11-09 15:26, Thomas St?fe wrote: >>> >>> Do you think this for all platforms or just for Windows? With removed, do >>> you really mean the feature removed, not just the default changed? >>> >>> I mean for all platforms. I don't see any point in the build wasting time >>> on zipping up the debug symbols which also makes them unusable. If >>> someone >>> cries out we could leave the feature in, but I would much rather not. >>> Note >>> that the bundle target has to unzip them again to put them in the symbols >>> bundle, which is the final deliverable of the symbols. >>> >>> Historically there have been various reasons for this zipping internally >>> to Oracle, but I don't think any of those reasons hold up anymore in our >>> current JDK 10 infrastructure. >>> >>> >> I am all for it. We never really used that feature. >> > > Could we start by changing the default (for all platforms) to be either > 'external' or 'internal' and then work on eventually removing 'zipped'? > > Sure. Gives us an easy way back should someone complain :) Cheers, Thomas > Thanks, > Erik > > > Best Regards, Thomas >> >> >> >>> >>> /Erik >>> >>> Thomas >>> >>> On Thu 9. Nov 2017 at 19:58, Erik Joelsson >>> wrote: >>> >>> I agree that the zipped debug symbols are just annoying and should be >>>> removed. >>>> >>>> /Erik >>>> >>>> >>>> On 2017-11-08 22:32, Thomas St?fe wrote: >>>> >>>>> Hi all, >>>>> >>>>> I could reframe the subject matter as "how do you internally at Oracle >>>>> build the Windows JDK"? >>>>> >>>>> I had several discussions with people from Oracle about missing >>>>> >>>> callstacks >>>> >>>>> in hs-err files on Windows generated in tests which run at Oracle. >>>>> >>>>> I recently did JDK-8185712, which improves the Windows symbol decoder, >>>>> >>>> so I >>>> >>>>> feel somewhat responsible. However, I was never able to reproduce >>>>> >>>> anything >>>> >>>>> - here at SAP, we get nice callstacks and all works well. >>>>> >>>>> A simple explanation may be that you at Oracle either remove the debug >>>>> >>>> info >>>> >>>>> (pdb files) from the images before testing and/or build >>>>> with -with_native_debug_symbols=zipped . The latter zips the pdb >>>>> files, >>>>> which in that form are useless. Which is it? >>>>> >>>>> For that matter, do you think -with_native_debug_symbols=zipped makes >>>>> >>>> sense >>>> >>>>> on Windows? Would it not make more sense to make the default >>>>> -with_native_debug_symbols=external on Windows, to have pdb files >>>>> >>>> ready for >>>> >>>>> debugging and testing? >>>>> >>>>> Thanks, Thomas >>>>> >>>> >>>> >>>> >>> From magnus.ihse.bursie at oracle.com Mon Nov 13 12:52:57 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 13 Nov 2017 13:52:57 +0100 Subject: RFR: JDK-8190725: Freetype license file provided with configure not included in images In-Reply-To: <5d66fd8f-f60e-c226-b191-79728db771e2@oracle.com> References: <5d66fd8f-f60e-c226-b191-79728db771e2@oracle.com> Message-ID: <9a810010-deeb-dd11-ec67-afda5c1665f9@oracle.com> On 2017-11-03 21:34, Erik Joelsson wrote: > The inclusion of the freetype license file has stopped working. For > the -ri windows profile, we set --with-freetype-license, but the > makefile logic for creating the java.desktop jmod is broken and > doesn't pick it up. This patch fixes the FindModuleLegalDirs macro so > that support/modules_legal/$MODULE gets included as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190725 > > Webrev: http://cr.openjdk.java.net/~erikj/8190725/webrev.01/ Looks good to me. /Magnus > > /Erik > From volker.simonis at gmail.com Mon Nov 13 16:09:46 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 13 Nov 2017 17:09:46 +0100 Subject: Howto build an old version of hotspot (pre forest consolidation) Message-ID: Hi, can somebody provide any hints on how to build an older version of hotspot in the correct context? I have a reproducible hotspot crash which occurs with jdk-9+105 but not with jdk-9+104. I can sync to both tags and successfully build the corresponding jdk. But it seems impossible to update the hotspot repo to a change between jdk-9+104 and jdk-9+105 and build the complete jdk because I always get some wired build errors (no difference if the other repos are on jdk-9+104 or jdk-9+105). It seems that the hotspot revisions between jdk-9+104 and jdk-9+105 are based on some older versions of jdk. Is there s simple way how I can find out on which version? Thank you and best regards, Volker From erik.joelsson at oracle.com Mon Nov 13 16:43:52 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 13 Nov 2017 08:43:52 -0800 Subject: Howto build an old version of hotspot (pre forest consolidation) In-Reply-To: References: Message-ID: <675689a8-78a8-29d0-48f0-e1a53746e5fd@oracle.com> Hello Volker, The recommended way of actually building source from pre-consolidation is to clone a tree from that day and age (jdk9 in this case). That said, it should be possible to build the consolidated repo as well (as long as you are working in an OpenJDK only situation). The merge of the repos is only actually correct at the tags. Between tags, each old repo moves on its own, with the rest of the repos sitting still on the last tag, then at the next tag, they are all merged together again. So in your case (provided I got it all right), if you first sync to jdk-9+104, that is a verified equivalent to the combined tags of jdk-9+104 pre-consolidation. If you then sync to a hotspot change after that, the rest of the repos should sit still at 104. This does not guarantee that the consolidated repo builds on all or any of those changes since we can't know which combination of changes were ever actually a working set of tips in the old forest, except for the promoted tags. Also note that just because a change in the hotspot subtree has a higher number than the tagged jdk-9+104, it does not necessarily mean it is a descendant of jdk-9+104. Especially for hotspot, since it was merged through one or two side forests, many of the new changes in 105 likely have parents much older than that. To find the relevant list of hotspot changes to try to build, you need to do a more advanced revset query, looking for descendants of 104 and ancestors of 105. Many of these changes will be merges that brought the actual changes in, typically when the integrator brought 104 down from dev. /Erik On 2017-11-13 08:09, Volker Simonis wrote: > Hi, > > can somebody provide any hints on how to build an older version of > hotspot in the correct context? > > I have a reproducible hotspot crash which occurs with jdk-9+105 but > not with jdk-9+104. I can sync to both tags and successfully build the > corresponding jdk. But it seems impossible to update the hotspot repo > to a change between jdk-9+104 and jdk-9+105 and build the complete > jdk because I always get some wired build errors (no difference if the > other repos are on jdk-9+104 or jdk-9+105). It seems that the hotspot > revisions between jdk-9+104 and jdk-9+105 are based on some older > versions of jdk. Is there s simple way how I can find out on which > version? > > Thank you and best regards, > Volker From volker.simonis at gmail.com Mon Nov 13 18:06:28 2017 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 13 Nov 2017 19:06:28 +0100 Subject: Howto build an old version of hotspot (pre forest consolidation) In-Reply-To: <675689a8-78a8-29d0-48f0-e1a53746e5fd@oracle.com> References: <675689a8-78a8-29d0-48f0-e1a53746e5fd@oracle.com> Message-ID: Hi Erik, thanks for the explanation and suggestions. I've managed to find the offending change (8145322: Code generated from unsafe loops can be slightly improved) just to find out that Roland already sent out a RFR for the fix (RFR(S): 8190375: Java Crash in JavaBug.formatPos(I)Ljava/lang/String :) In the end I could actually only find the offending change by building "hotspot-only" and copying libjvm.so into a pre-built image. The pre-build image was from jdk-9+100, the hotspot changes I was testing were from hotspot between jdk-9+104 and jdk-9+105. >From my understanding (and from what you wrote) I thought there must be an older, tagged version of jdk and the other sub-repos (i.e. older than jdk-9+104) against which the changes in hotspot, which finally ended up between jdk-9+104 and jdk-9+105 in the main repo, must have been developed. Unfortunately, I couldn't do a complete, clean build of the offending hotspot changes with the other repos being synced at any of the tags between jdk-9+95 and jdk-9+105. Another problem is that the date attribute on the changesets is actually unusable because it is fooled by tools like Mercurial Queues which many developers (including myself) are using. The problem is that the date attribute on a changeset is the date, when the change was first committed in the developers repo, which can be potentially quite some time before it was integrated or completely bogus if the developers local time was not accurate or he deliberately used a bad "--date" argument when committing. Taking all this into account, I don't see how I could clone a tree "from that day and age" (although that would be usefull)? JBS contains the correct check-in times, but unfortunately that's an external tool and cumbersome to look-up. After all, I finally found the offending change and hopefully these kind of problems will disappear in the future with the consolidated repo. Thank you and best regards, Volker On Mon, Nov 13, 2017 at 5:43 PM, Erik Joelsson wrote: > Hello Volker, > > The recommended way of actually building source from pre-consolidation is to > clone a tree from that day and age (jdk9 in this case). That said, it should > be possible to build the consolidated repo as well (as long as you are > working in an OpenJDK only situation). > > The merge of the repos is only actually correct at the tags. Between tags, > each old repo moves on its own, with the rest of the repos sitting still on > the last tag, then at the next tag, they are all merged together again. So > in your case (provided I got it all right), if you first sync to jdk-9+104, > that is a verified equivalent to the combined tags of jdk-9+104 > pre-consolidation. If you then sync to a hotspot change after that, the rest > of the repos should sit still at 104. This does not guarantee that the > consolidated repo builds on all or any of those changes since we can't know > which combination of changes were ever actually a working set of tips in the > old forest, except for the promoted tags. > > Also note that just because a change in the hotspot subtree has a higher > number than the tagged jdk-9+104, it does not necessarily mean it is a > descendant of jdk-9+104. Especially for hotspot, since it was merged through > one or two side forests, many of the new changes in 105 likely have parents > much older than that. To find the relevant list of hotspot changes to try to > build, you need to do a more advanced revset query, looking for descendants > of 104 and ancestors of 105. Many of these changes will be merges that > brought the actual changes in, typically when the integrator brought 104 > down from dev. > > /Erik > > > > On 2017-11-13 08:09, Volker Simonis wrote: >> >> Hi, >> >> can somebody provide any hints on how to build an older version of >> hotspot in the correct context? >> >> I have a reproducible hotspot crash which occurs with jdk-9+105 but >> not with jdk-9+104. I can sync to both tags and successfully build the >> corresponding jdk. But it seems impossible to update the hotspot repo >> to a change between jdk-9+104 and jdk-9+105 and build the complete >> jdk because I always get some wired build errors (no difference if the >> other repos are on jdk-9+104 or jdk-9+105). It seems that the hotspot >> revisions between jdk-9+104 and jdk-9+105 are based on some older >> versions of jdk. Is there s simple way how I can find out on which >> version? >> >> Thank you and best regards, >> Volker > > From magnus.ihse.bursie at oracle.com Tue Nov 14 11:17:08 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Nov 2017 12:17:08 +0100 Subject: RFR: JDK-8191204 Post-consolidation cleaning up of the build system Message-ID: <038f322b-2d06-31da-a3ed-8123fc0120cb@oracle.com> I think this is the last round of the post-consolidation cleaning up of the build system. I'm removing some now-redundant checks, aligning to more common calling practice, and speeding up the hg status check (which was becoming more urgent as the repo grow in size). Bug: https://bugs.openjdk.java.net/browse/JDK-8191204 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191204-post-consolidation-cleanup/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 14 12:21:13 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Nov 2017 13:21:13 +0100 Subject: Howto build an old version of hotspot (pre forest consolidation) In-Reply-To: References: <675689a8-78a8-29d0-48f0-e1a53746e5fd@oracle.com> Message-ID: <805582ae-25f9-86c0-4940-cfdbc448cce3@oracle.com> On 2017-11-13 19:06, Volker Simonis wrote: > Hi Erik, > > thanks for the explanation and suggestions. I've managed to find the > offending change (8145322: Code generated from unsafe loops can be > slightly improved) just to find out that Roland already sent out a RFR > for the fix (RFR(S): 8190375: Java Crash in > JavaBug.formatPos(I)Ljava/lang/String :) > > In the end I could actually only find the offending change by building > "hotspot-only" and copying libjvm.so into a pre-built image. The > pre-build image was from jdk-9+100, the hotspot changes I was testing > were from hotspot between jdk-9+104 and jdk-9+105. > > From my understanding (and from what you wrote) I thought there must > be an older, tagged version of jdk and the other sub-repos (i.e. older > than jdk-9+104) against which the changes in hotspot, which finally > ended up between jdk-9+104 and jdk-9+105 in the main repo, must have > been developed. Unfortunately, I couldn't do a complete, clean build > of the offending hotspot changes with the other repos being synced at > any of the tags between jdk-9+95 and jdk-9+105. > > Another problem is that the date attribute on the changesets is > actually unusable because it is fooled by tools like Mercurial Queues > which many developers (including myself) are using. The problem is > that the date attribute on a changeset is the date, when the change > was first committed in the developers repo, which can be potentially > quite some time before it was integrated or completely bogus if the > developers local time was not accurate or he deliberately used a bad > "--date" argument when committing. > > Taking all this into account, I don't see how I could clone a tree > "from that day and age" (although that would be usefull)? JBS contains > the correct check-in times, but unfortunately that's an external tool > and cumbersome to look-up. Unfortunately, there is no such way. :-( The "best" approximation of what consituted the complete source code tree at any point in time is provided by the jdk*-changes mailing lists. You would have to dig up the mails there, check their timestamps and then reconstruate the timeline of the entire forst. Yes, this sucks big time. :-( It means that interval halving your way to find a problem when the code spans multiple repos is virtually impossible in practice. I've done it a few times for the build system when I found no other way out. In normal circumstances, bisecting commits would be an almost automated process that should be on top of your list of tools. On the flip side, this should now work better, as long as you stick to OpenJDK only with no closed extensions. :) /Magnus > > After all, I finally found the offending change and hopefully these > kind of problems will disappear in the future with the consolidated > repo. > > Thank you and best regards, > Volker > > > > On Mon, Nov 13, 2017 at 5:43 PM, Erik Joelsson wrote: >> Hello Volker, >> >> The recommended way of actually building source from pre-consolidation is to >> clone a tree from that day and age (jdk9 in this case). That said, it should >> be possible to build the consolidated repo as well (as long as you are >> working in an OpenJDK only situation). >> >> The merge of the repos is only actually correct at the tags. Between tags, >> each old repo moves on its own, with the rest of the repos sitting still on >> the last tag, then at the next tag, they are all merged together again. So >> in your case (provided I got it all right), if you first sync to jdk-9+104, >> that is a verified equivalent to the combined tags of jdk-9+104 >> pre-consolidation. If you then sync to a hotspot change after that, the rest >> of the repos should sit still at 104. This does not guarantee that the >> consolidated repo builds on all or any of those changes since we can't know >> which combination of changes were ever actually a working set of tips in the >> old forest, except for the promoted tags. >> >> Also note that just because a change in the hotspot subtree has a higher >> number than the tagged jdk-9+104, it does not necessarily mean it is a >> descendant of jdk-9+104. Especially for hotspot, since it was merged through >> one or two side forests, many of the new changes in 105 likely have parents >> much older than that. To find the relevant list of hotspot changes to try to >> build, you need to do a more advanced revset query, looking for descendants >> of 104 and ancestors of 105. Many of these changes will be merges that >> brought the actual changes in, typically when the integrator brought 104 >> down from dev. >> >> /Erik >> >> >> >> On 2017-11-13 08:09, Volker Simonis wrote: >>> Hi, >>> >>> can somebody provide any hints on how to build an older version of >>> hotspot in the correct context? >>> >>> I have a reproducible hotspot crash which occurs with jdk-9+105 but >>> not with jdk-9+104. I can sync to both tags and successfully build the >>> corresponding jdk. But it seems impossible to update the hotspot repo >>> to a change between jdk-9+104 and jdk-9+105 and build the complete >>> jdk because I always get some wired build errors (no difference if the >>> other repos are on jdk-9+104 or jdk-9+105). It seems that the hotspot >>> revisions between jdk-9+104 and jdk-9+105 are based on some older >>> versions of jdk. Is there s simple way how I can find out on which >>> version? >>> >>> Thank you and best regards, >>> Volker >> From magnus.ihse.bursie at oracle.com Tue Nov 14 12:30:14 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Nov 2017 13:30:14 +0100 Subject: Default value for -with_native_debug_symbols on Windows useful? In-Reply-To: References: <9e3ed379-5ecb-3c4a-a555-9d1304d6f64d@oracle.com> <54909f49-5f51-2d15-fdc7-d4ceb5dacdd1@oracle.com> Message-ID: On 2017-11-10 15:50, Erik Helin wrote: > On 11/10/2017 09:01 AM, Thomas St?fe wrote: >> Hi Erik, >> >> On Fri, Nov 10, 2017 at 12:52 AM, Erik Joelsson >> >> wrote: >> >>> Hello, >>> >>> On 2017-11-09 15:26, Thomas St?fe wrote: >>> >>> Do you think this for all platforms or just for Windows? With >>> removed, do >>> you really mean the feature removed, not just the default changed? >>> >>> I mean for all platforms. I don't see any point in the build wasting >>> time >>> on zipping up the debug symbols which also makes them unusable. If >>> someone >>> cries out we could leave the feature in, but I would much rather >>> not. Note >>> that the bundle target has to unzip them again to put them in the >>> symbols >>> bundle, which is the final deliverable of the symbols. >>> >>> Historically there have been various reasons for this zipping >>> internally >>> to Oracle, but I don't think any of those reasons hold up anymore in >>> our >>> current JDK 10 infrastructure. >>> >> >> I am all for it. We never really used that feature. > > Could we start by changing the default (for all platforms) to be > either 'external' or 'internal' and then work on eventually removing > 'zipped'? I think that's the best way forward. I created https://bugs.openjdk.java.net/browse/JDK-8191205. I'd like to keep the default to "external", to have that code excercised (since it's more complex than "internal"). /Magnus > > Thanks, > Erik > >> Best Regards, Thomas >> >> >>> >>> >>> /Erik >>> >>> Thomas >>> >>> On Thu 9. Nov 2017 at 19:58, Erik Joelsson >>> wrote: >>> >>>> I agree that the zipped debug symbols are just annoying and should be >>>> removed. >>>> >>>> /Erik >>>> >>>> >>>> On 2017-11-08 22:32, Thomas St?fe wrote: >>>>> Hi all, >>>>> >>>>> I could reframe the subject matter as "how do you internally at >>>>> Oracle >>>>> build the Windows JDK"? >>>>> >>>>> I had several discussions with people from Oracle about missing >>>> callstacks >>>>> in hs-err files on Windows generated in tests which run at Oracle. >>>>> >>>>> I recently did JDK-8185712, which improves the Windows symbol >>>>> decoder, >>>> so I >>>>> feel somewhat responsible. However, I was never able to reproduce >>>> anything >>>>> - here at SAP, we get nice callstacks and all works well. >>>>> >>>>> A simple explanation may be that you at Oracle either remove the >>>>> debug >>>> info >>>>> (pdb files) from the images before testing and/or build >>>>> with -with_native_debug_symbols=zipped . The latter zips the pdb >>>>> files, >>>>> which in that form are useless. Which is it? >>>>> >>>>> For that matter, do you think -with_native_debug_symbols=zipped makes >>>> sense >>>>> on Windows? Would it not make more sense to make the default >>>>> -with_native_debug_symbols=external on Windows, to have pdb files >>>> ready for >>>>> debugging and testing? >>>>> >>>>> Thanks, Thomas >>>> >>>> >>> From thomas.stuefe at gmail.com Tue Nov 14 12:46:56 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 14 Nov 2017 13:46:56 +0100 Subject: Default value for -with_native_debug_symbols on Windows useful? In-Reply-To: References: <9e3ed379-5ecb-3c4a-a555-9d1304d6f64d@oracle.com> <54909f49-5f51-2d15-fdc7-d4ceb5dacdd1@oracle.com> Message-ID: Thanks Markus! On Tue, Nov 14, 2017 at 1:30 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > On 2017-11-10 15:50, Erik Helin wrote: > >> On 11/10/2017 09:01 AM, Thomas St?fe wrote: >> >>> Hi Erik, >>> >>> On Fri, Nov 10, 2017 at 12:52 AM, Erik Joelsson < >>> erik.joelsson at oracle.com> >>> wrote: >>> >>> Hello, >>>> >>>> On 2017-11-09 15:26, Thomas St?fe wrote: >>>> >>>> Do you think this for all platforms or just for Windows? With removed, >>>> do >>>> you really mean the feature removed, not just the default changed? >>>> >>>> I mean for all platforms. I don't see any point in the build wasting >>>> time >>>> on zipping up the debug symbols which also makes them unusable. If >>>> someone >>>> cries out we could leave the feature in, but I would much rather not. >>>> Note >>>> that the bundle target has to unzip them again to put them in the >>>> symbols >>>> bundle, which is the final deliverable of the symbols. >>>> >>>> Historically there have been various reasons for this zipping internally >>>> to Oracle, but I don't think any of those reasons hold up anymore in our >>>> current JDK 10 infrastructure. >>>> >>>> >>> I am all for it. We never really used that feature. >>> >> >> Could we start by changing the default (for all platforms) to be either >> 'external' or 'internal' and then work on eventually removing 'zipped'? >> > > I think that's the best way forward. I created > https://bugs.openjdk.java.net/browse/JDK-8191205. I'd like to keep the > default to "external", to have that code excercised (since it's more > complex than "internal"). > > /Magnus > > > >> Thanks, >> Erik >> >> Best Regards, Thomas >>> >>> >>> >>>> >>>> /Erik >>>> >>>> Thomas >>>> >>>> On Thu 9. Nov 2017 at 19:58, Erik Joelsson >>>> wrote: >>>> >>>> I agree that the zipped debug symbols are just annoying and should be >>>>> removed. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2017-11-08 22:32, Thomas St?fe wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> I could reframe the subject matter as "how do you internally at Oracle >>>>>> build the Windows JDK"? >>>>>> >>>>>> I had several discussions with people from Oracle about missing >>>>>> >>>>> callstacks >>>>> >>>>>> in hs-err files on Windows generated in tests which run at Oracle. >>>>>> >>>>>> I recently did JDK-8185712, which improves the Windows symbol decoder, >>>>>> >>>>> so I >>>>> >>>>>> feel somewhat responsible. However, I was never able to reproduce >>>>>> >>>>> anything >>>>> >>>>>> - here at SAP, we get nice callstacks and all works well. >>>>>> >>>>>> A simple explanation may be that you at Oracle either remove the debug >>>>>> >>>>> info >>>>> >>>>>> (pdb files) from the images before testing and/or build >>>>>> with -with_native_debug_symbols=zipped . The latter zips the pdb >>>>>> files, >>>>>> which in that form are useless. Which is it? >>>>>> >>>>>> For that matter, do you think -with_native_debug_symbols=zipped makes >>>>>> >>>>> sense >>>>> >>>>>> on Windows? Would it not make more sense to make the default >>>>>> -with_native_debug_symbols=external on Windows, to have pdb files >>>>>> >>>>> ready for >>>>> >>>>>> debugging and testing? >>>>>> >>>>>> Thanks, Thomas >>>>>> >>>>> >>>>> >>>>> >>>> > From magnus.ihse.bursie at oracle.com Tue Nov 14 13:06:12 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 14 Nov 2017 14:06:12 +0100 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended Message-ID: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> During hotspot gensrc, we create two files, jvmtiEnvStub and jvmtiEnvRecommended, which later on are explicitly excluded from the build. We should just stop generating them. I have built hotspot with and without this patch, and used the build comparison script (compare.sh) to verify that it has not changed. Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 /Magnus From erik.joelsson at oracle.com Tue Nov 14 18:22:45 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Nov 2017 10:22:45 -0800 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> Message-ID: <044a3b25-44c3-12d2-530f-3e7aef2f5e32@oracle.com> Fantastic build logic. Looks good. /Erik On 2017-11-14 05:06, Magnus Ihse Bursie wrote: > During hotspot gensrc, we create two files, jvmtiEnvStub and > jvmtiEnvRecommended, which later on are explicitly excluded from the > build. We should just stop generating them. > > I have built hotspot with and without this patch, and used the build > comparison script (compare.sh) to verify that it has not changed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 > > /Magnus > From tim.bell at oracle.com Tue Nov 14 17:57:12 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 14 Nov 2017 09:57:12 -0800 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <044a3b25-44c3-12d2-530f-3e7aef2f5e32@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> <044a3b25-44c3-12d2-530f-3e7aef2f5e32@oracle.com> Message-ID: <5A0B2E78.7060606@oracle.com> Looks good to me as well. That is much cleaner. Tim On 11/14/17 10:22, Erik Joelsson wrote: > Fantastic build logic. Looks good. > > /Erik > > > On 2017-11-14 05:06, Magnus Ihse Bursie wrote: >> During hotspot gensrc, we create two files, jvmtiEnvStub and >> jvmtiEnvRecommended, which later on are explicitly excluded from the >> build. We should just stop generating them. >> >> I have built hotspot with and without this patch, and used the build >> comparison script (compare.sh) to verify that it has not changed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 >> >> >> /Magnus >> > From tim.bell at oracle.com Tue Nov 14 18:03:47 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 14 Nov 2017 10:03:47 -0800 Subject: RFR: JDK-8191204 Post-consolidation cleaning up of the build system In-Reply-To: <038f322b-2d06-31da-a3ed-8123fc0120cb@oracle.com> References: <038f322b-2d06-31da-a3ed-8123fc0120cb@oracle.com> Message-ID: <5A0B3003.1050109@oracle.com> Magnus: > I think this is the last round of the post-consolidation cleaning up of > the build system. I'm removing some now-redundant checks, aligning to > more common calling practice, and speeding up the hg status check (which > was becoming more urgent as the repo grow in size). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191204 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191204-post-consolidation-cleanup/webrev.01 Looks good. For make/hotspot/lib/CompileLibjsig.gmk I see there will be a merge with the fix for JDK-8190418, but that should be trivial. Tim From david.holmes at oracle.com Tue Nov 14 21:55:08 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 07:55:08 +1000 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> Message-ID: <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> Hi Magnus, On 14/11/2017 11:06 PM, Magnus Ihse Bursie wrote: > During hotspot gensrc, we create two files, jvmtiEnvStub and > jvmtiEnvRecommended, which later on are explicitly excluded from the > build. We should just stop generating them. cc'd Dan: Need someone who knows to chime in with what these files are and why they exist. The stub is like a dummy implementation that may have been useful for testing against. No idea what the "recommended" file may represent. ?? > I have built hotspot with and without this patch, and used the build > comparison script (compare.sh) to verify that it has not changed. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 Change itself seems fine. Not sure if jvmtiEnv.xsl is now a dead file that can be removed (if so we'll file a hotspot bug for that). Thanks, David > > /Magnus > From daniel.daugherty at oracle.com Tue Nov 14 21:57:03 2017 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 14 Nov 2017 16:57:03 -0500 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> Message-ID: <0b9e32bb-7bb9-3e68-9806-3fbfac95eff8@oracle.com> Adding Robert Field...? Those files were created before I started doing any work on JVM/TI... Dan On 11/14/17 4:55 PM, David Holmes wrote: > Hi Magnus, > > On 14/11/2017 11:06 PM, Magnus Ihse Bursie wrote: >> During hotspot gensrc, we create two files, jvmtiEnvStub and >> jvmtiEnvRecommended, which later on are explicitly excluded from the >> build. We should just stop generating them. > > cc'd Dan: Need someone who knows to chime in with what these files are > and why they exist. The stub is like a dummy implementation that may > have been useful for testing against. No idea what the "recommended" > file may represent. ?? > >> I have built hotspot with and without this patch, and used the build >> comparison script (compare.sh) to verify that it has not changed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 > > > Change itself seems fine. Not sure if jvmtiEnv.xsl is now a dead file > that can be removed (if so we'll file a hotspot bug for that). > > Thanks, > David > >> >> /Magnus >> From david.holmes at oracle.com Tue Nov 14 21:57:47 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 15 Nov 2017 07:57:47 +1000 Subject: RFR: JDK-8191204 Post-consolidation cleaning up of the build system In-Reply-To: <038f322b-2d06-31da-a3ed-8123fc0120cb@oracle.com> References: <038f322b-2d06-31da-a3ed-8123fc0120cb@oracle.com> Message-ID: Hi Magnus, All seems reasonable. Thanks, David On 14/11/2017 9:17 PM, Magnus Ihse Bursie wrote: > I think this is the last round of the post-consolidation cleaning up of > the build system. I'm removing some now-redundant checks, aligning to > more common calling practice, and speeding up the hg status check (which > was becoming more urgent as the repo grow in size). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191204 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191204-post-consolidation-cleanup/webrev.01 > > > /Magnus From erik.joelsson at oracle.com Tue Nov 14 22:35:06 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 14 Nov 2017 14:35:06 -0800 Subject: RFR: JDK-8190702: JMC packaging causing errors in JDK 10 consolidated repo (macOS) Message-ID: <3ef3b742-12c1-2996-f144-cb318a3799bc@oracle.com> When I added support for copying files with spaces in their names, I missed a case. On Mac (the only platform where we currently, in the Oracle build, have a directory with space in it), when rebuilding images after actually touching the source, the build fails with: cp: /Users/danielfuchs/workspaces/jdk/jdk10/build/macosx-x64/images/jdk/lib/missioncontrol/Java Mission Control.app/Contents/Eclipse/jmc.ini: No such file or directory This is caused by the $(call MakeDir, $(@D)) line in the install-file macro not actually creating the parent directory before trying to copy the file. This in turn was caused by two things: First, if a target file that contains spaces, that is defined using the ? wildcard trick, exists when the makefile is parsed, make will resolve those wildcards to spaces, so the target file variable ($@) will have spaces in it instead of ?. This has the consequence that $(@D), which is just a shortcut for $(dir $@) will actually apply the dir call on each space separated entity in $@. So the first fix was to make sure the input to $(dir ) is actually SpaceEncoded. Second, the wildcard function seem to be doing some kind of clever caching of results and this caching breaks down when there are spaces in filenames. Because of this, if the argument of $(wildcard ) existed when the makefile was parsed, but was then deleted as part of a prerequisite rule, $(wildcard ) will still return the file as existing when called from a subsequent recipe line. This only happens if the file argument to wildcard contains spaces, so my best guess is that some string matching is happening in some caching table and fails (but I haven't actually checked the gnu make source). My fix for this is to change the MakeDir macro so that it always runs mkdir if the target dir contains ?. I also have modified the copy-files tests to reproduce this situation and verified that the fix solves it there as well. Bug: https://bugs.openjdk.java.net/browse/JDK-8190702 Webrev: http://cr.openjdk.java.net/~erikj/8190702/webrev.01/ /Erik From daniel.fuchs at oracle.com Wed Nov 15 15:52:09 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 15 Nov 2017 15:52:09 +0000 Subject: RFR: JDK-8190702: JMC packaging causing errors in JDK 10 consolidated repo (macOS) In-Reply-To: <3ef3b742-12c1-2996-f144-cb318a3799bc@oracle.com> References: <3ef3b742-12c1-2996-f144-cb318a3799bc@oracle.com> Message-ID: <12c4488f-f62c-c276-69e3-9b01d6682fec@oracle.com> Thanks for that Erik! It's been annoying me for a couple of days :-) I have imported your patch locally in my repo and it seems to be working fine. Hopefully someone from the build team will give you a thumbs up! best regards, -- daniel On 14/11/2017 22:35, Erik Joelsson wrote: > When I added support for copying files with spaces in their names, I > missed a case. On Mac (the only platform where we currently, in the > Oracle build, have a directory with space in it), when rebuilding images > after actually touching the source, the build fails with: > > cp: > /Users/danielfuchs/workspaces/jdk/jdk10/build/macosx-x64/images/jdk/lib/missioncontrol/Java > Mission Control.app/Contents/Eclipse/jmc.ini: No such file or directory > > This is caused by the $(call MakeDir, $(@D)) line in the install-file > macro not actually creating the parent directory before trying to copy > the file. This in turn was caused by two things: > > First, if a target file that contains spaces, that is defined using the > ? wildcard trick, exists when the makefile is parsed, make will resolve > those wildcards to spaces, so the target file variable ($@) will have > spaces in it instead of ?. This has the consequence that $(@D), which is > just a shortcut for $(dir $@) will actually apply the dir call on each > space separated entity in $@. So the first fix was to make sure the > input to $(dir ) is actually SpaceEncoded. > > Second, the wildcard function seem to be doing some kind of clever > caching of results and this caching breaks down when there are spaces in > filenames. Because of this, if the argument of $(wildcard ) existed when > the makefile was parsed, but was then deleted as part of a prerequisite > rule, $(wildcard ) will still return the file as existing when called > from a subsequent recipe line. This only happens if the file argument to > wildcard contains spaces, so my best guess is that some string matching > is happening in some caching table and fails (but I haven't actually > checked the gnu make source). My fix for this is to change the MakeDir > macro so that it always runs mkdir if the target dir contains ?. > > I also have modified the copy-files tests to reproduce this situation > and verified that the fix solves it there as well. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190702 > > Webrev: http://cr.openjdk.java.net/~erikj/8190702/webrev.01/ > > /Erik > From tim.bell at oracle.com Wed Nov 15 17:42:59 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 15 Nov 2017 09:42:59 -0800 Subject: RFR: JDK-8190702: JMC packaging causing errors in JDK 10 consolidated repo (macOS) In-Reply-To: <12c4488f-f62c-c276-69e3-9b01d6682fec@oracle.com> References: <3ef3b742-12c1-2996-f144-cb318a3799bc@oracle.com> <12c4488f-f62c-c276-69e3-9b01d6682fec@oracle.com> Message-ID: <5A0C7CA3.3070306@oracle.com> Erik: Looks good to me as well. Tim On 11/15/17 07:52, Daniel Fuchs wrote: > > Thanks for that Erik! > It's been annoying me for a couple of days :-) > > I have imported your patch locally in my repo and it seems to > be working fine. > > Hopefully someone from the build team will give you a thumbs up! > > best regards, > > -- daniel > > > On 14/11/2017 22:35, Erik Joelsson wrote: >> When I added support for copying files with spaces in their names, I >> missed a case. On Mac (the only platform where we currently, in the >> Oracle build, have a directory with space in it), when rebuilding >> images after actually touching the source, the build fails with: >> >> cp: >> /Users/danielfuchs/workspaces/jdk/jdk10/build/macosx-x64/images/jdk/lib/missioncontrol/Java >> Mission Control.app/Contents/Eclipse/jmc.ini: No such file or directory >> >> This is caused by the $(call MakeDir, $(@D)) line in the install-file >> macro not actually creating the parent directory before trying to copy >> the file. This in turn was caused by two things: >> >> First, if a target file that contains spaces, that is defined using >> the ? wildcard trick, exists when the makefile is parsed, make will >> resolve those wildcards to spaces, so the target file variable ($@) >> will have spaces in it instead of ?. This has the consequence that >> $(@D), which is just a shortcut for $(dir $@) will actually apply the >> dir call on each space separated entity in $@. So the first fix was to >> make sure the input to $(dir ) is actually SpaceEncoded. >> >> Second, the wildcard function seem to be doing some kind of clever >> caching of results and this caching breaks down when there are spaces >> in filenames. Because of this, if the argument of $(wildcard ) existed >> when the makefile was parsed, but was then deleted as part of a >> prerequisite rule, $(wildcard ) will still return the file as existing >> when called from a subsequent recipe line. This only happens if the >> file argument to wildcard contains spaces, so my best guess is that >> some string matching is happening in some caching table and fails (but >> I haven't actually checked the gnu make source). My fix for this is to >> change the MakeDir macro so that it always runs mkdir if the target >> dir contains ?. >> >> I also have modified the copy-files tests to reproduce this situation >> and verified that the fix solves it there as well. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190702 >> >> Webrev: http://cr.openjdk.java.net/~erikj/8190702/webrev.01/ >> >> /Erik >> > From erik.joelsson at oracle.com Thu Nov 16 17:14:34 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 16 Nov 2017 09:14:34 -0800 Subject: RFR: 8191420: Changing "requires" to "requires static" in an application module results in build failure Message-ID: Hello, This is a small fix to the module-info.java parsing logic in make to add support for the "requires static" construct. I also made the current logic a bit more robust so that it only matches keywords as stand alone words. Webrev: http://cr.openjdk.java.net/~erikj/8191420/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8191420 /Erik From tim.bell at oracle.com Thu Nov 16 23:40:59 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 16 Nov 2017 15:40:59 -0800 Subject: RFR: 8191420: Changing "requires" to "requires static" in an application module results in build failure In-Reply-To: References: Message-ID: <5A0E220B.8060700@oracle.com> Erik: > This is a small fix to the module-info.java parsing logic in make to add > support for the "requires static" construct. I also made the current > logic a bit more robust so that it only matches keywords as stand alone > words. > > Webrev: http://cr.openjdk.java.net/~erikj/8191420/webrev.01/ > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191420 Looks good. /Tim From erik.joelsson at oracle.com Fri Nov 17 01:43:27 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 16 Nov 2017 17:43:27 -0800 Subject: RFR: 8191420: Changing "requires" to "requires static" in an application module results in build failure In-Reply-To: <5A0E220B.8060700@oracle.com> References: <5A0E220B.8060700@oracle.com> Message-ID: <065fa005-5056-c4b5-ee05-3e956b43b053@oracle.com> To be clear, I did not intend to change the module-info.java for jdk.scripting.nashorn.shell in this change. That was only done to test the new functionality. /Erik On 2017-11-16 15:40, Tim Bell wrote: > Erik: > >> This is a small fix to the module-info.java parsing logic in make to add >> support for the "requires static" construct. I also made the current >> logic a bit more robust so that it only matches keywords as stand alone >> words. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8191420/webrev.01/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191420 > > Looks good. > > /Tim > > From matthias.baesken at sap.com Fri Nov 17 08:54:50 2017 From: matthias.baesken at sap.com (Baesken, Matthias) Date: Fri, 17 Nov 2017 08:54:50 +0000 Subject: OpenJDK9/10 : sawindbg.dll / sawindbg.dll.manifest Message-ID: Hello, I noticed that in OpenJDK 9 and 10, on 64bit Windows the sawindbg.dll.manifest shows up in another folder than the related dll : ./images/jdk/lib/sawindbg.dll.manifest ./images/jdk/bin/sawindbg.dll Does anybody know why it is done this way ? I thought that usually the manifest would be placed next to the dll ? (in Open JDK8 there is no sawindbg.dll.manifest manifest file at all) Thanks, Matthias From erik.joelsson at oracle.com Fri Nov 17 17:15:21 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 17 Nov 2017 09:15:21 -0800 Subject: OpenJDK9/10 : sawindbg.dll / sawindbg.dll.manifest In-Reply-To: References: Message-ID: <8b8ac835-7a4f-dc7f-85fe-34a24ab700fa@oracle.com> I don't know what the manifest file is for, but if it's in the wrong place I would blame jlink for messing it up. /Erik On 2017-11-17 00:54, Baesken, Matthias wrote: > Hello, I noticed that in OpenJDK 9 and 10, on 64bit Windows the sawindbg.dll.manifest > shows up in another folder than the related dll : > > ./images/jdk/lib/sawindbg.dll.manifest > ./images/jdk/bin/sawindbg.dll > > Does anybody know why it is done this way ? I thought that usually the manifest would be placed next to the dll ? > (in Open JDK8 there is no sawindbg.dll.manifest manifest file at all) > > Thanks, Matthias From ted at tedneward.com Sat Nov 18 15:42:20 2017 From: ted at tedneward.com (Ted Neward) Date: Sat, 18 Nov 2017 16:42:20 +0100 Subject: OpenJDK9/10 : sawindbg.dll / sawindbg.dll.manifest In-Reply-To: <8b8ac835-7a4f-dc7f-85fe-34a24ab700fa@oracle.com> References: <8b8ac835-7a4f-dc7f-85fe-34a24ab700fa@oracle.com> Message-ID: <1E40FA7D-39DD-493A-8CC9-5C7E5A31D952@tedneward.com> The manifest file was introduced around Windows 7 timeframe, as I recall, as part of Microsoft?s slow revamp of many of their unmanaged code practices (DLLs, etc) to gain benefit from some of the things they?d learned from managed code. It?s been a while since I did any unmanaged Windows development, but I believe that as long as the manifest is somewhere on the dynamic library load path (which would correspond to the PATH plus a few additional places), it?s visible to the native loader and therefore usable. Basically, these are XML files that allow for some amount of metadata and redirection to be supported for native code. More details are available here: https://msdn.microsoft.com/en-us/library/windows/desktop/aa375365(v=vs.85).aspx . I suspect they are produced as a natural part of the build when using Visual Studio to compile native code, but I?m speculating here. Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 11/17/17, 6:15 PM, "build-dev on behalf of Erik Joelsson" wrote: I don't know what the manifest file is for, but if it's in the wrong place I would blame jlink for messing it up. /Erik On 2017-11-17 00:54, Baesken, Matthias wrote: > Hello, I noticed that in OpenJDK 9 and 10, on 64bit Windows the sawindbg.dll.manifest > shows up in another folder than the related dll : > > ./images/jdk/lib/sawindbg.dll.manifest > ./images/jdk/bin/sawindbg.dll > > Does anybody know why it is done this way ? I thought that usually the manifest would be placed next to the dll ? > (in Open JDK8 there is no sawindbg.dll.manifest manifest file at all) > > Thanks, Matthias From Alan.Bateman at oracle.com Sun Nov 19 07:48:39 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 19 Nov 2017 07:48:39 +0000 Subject: OpenJDK9/10 : sawindbg.dll / sawindbg.dll.manifest In-Reply-To: <8b8ac835-7a4f-dc7f-85fe-34a24ab700fa@oracle.com> References: <8b8ac835-7a4f-dc7f-85fe-34a24ab700fa@oracle.com> Message-ID: <2c1a4c14-f897-9a8b-d7e7-8d3f679efac4@oracle.com> On 17/11/2017 17:15, Erik Joelsson wrote: > I don't know what the manifest file is for, but if it's in the wrong > place I would blame jlink for messing it up. > jlink doesn't know anything about Windows manifests files. I think the issue here is that jdk.hotspot.agent.jmod contains lib/sawindbg.dll.manifest and jlink will copy it into the run-time image lib directory as it's not a .dll/.pdb/.map file that needs special handling on Windows. I think we need to establish if the .manifest file is needed. If it is needed then decide if it gets packaged into the bin or lib section of the JMOD file as that will determine if jlink? needs to special case these files. -Alan From erik.joelsson at oracle.com Mon Nov 20 22:12:38 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 20 Nov 2017 14:12:38 -0800 Subject: RFR: JDK-8191614: Generated configure out of sync Message-ID: If I run autogen.sh I get a pretty big diff. It seems some merge or other have failed to update generated-configure.sh. This patch is just a pure rerun of autogen.sh on the latest change. Bug: https://bugs.openjdk.java.net/browse/JDK-8191614 Webrev: http://cr.openjdk.java.net/~erikj/8191614/webrev.01/ /Erik From claes.redestad at oracle.com Mon Nov 20 22:23:17 2017 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 20 Nov 2017 23:23:17 +0100 Subject: RFR: JDK-8191614: Generated configure out of sync In-Reply-To: References: Message-ID: <72abea01-ad9d-ac7a-1291-6d0cdf9b3fd7@oracle.com> Ship it! /Claes On 2017-11-20 23:12, Erik Joelsson wrote: > If I run autogen.sh I get a pretty big diff. It seems some merge or > other have failed to update generated-configure.sh. This patch is just > a pure rerun of autogen.sh on the latest change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191614 > Webrev: http://cr.openjdk.java.net/~erikj/8191614/webrev.01/ > > /Erik > From david.holmes at oracle.com Mon Nov 20 22:28:16 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Nov 2017 08:28:16 +1000 Subject: RFR: JDK-8191614: Generated configure out of sync In-Reply-To: References: Message-ID: <3084fa33-af41-5157-df9b-494466e3df08@oracle.com> On 21/11/2017 8:12 AM, Erik Joelsson wrote: > If I run autogen.sh I get a pretty big diff. It seems some merge or > other have failed to update generated-configure.sh. This patch is just a > pure rerun of autogen.sh on the latest change. I don't know how but this seems to have been caused by: http://hg.openjdk.java.net/jdk/jdk/rev/fb290fd1f9d4 8171853: Remove Shark compiler Reviewed-by: dholmes, kvn, erikj, ihse There's no generated-configure.sh in the changeset! But how that could have been that way for so long is a complete mystery as any build attempt would have tried to regenerate it which would have failed on most platforms. ??? > Bug: https://bugs.openjdk.java.net/browse/JDK-8191614 > Webrev: http://cr.openjdk.java.net/~erikj/8191614/webrev.01/ Change is fine. Thanks, David ----- > /Erik > From magnus.ihse.bursie at oracle.com Tue Nov 21 08:46:03 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Nov 2017 09:46:03 +0100 Subject: RFR: JDK-8190418 Stop generating jvmtiEnvStub and jvmtiEnvRecommended In-Reply-To: <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> References: <9ce17220-bbd0-6290-224f-02e203a588f9@oracle.com> <475eb71c-d770-e0a3-a82e-943fadecb293@oracle.com> Message-ID: <56fea37f-eb99-9a82-e3fb-7df7b861a8ef@oracle.com> On 2017-11-14 22:55, David Holmes wrote: > Hi Magnus, > > On 14/11/2017 11:06 PM, Magnus Ihse Bursie wrote: >> During hotspot gensrc, we create two files, jvmtiEnvStub and >> jvmtiEnvRecommended, which later on are explicitly excluded from the >> build. We should just stop generating them. > > cc'd Dan: Need someone who knows to chime in with what these files are > and why they exist. The stub is like a dummy implementation that may > have been useful for testing against. No idea what the "recommended" > file may represent. ?? > >> I have built hotspot with and without this patch, and used the build >> comparison script (compare.sh) to verify that it has not changed. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8190418 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8190418-stop-generating-unneeded-jvmti-files/webrev.01 > > > Change itself seems fine. Not sure if jvmtiEnv.xsl is now a dead file > that can be removed (if so we'll file a hotspot bug for that). It seems likely that it is. There's no reference to it. I leave it to you do delete it then. /Magnus > > Thanks, > David > >> >> /Magnus >> From magnus.ihse.bursie at oracle.com Tue Nov 21 08:58:40 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Nov 2017 09:58:40 +0100 Subject: RFR: JDK-8191204 Post-consolidation cleaning up of the build system In-Reply-To: <038f322b-2d06-31da-a3ed-8123fc0120cb@oracle.com> References: <038f322b-2d06-31da-a3ed-8123fc0120cb@oracle.com> Message-ID: <472bf121-2b51-d8b0-53bb-edeb98a70592@oracle.com> Erik reminded me off-list that the check for gtest source code could not be removed, due to the fact that Oracle, for historical reasons, generates "source bundles" with incomplete source trees, which e.g. are missing gtest. (And since gtest is built as part of the hotspot product, and not as a separate build step, it cannot be not built by just omitting a make target, so we must have this test.) I reverted this part before checking in the patch, judging that no re-review was needed. /Magnus On 2017-11-14 12:17, Magnus Ihse Bursie wrote: > I think this is the last round of the post-consolidation cleaning up > of the build system. I'm removing some now-redundant checks, aligning > to more common calling practice, and speeding up the hg status check > (which was becoming more urgent as the repo grow in size). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191204 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191204-post-consolidation-cleanup/webrev.01 > > /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 21 11:13:12 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Nov 2017 12:13:12 +0100 Subject: RFR: JDK-8191203 Remove duplicated jimage.hpp Message-ID: I ran a duplicate name check on the source base. Then I discovered that there is a jimage.hpp in both src/hotspot/share/classfile/jimage.hpp and src/java.base/share/native/libjimage/jimage.hpp. They are identical (apart from copyright headers), and once again, we shouldn't have both. David Holmes suggested removing the hotspot version, so this I've done. I intend to push this to jdk/hs. Bug: https://bugs.openjdk.java.net/browse/JDK-8191203 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191203-remove-duplicated-jimage-hpp/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 21 11:42:30 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Nov 2017 12:42:30 +0100 Subject: RFR: JDK-8191202 Remove duplicated jmm.h Message-ID: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> As part of the effort to remove duplicated files between Hotspot and JDK, the turn has now come to jmm.h. Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 /Magnus From david.holmes at oracle.com Tue Nov 21 11:44:38 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Nov 2017 21:44:38 +1000 Subject: RFR: JDK-8191203 Remove duplicated jimage.hpp In-Reply-To: References: Message-ID: Hi Magnus, This seems fine to me. Do you know what the story is with the copyright header? Thanks, David On 21/11/2017 9:13 PM, Magnus Ihse Bursie wrote: > I ran a duplicate name check on the source base. Then I discovered that > there is a jimage.hpp in both src/hotspot/share/classfile/jimage.hpp and > src/java.base/share/native/libjimage/jimage.hpp. They are identical > (apart from copyright headers), and once again, we shouldn't have both. > David Holmes suggested removing the hotspot version, so this I've done. > > I intend to push this to jdk/hs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191203 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191203-remove-duplicated-jimage-hpp/webrev.01 > > > /Magnus From david.holmes at oracle.com Tue Nov 21 11:49:20 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 21 Nov 2017 21:49:20 +1000 Subject: RFR: JDK-8191202 Remove duplicated jmm.h In-Reply-To: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> References: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> Message-ID: <2cd090e5-2272-e3f8-3a9e-da487b3f1550@oracle.com> Hi Magnus, Seems to me that jmm is an interface exported by the VM, so the hotspot version of the header is the one that should survive IMO. David On 21/11/2017 9:42 PM, Magnus Ihse Bursie wrote: > As part of the effort to remove duplicated files between Hotspot and > JDK, the turn has now come to jmm.h. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 > > > /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 21 13:55:57 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Nov 2017 14:55:57 +0100 Subject: RFR: JDK-8191202 Remove duplicated jmm.h In-Reply-To: <2cd090e5-2272-e3f8-3a9e-da487b3f1550@oracle.com> References: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> <2cd090e5-2272-e3f8-3a9e-da487b3f1550@oracle.com> Message-ID: <25e3f830-394d-a549-6889-abf36021e93b@oracle.com> On 2017-11-21 12:49, David Holmes wrote: > Hi Magnus, > > Seems to me that jmm is an interface exported by the VM, so the > hotspot version of the header is the one that should survive IMO. We had a similar discussion about the other header files, were we kept the JDK version, for the time being. A bug, JDK-8190484 was opened to discuss the final location of the one remaining copy. This has in fact already prepared for the removal of the duplicated jmm.h, since it's titled "Revisit the source location of jvm.h and jmm.h". I'd prefer to treat this one similar to the other duplicated header files, and keep the JDK version for the time being. And then leaving it to whoever solves JDK-8190484 to figure out a proper location. Are you okay with that? /Magnus > David > > On 21/11/2017 9:42 PM, Magnus Ihse Bursie wrote: >> As part of the effort to remove duplicated files between Hotspot and >> JDK, the turn has now come to jmm.h. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 >> >> >> /Magnus From magnus.ihse.bursie at oracle.com Tue Nov 21 14:00:26 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 21 Nov 2017 15:00:26 +0100 Subject: RFR: JDK-8191203 Remove duplicated jimage.hpp In-Reply-To: References: Message-ID: <8e65a735-7972-a5eb-94b0-10beee3f42e9@oracle.com> On 2017-11-21 12:44, David Holmes wrote: > Hi Magnus, > > This seems fine to me. > > Do you know what the story is with the copyright header? No, I don't. It was introduced in JDK-8149776, which has just a brief rationale: "Allow the jimage native code to be more easily re-used in JVM implementations which cannot accept code under the GPL." I do not know what prompted this. It seems reasonable to keep the more liberaly licensed version, though. (Which happens to coincide with the JDK version). /Magnus > > Thanks, > David > > On 21/11/2017 9:13 PM, Magnus Ihse Bursie wrote: >> I ran a duplicate name check on the source base. Then I discovered >> that there is a jimage.hpp in both >> src/hotspot/share/classfile/jimage.hpp and >> src/java.base/share/native/libjimage/jimage.hpp. They are identical >> (apart from copyright headers), and once again, we shouldn't have >> both. David Holmes suggested removing the hotspot version, so this >> I've done. >> >> I intend to push this to jdk/hs. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191203 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8191203-remove-duplicated-jimage-hpp/webrev.01 >> >> >> /Magnus From james.laskey at oracle.com Tue Nov 21 14:11:18 2017 From: james.laskey at oracle.com (Jim Laskey (Oracle)) Date: Tue, 21 Nov 2017 10:11:18 -0400 Subject: RFR: JDK-8191203 Remove duplicated jimage.hpp In-Reply-To: <8e65a735-7972-a5eb-94b0-10beee3f42e9@oracle.com> References: <8e65a735-7972-a5eb-94b0-10beee3f42e9@oracle.com> Message-ID: <14AAFF1F-5DF7-4E39-8BBA-CCEC0B091C7C@oracle.com> The file was moved from hs to the jdk to simplify the API, not sure why it?s still there. A bulk merge issue maybe. I don?t recall clearly but I think the BSD license was a request from that other big company. Cheers, ? Jim > On Nov 21, 2017, at 10:00 AM, Magnus Ihse Bursie wrote: > > On 2017-11-21 12:44, David Holmes wrote: >> Hi Magnus, >> >> This seems fine to me. >> >> Do you know what the story is with the copyright header? > No, I don't. It was introduced in JDK-8149776, which has just a brief rationale: > "Allow the jimage native code to be more easily re-used in JVM implementations which cannot accept code under the GPL." I do not know what prompted this. > > It seems reasonable to keep the more liberaly licensed version, though. (Which happens to coincide with the JDK version). > > /Magnus >> >> Thanks, >> David >> >> On 21/11/2017 9:13 PM, Magnus Ihse Bursie wrote: >>> I ran a duplicate name check on the source base. Then I discovered that there is a jimage.hpp in both src/hotspot/share/classfile/jimage.hpp and src/java.base/share/native/libjimage/jimage.hpp. They are identical (apart from copyright headers), and once again, we shouldn't have both. David Holmes suggested removing the hotspot version, so this I've done. >>> >>> I intend to push this to jdk/hs. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191203 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191203-remove-duplicated-jimage-hpp/webrev.01 >>> >>> /Magnus > From tim.bell at oracle.com Tue Nov 21 14:56:09 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 21 Nov 2017 06:56:09 -0800 Subject: RFR: JDK-8191203 Remove duplicated jimage.hpp In-Reply-To: <14AAFF1F-5DF7-4E39-8BBA-CCEC0B091C7C@oracle.com> References: <8e65a735-7972-a5eb-94b0-10beee3f42e9@oracle.com> <14AAFF1F-5DF7-4E39-8BBA-CCEC0B091C7C@oracle.com> Message-ID: <5A143E89.8070807@oracle.com> Magnus: Looks good to me as well. Tim On 11/21/17 06:11, Jim Laskey (Oracle) wrote: > The file was moved from hs to the jdk to simplify the API, not sure why it?s still there. A bulk merge issue maybe. I don?t recall clearly but I think the BSD license was a request from that other big company. > > Cheers, > > ? Jim > >> On Nov 21, 2017, at 10:00 AM, Magnus Ihse Bursie wrote: >> >> On 2017-11-21 12:44, David Holmes wrote: >>> Hi Magnus, >>> >>> This seems fine to me. >>> >>> Do you know what the story is with the copyright header? >> No, I don't. It was introduced in JDK-8149776, which has just a brief rationale: >> "Allow the jimage native code to be more easily re-used in JVM implementations which cannot accept code under the GPL." I do not know what prompted this. >> >> It seems reasonable to keep the more liberaly licensed version, though. (Which happens to coincide with the JDK version). >> >> /Magnus >>> >>> Thanks, >>> David >>> >>> On 21/11/2017 9:13 PM, Magnus Ihse Bursie wrote: >>>> I ran a duplicate name check on the source base. Then I discovered that there is a jimage.hpp in both src/hotspot/share/classfile/jimage.hpp and src/java.base/share/native/libjimage/jimage.hpp. They are identical (apart from copyright headers), and once again, we shouldn't have both. David Holmes suggested removing the hotspot version, so this I've done. >>>> >>>> I intend to push this to jdk/hs. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191203 >>>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191203-remove-duplicated-jimage-hpp/webrev.01 >>>> >>>> /Magnus From erik.joelsson at oracle.com Tue Nov 21 17:49:56 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 Nov 2017 09:49:56 -0800 Subject: RFR: JDK-8191203 Remove duplicated jimage.hpp In-Reply-To: References: Message-ID: Looks good. /Erik On 2017-11-21 03:13, Magnus Ihse Bursie wrote: > I ran a duplicate name check on the source base. Then I discovered > that there is a jimage.hpp in both > src/hotspot/share/classfile/jimage.hpp and > src/java.base/share/native/libjimage/jimage.hpp. They are identical > (apart from copyright headers), and once again, we shouldn't have > both. David Holmes suggested removing the hotspot version, so this > I've done. > > I intend to push this to jdk/hs. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191203 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191203-remove-duplicated-jimage-hpp/webrev.01 > > /Magnus From erik.joelsson at oracle.com Tue Nov 21 17:52:56 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 Nov 2017 09:52:56 -0800 Subject: RFR: JDK-8191202 Remove duplicated jmm.h In-Reply-To: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> References: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> Message-ID: The change looks good. I'm fine with leaving the decision for later with the open bug, but I do think the file should be in the library that exports the API. /Erik On 2017-11-21 03:42, Magnus Ihse Bursie wrote: > As part of the effort to remove duplicated files between Hotspot and > JDK, the turn has now come to jmm.h. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 > > /Magnus From david.holmes at oracle.com Tue Nov 21 21:33:24 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 22 Nov 2017 07:33:24 +1000 Subject: RFR: JDK-8191202 Remove duplicated jmm.h In-Reply-To: References: <204d256a-515b-367b-a31b-7b61326c8f61@oracle.com> Message-ID: <0a52249c-762d-49f1-1811-75b0f1ac740d@oracle.com> On 22/11/2017 3:52 AM, Erik Joelsson wrote: > The change looks good. I'm fine with leaving the decision for later with > the open bug, but I do think the file should be in the library that > exports the API. Exactly! Deferring this placement decision seems pointless to me as the right location is plainly evident for these internal interfaces. It's just double shuffling and wasting time and effort. :( David > /Erik > > > On 2017-11-21 03:42, Magnus Ihse Bursie wrote: >> As part of the effort to remove duplicated files between Hotspot and >> JDK, the turn has now come to jmm.h. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191202 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8191202-remove-duplicated-jmm-h/webrev.01 >> >> >> /Magnus > From erik.joelsson at oracle.com Wed Nov 22 00:33:29 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 21 Nov 2017 16:33:29 -0800 Subject: RFR: JDK-8191744: Remove typo in makefile Message-ID: <26b266be-c0eb-2cb1-f794-203214489eef@oracle.com> I seem to have fat fingered some extra letters into a makefile in a recent change. Those need to be removed. Thanks to Magnus who saw it, albeit too late to stop me. Bug: https://bugs.openjdk.java.net/browse/JDK-8191744 Patch: diff -r 53440b6353b6 test/make/TestCopyFiles.gmk --- a/test/make/TestCopyFiles.gmk +++ b/test/make/TestCopyFiles.gmk @@ -52,7 +52,7 @@ ???? $(TOUCH) $(SRC_DIR)/foo/foofile ???? $(TOUCH) "$(SRC_DIR)/foo/foo file" ???????? # Spaces in directories only works with gnu make 4.0 or later -??????? ifeq (4.0dfd, $(firstword $(sort 4.0 $(MAKE_VERSION)))) +??????? ifeq (4.0, $(firstword $(sort 4.0 $(MAKE_VERSION)))) ???? ? $(MKDIR) -p "$(SRC_DIR)/foo bar" ???? ? $(TOUCH) "$(SRC_DIR)/foo bar/foobarfile" ???? ? $(TOUCH) "$(SRC_DIR)/foo bar/foo bar file" /Erik From tim.bell at oracle.com Tue Nov 21 23:47:17 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 21 Nov 2017 15:47:17 -0800 Subject: RFR: JDK-8191744: Remove typo in makefile In-Reply-To: <26b266be-c0eb-2cb1-f794-203214489eef@oracle.com> References: <26b266be-c0eb-2cb1-f794-203214489eef@oracle.com> Message-ID: <5A14BB05.8050702@oracle.com> Erik: > I seem to have fat fingered some extra letters into a makefile in a > recent change. Those need to be removed. Thanks to Magnus who saw it, > albeit too late to stop me. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191744 > > Patch: > > diff -r 53440b6353b6 test/make/TestCopyFiles.gmk > --- a/test/make/TestCopyFiles.gmk > +++ b/test/make/TestCopyFiles.gmk > @@ -52,7 +52,7 @@ > $(TOUCH) $(SRC_DIR)/foo/foofile > $(TOUCH) "$(SRC_DIR)/foo/foo file" > # Spaces in directories only works with gnu make 4.0 or later > - ifeq (4.0dfd, $(firstword $(sort 4.0 $(MAKE_VERSION)))) > + ifeq (4.0, $(firstword $(sort 4.0 $(MAKE_VERSION)))) > $(MKDIR) -p "$(SRC_DIR)/foo bar" > $(TOUCH) "$(SRC_DIR)/foo bar/foobarfile" > $(TOUCH) "$(SRC_DIR)/foo bar/foo bar file" Looks good. Tim From magnus.ihse.bursie at oracle.com Wed Nov 22 11:02:59 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 22 Nov 2017 12:02:59 +0100 Subject: RFR: JDK-8191715 Update documentation pointing to "common" directory Message-ID: <5544801e-7163-ae11-3f7c-8d6b55c56114@oracle.com> There are multiple places in comments/documentation that points to the now removed "common" directory. Since it does not affect running code, it was not discovered during the transition to the new consolidated structure (nor by me in my follow-up code review...) Bug: https://bugs.openjdk.java.net/browse/JDK-8191715 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191715-remove-mentions-of-common-dir/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Wed Nov 22 14:01:48 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 22 Nov 2017 15:01:48 +0100 Subject: RFR: JDK-8191205 Set native-debug-symbols default to "external" Message-ID: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> We should not have "zipped" as default for native-debug-symbols. In the future, this option should probably be dropped completely, but for now, start by not making it default. Bug: https://bugs.openjdk.java.net/browse/JDK-8191205 Patch inline: diff --git a/make/autoconf/jdk-options.m4 b/make/autoconf/jdk-options.m4 --- a/make/autoconf/jdk-options.m4 +++ b/make/autoconf/jdk-options.m4 @@ -296,13 +296,13 @@ ?????? ], ?????? [ ???????? if test "x$OPENJDK_TARGET_OS" = xaix; then -????????? # AIX doesn't support 'zipped' so use 'internal' as default +????????? # AIX doesn't support 'external' so use 'internal' as default ?????????? with_native_debug_symbols="internal" ???????? else ?????????? if test "x$STATIC_BUILD" = xtrue; then ???????????? with_native_debug_symbols="none" ?????????? else -??????????? with_native_debug_symbols="zipped" +??????????? with_native_debug_symbols="external" ?????????? fi ???????? fi ?????? ]) /Magnus From thomas.stuefe at gmail.com Wed Nov 22 14:24:39 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 22 Nov 2017 15:24:39 +0100 Subject: RFR: JDK-8191205 Set native-debug-symbols default to "external" In-Reply-To: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> References: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> Message-ID: Looks good. Thanks for doing this! ..Thomas On Wed, Nov 22, 2017 at 3:01 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > We should not have "zipped" as default for native-debug-symbols. In the > future, this option should probably be dropped completely, but for now, > start by not making it default. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191205 > Patch inline: > diff --git a/make/autoconf/jdk-options.m4 b/make/autoconf/jdk-options.m4 > --- a/make/autoconf/jdk-options.m4 > +++ b/make/autoconf/jdk-options.m4 > @@ -296,13 +296,13 @@ > ], > [ > if test "x$OPENJDK_TARGET_OS" = xaix; then > - # AIX doesn't support 'zipped' so use 'internal' as default > + # AIX doesn't support 'external' so use 'internal' as default > with_native_debug_symbols="internal" > else > if test "x$STATIC_BUILD" = xtrue; then > with_native_debug_symbols="none" > else > - with_native_debug_symbols="zipped" > + with_native_debug_symbols="external" > fi > fi > ]) > > /Magnus > From erik.helin at oracle.com Wed Nov 22 14:59:18 2017 From: erik.helin at oracle.com (Erik Helin) Date: Wed, 22 Nov 2017 15:59:18 +0100 Subject: RFR: JDK-8191205 Set native-debug-symbols default to "external" In-Reply-To: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> References: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> Message-ID: On 11/22/2017 03:01 PM, Magnus Ihse Bursie wrote: > We should not have "zipped" as default for native-debug-symbols. In the > future, this option should probably be dropped completely, but for now, > start by not making it default. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191205 > Patch inline: > diff --git a/make/autoconf/jdk-options.m4 b/make/autoconf/jdk-options.m4 > --- a/make/autoconf/jdk-options.m4 > +++ b/make/autoconf/jdk-options.m4 > @@ -296,13 +296,13 @@ > ?????? ], > ?????? [ > ???????? if test "x$OPENJDK_TARGET_OS" = xaix; then > -????????? # AIX doesn't support 'zipped' so use 'internal' as default > +????????? # AIX doesn't support 'external' so use 'internal' as default > ?????????? with_native_debug_symbols="internal" > ???????? else > ?????????? if test "x$STATIC_BUILD" = xtrue; then > ???????????? with_native_debug_symbols="none" > ?????????? else > -??????????? with_native_debug_symbols="zipped" > +??????????? with_native_debug_symbols="external" > ?????????? fi > ???????? fi > ?????? ]) Looks good, Reviewed. Thanks for fixing this! Erik > /Magnus From thomas.stuefe at gmail.com Wed Nov 22 15:29:00 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 22 Nov 2017 16:29:00 +0100 Subject: zero build slow Message-ID: Hi all, when building zero on Linux x64, I notice that the build is extremely slow, due to what I assume is jmod ran from the built image, which would only run interpreted? Is my guess true, and if yes, is it possible to use a different jmod? I assume it is not possible to use jmod from the build jdk? Thanks, THomas From glaubitz at physik.fu-berlin.de Wed Nov 22 15:40:24 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 22 Nov 2017 16:40:24 +0100 Subject: zero build slow In-Reply-To: References: Message-ID: Hi Thomas! On 11/22/2017 04:29 PM, Thomas St?fe wrote: > when building zero on Linux x64, I notice that the build is extremely slow, > due to what I assume is jmod ran from the built image, which would only > run interpreted? Is my guess true, and if yes, is it possible to use a > different jmod? I assume it is not possible to use jmod from the build jdk? Some questions: - What hardware are you building on? - What configure options are you using for building? - Which distribution is this on? For reference, my setup: - Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 16 GB RAM - Debian unstable - sh ./configure --with-jvm-variants=zero --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-amd64/ \ --disable-precompiled-headers --disable-warnings-as-errors && make JOBS=32 MAKE_VERBOSE=y \ QUIETLY= LOG=debug CONF=linux-x86_64-normal-zero-release This builds Zero within 5 minutes, building the Server variant takes about the same time. On an AMD Threadripper 1950X, the build takes only about 2 minutes for both variants. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Wed Nov 22 15:40:49 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Nov 2017 15:40:49 +0000 Subject: zero build slow In-Reply-To: References: Message-ID: On 22/11/17 15:29, Thomas St?fe wrote: > when building zero on Linux x64, I notice that the build is extremely slow, > due to what I assume is jmod ran from the built image, which would only run > interpreted? Is my guess true, and if yes, is it possible to use a > different jmod? I assume it is not possible to use jmod from the build jdk? No, because the bootstrap JDK is version N-1. Hmm, I wonder if you could cross-compile the JDK from x86 native -> x86 zero. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From aph at redhat.com Wed Nov 22 15:42:46 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Nov 2017 15:42:46 +0000 Subject: zero build slow In-Reply-To: References: Message-ID: <35bf5a24-5133-47e6-6f68-18ed7322221f@redhat.com> On 22/11/17 15:40, John Paul Adrian Glaubitz wrote: > This builds Zero within 5 minutes, building the Server variant takes about > the same time. On an AMD Threadripper 1950X, the build takes only about > 2 minutes for both variants. You're not making the images. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From thomas.stuefe at gmail.com Wed Nov 22 16:26:57 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 22 Nov 2017 17:26:57 +0100 Subject: zero build slow In-Reply-To: References: Message-ID: Hi guys, thanks for your help. I think the reason is the combination of zero+slowdebug and the fact that we run our own binaries during build (at least this is true for jmod). I am building on Ubuntu 16.4, "normal" machine (i7, 16G ram, ssd). Normally my builds take ~5-10 minutes. My configure line in this case: CONFIGURE_COMMAND_LINE:=--with-boot-jdk=/shared/projects/openjdk/jdks/openjdk9 --with-debug-level=slowdebug --with-jvm-variants=zero --with-native-debug-symbols=internal Wanted slowdebug to test something. Boot jdk is downloaded from adoptopenjdk (I was lazy). When building (make images), top is dominated by jmod, which is taken from the output directory, not the bootstrap vm: 19710 thomas 30 10 1176348 63480 15800 S 100,0 0,4 2:02.64 /shared/projects/openjdk/jdk-hs/output-zero/jdk/bin/jmod -J-XX:+UseSerialGC -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 create --module-version 10-internal --target-platform linux-amd64 --module-path /sha+ Note that my normal (non-zero) slowdebug builds are done in ~5 minutes, but this thing here is now running for 30 minutes and not done yet. Hence my assumption, that we need to run jmod from the build directory and that a zero jmod in slowdebug mode is terrible. It probably makes sense, when I run jmod interpreted and the C++ code is not optimized... Hence my original question, whether I can force the build to use a different jmod. This would also help in cases when I am developing and my hotspot is crashy - currently, the build does not go thru in this case. I will retry with fastdebug to see how much faster this is. Thanks, Thomas On Wed, Nov 22, 2017 at 4:40 PM, John Paul Adrian Glaubitz < glaubitz at physik.fu-berlin.de> wrote: > Hi Thomas! > > On 11/22/2017 04:29 PM, Thomas St?fe wrote: > >> when building zero on Linux x64, I notice that the build is extremely >> slow, >> due to what I assume is jmod ran from the built image, which would only >> run interpreted? Is my guess true, and if yes, is it possible to use a >> different jmod? I assume it is not possible to use jmod from the build >> jdk? >> > > Some questions: > > - What hardware are you building on? > - What configure options are you using for building? > - Which distribution is this on? > > For reference, my setup: > > - Intel(R) Xeon(R) CPU E5-2620 v4 @ 2.10GHz, 16 GB RAM > - Debian unstable > - sh ./configure --with-jvm-variants=zero --with-boot-jdk=/usr/lib/jvm/java-9-openjdk-amd64/ > \ > --disable-precompiled-headers --disable-warnings-as-errors && make > JOBS=32 MAKE_VERBOSE=y \ > QUIETLY= LOG=debug CONF=linux-x86_64-normal-zero-release > > This builds Zero within 5 minutes, building the Server variant takes about > the same time. On an AMD Threadripper 1950X, the build takes only about > 2 minutes for both variants. > > Adrian > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > From thomas.stuefe at gmail.com Wed Nov 22 16:30:32 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 22 Nov 2017 17:30:32 +0100 Subject: zero build slow In-Reply-To: References: Message-ID: On Wed, Nov 22, 2017 at 4:40 PM, Andrew Haley wrote: > On 22/11/17 15:29, Thomas St?fe wrote: > > when building zero on Linux x64, I notice that the build is extremely > slow, > > due to what I assume is jmod ran from the built image, which would only > run > > interpreted? Is my guess true, and if yes, is it possible to use a > > different jmod? I assume it is not possible to use jmod from the build > jdk? > > No, because the bootstrap JDK is version N-1. > > Ah, right. > Hmm, I wonder if you could cross-compile the JDK from x86 native -> x86 > zero. > Does it have to be from the same build? If I build zero and normal product from the same head, could I not use the jmod from the product build for zero? > -- > Andrew Haley > Java Platform Lead Engineer > Red Hat UK Ltd. > EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 > From aph at redhat.com Wed Nov 22 16:31:58 2017 From: aph at redhat.com (Andrew Haley) Date: Wed, 22 Nov 2017 16:31:58 +0000 Subject: zero build slow In-Reply-To: References: Message-ID: <6b8ac21b-7bf8-c3e3-fa7a-05db078b5818@redhat.com> On 22/11/17 16:30, Thomas St?fe wrote: >> Hmm, I wonder if you could cross-compile the JDK from x86 native -> x86 >> zero. >> > Does it have to be from the same build? If I build zero and normal product > from the same head, could I not use the jmod from the product build for > zero? Possibly. I'll leave that question to the build ninjas! -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From christian.tornqvist at oracle.com Wed Nov 22 16:47:07 2017 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 22 Nov 2017 11:47:07 -0500 Subject: RFR: 8191768 - Introduce a concurrency factor to be able to scale up or down jtreg concurrency when running Hotspot tests Message-ID: <4116B07E-105C-4C7C-96DD-22D077F35283@oracle.com> Please review this small change that allows a user to scale up or down the concurrency for running Hotspot jtreg tests using CONCURRENCY_FACTOR. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8191768/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8191768 Thanks, Christian From erik.joelsson at oracle.com Wed Nov 22 16:59:31 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 Nov 2017 08:59:31 -0800 Subject: RFR: JDK-8191715 Update documentation pointing to "common" directory In-Reply-To: <5544801e-7163-ae11-3f7c-8d6b55c56114@oracle.com> References: <5544801e-7163-ae11-3f7c-8d6b55c56114@oracle.com> Message-ID: <9c30f3a6-9e35-c706-b099-be31aa7cb618@oracle.com> Looks good. /Erik On 2017-11-22 03:02, Magnus Ihse Bursie wrote: > There are multiple places in comments/documentation that points to the > now removed "common" directory. Since it does not affect running code, > it was not discovered during the transition to the new consolidated > structure (nor by me in my follow-up code review...) > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191715 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191715-remove-mentions-of-common-dir/webrev.01 > > /Magnus From erik.joelsson at oracle.com Wed Nov 22 17:00:08 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 Nov 2017 09:00:08 -0800 Subject: RFR: JDK-8191205 Set native-debug-symbols default to "external" In-Reply-To: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> References: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> Message-ID: Looks good. /Erik On 2017-11-22 06:01, Magnus Ihse Bursie wrote: > We should not have "zipped" as default for native-debug-symbols. In > the future, this option should probably be dropped completely, but for > now, start by not making it default. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191205 > Patch inline: > diff --git a/make/autoconf/jdk-options.m4 b/make/autoconf/jdk-options.m4 > --- a/make/autoconf/jdk-options.m4 > +++ b/make/autoconf/jdk-options.m4 > @@ -296,13 +296,13 @@ > ?????? ], > ?????? [ > ???????? if test "x$OPENJDK_TARGET_OS" = xaix; then > -????????? # AIX doesn't support 'zipped' so use 'internal' as default > +????????? # AIX doesn't support 'external' so use 'internal' as default > ?????????? with_native_debug_symbols="internal" > ???????? else > ?????????? if test "x$STATIC_BUILD" = xtrue; then > ???????????? with_native_debug_symbols="none" > ?????????? else > -??????????? with_native_debug_symbols="zipped" > +??????????? with_native_debug_symbols="external" > ?????????? fi > ???????? fi > ?????? ]) > > /Magnus From erik.joelsson at oracle.com Wed Nov 22 17:09:10 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 Nov 2017 09:09:10 -0800 Subject: zero build slow In-Reply-To: References: Message-ID: <58e6f8ee-f9ea-de00-c21c-73a282266134@oracle.com> Hello, On 2017-11-22 08:30, Thomas St?fe wrote: > On Wed, Nov 22, 2017 at 4:40 PM, Andrew Haley wrote: > >> On 22/11/17 15:29, Thomas St?fe wrote: >>> when building zero on Linux x64, I notice that the build is extremely >> slow, >>> due to what I assume is jmod ran from the built image, which would only >> run >>> interpreted? Is my guess true, and if yes, is it possible to use a >>> different jmod? I assume it is not possible to use jmod from the build >> jdk? >> >> No, because the bootstrap JDK is version N-1. >> >> > Ah, right. > > >> Hmm, I wonder if you could cross-compile the JDK from x86 native -> x86 >> zero. >> > Does it have to be from the same build? If I build zero and normal product > from the same head, could I not use the jmod from the product build for > zero? > Yes you can indeed! There is a configure option: ? --with-build-jdk??????? path to JDK of same version as is being built[the ????????????????????????? newly built JDK] If set, this jdk is used instead of the newly built jdk for any tool that needs to run, like jmod and jlink. I realize the help text could be more elaborate in explaining this. This option is meant for your usecase as well as an option to speed up cross compilation builds. (When cross compiling, we otherwise have to build a minimal jdk for the host system to run jmod and jlink during the build.) Note that for best performance, point this to the images/jdk directory of the release (non debug) build of the jdk for the native platform. Also note that it's only guaranteed to work if you use the exact same version as you are building zero from. If your build-jdk gets stale, weird things can start happening. /Erik From erik.joelsson at oracle.com Wed Nov 22 17:09:53 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 22 Nov 2017 09:09:53 -0800 Subject: RFR: 8191768 - Introduce a concurrency factor to be able to scale up or down jtreg concurrency when running Hotspot tests In-Reply-To: <4116B07E-105C-4C7C-96DD-22D077F35283@oracle.com> References: <4116B07E-105C-4C7C-96DD-22D077F35283@oracle.com> Message-ID: <0907ebe2-3767-f7f7-c2d6-f9a761b5e4db@oracle.com> Looks good. /Erik On 2017-11-22 08:47, Christian Tornqvist wrote: > Please review this small change that allows a user to scale up or down the concurrency for running Hotspot jtreg tests using CONCURRENCY_FACTOR. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8191768/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8191768 > > Thanks, > Christian From thomas.stuefe at gmail.com Wed Nov 22 17:24:52 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Wed, 22 Nov 2017 18:24:52 +0100 Subject: zero build slow In-Reply-To: <58e6f8ee-f9ea-de00-c21c-73a282266134@oracle.com> References: <58e6f8ee-f9ea-de00-c21c-73a282266134@oracle.com> Message-ID: On Wed, Nov 22, 2017 at 6:09 PM, Erik Joelsson wrote: > Hello, > > On 2017-11-22 08:30, Thomas St?fe wrote: > >> On Wed, Nov 22, 2017 at 4:40 PM, Andrew Haley wrote: >> >> On 22/11/17 15:29, Thomas St?fe wrote: >>> >>>> when building zero on Linux x64, I notice that the build is extremely >>>> >>> slow, >>> >>>> due to what I assume is jmod ran from the built image, which would only >>>> >>> run >>> >>>> interpreted? Is my guess true, and if yes, is it possible to use a >>>> different jmod? I assume it is not possible to use jmod from the build >>>> >>> jdk? >>> >>> No, because the bootstrap JDK is version N-1. >>> >>> >>> Ah, right. >> >> >> Hmm, I wonder if you could cross-compile the JDK from x86 native -> x86 >>> zero. >>> >>> Does it have to be from the same build? If I build zero and normal >> product >> from the same head, could I not use the jmod from the product build for >> zero? >> >> Yes you can indeed! There is a configure option: > > --with-build-jdk path to JDK of same version as is being built[the > newly built JDK] > > If set, this jdk is used instead of the newly built jdk for any tool that > needs to run, like jmod and jlink. I realize the help text could be more > elaborate in explaining this. This option is meant for your usecase as well > as an option to speed up cross compilation builds. (When cross compiling, > we otherwise have to build a minimal jdk for the host system to run jmod > and jlink during the build.) > > Note that for best performance, point this to the images/jdk directory of > the release (non debug) build of the jdk for the native platform. Also note > that it's only guaranteed to work if you use the exact same version as you > are building zero from. If your build-jdk gets stale, weird things can > start happening. > > :) precisely what I needed, thank you! ..Thomas > /Erik > From glaubitz at physik.fu-berlin.de Wed Nov 22 18:31:30 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Wed, 22 Nov 2017 19:31:30 +0100 Subject: zero build slow In-Reply-To: <35bf5a24-5133-47e6-6f68-18ed7322221f@redhat.com> References: <35bf5a24-5133-47e6-6f68-18ed7322221f@redhat.com> Message-ID: <3767bf15-b56b-87a9-2214-48e7e59cb529@physik.fu-berlin.de> On 11/22/2017 04:42 PM, Andrew Haley wrote: > On 22/11/17 15:40, John Paul Adrian Glaubitz wrote: >> This builds Zero within 5 minutes, building the Server variant takes about >> the same time. On an AMD Threadripper 1950X, the build takes only about >> 2 minutes for both variants. > > You're not making the images. You're right, I forgot about that. With the images "make images", the build takes 16 minutes on the same machine. Still acceptable, I would say. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From peterbudai at hotmail.com Wed Nov 22 21:10:28 2017 From: peterbudai at hotmail.com (Peter Budai) Date: Wed, 22 Nov 2017 21:10:28 +0000 Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: <87472397-d1a6-e804-eb02-6fabdd2bbae2@oracle.com> <1727F532-B9DA-42AC-9B3E-6AB93DF349C7@oracle.com> <44d6d053-0666-c6f1-343e-87dc074543fb@oracle.com> <4da0c111-f13f-a814-09e2-906a02eaacb6@oracle.com> <5D41C052-D10F-4E7C-B6A7-4759274D5753@oracle.com> <565779B5-B2EE-40DC-8587-0B21AC788406@oracle.com> , Message-ID: Let me give an update on the current status: * I have managed to build both the 64 and the 32-bit version. * The 64-bit version seems reasonable: ============================== Test summary - w64-bit ============================== TEST TOTAL PASS FAIL ERROR >> jtreg:jdk/test:tier1 1645 1610 34 1 << >> jtreg:langtools/test:tier1 3907 3819 79 9 << jtreg:nashorn/test:tier1 0 0 0 0 jtreg:jaxp/test:tier1 0 0 0 0 ============================== * However the 32-bit version of hotspot contains a bunch of inline assembly pieces which uses an MSC specific syntax, and my ASM knowledge is really limited. I have managed to get a many inline assembly codes from the Linux version, but there are few pieces where I was not able to find a good solution yet, so although the 32-bit version compiles, unfortunately it is not working * I have installed VS Express 2013 and made sure that the ?traditional? Microsoft toolchain is still working with the changes * My OCA has been processed I have a changeset which cleanly applies to JDK9 v181, but I recall you have mentioned earlier that you would like to consider this to JDK10 So what is the best way to open a PR for review? This page: http://openjdk.java.net/contribute/ says I should send the changeset as attachment, but earlier somebody mentioned here that attachments are removed from the developer mailing lists. Best regards, Peter From: Erik Joelsson Sent: Thursday, November 2, 2017 1:07 AM To: Peter Budai; Magnus Ihse Bursie Cc: build-dev at openjdk.java.net Subject: Re: Building OpenJDK9 on MSYS2 I would say a few hours is way too long for tier1, but it of course depends on the hardware used. We typically run it on windows in less than 30 minutes with concurrency set to 6. Not sure what concurrency you used by default. /Erik On 2017-10-27 04:33, Peter Budai wrote: > Hi Magnus, after a little poking I managed to install and use jtreg, thanks for the guidance. > > Make run-test-tier1 resulted a pretty OK result for a first try, at least for run-test-jdk: > Test results: passed: 1,610; failed: 34; error: 1 > It took a few hors to run ? is that normal? > > I?ll review the patchset, and then share that with you. > > P. > > From: Magnus Ihse Bursie > Sent: Thursday, October 26, 2017 11:00 AM > To: Peter Budai > Cc: build-dev at openjdk.java.net > Subject: Re: Building OpenJDK9 on MSYS2 > > > On 2017-10-26 00:01, Peter Budai wrote: > OK, I have found what was missing, it was actually my fault with a missing exception handler. > > So finally OpenJDK build has finished on Windows using gcc toolchain running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it looks promising: > ./build/windows-x86_64-normal-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher.exe --jdk=/home/peterbud/jdk9/build/windows-x86_64-normal-server-fastdebug/jdk > ?. > ?. > ?. > > [----------] Global test environment tear-down > [==========] 346 tests from 54 test cases ran. (3859 ms total) > [ PASSED ] 346 tests. > I'm impressed! :-) > > Would you care to share your current patchset, just to still my curiosity? :-) > > > > What is the best way to test the current build more thoroughly? > "make run-test-tier1". As Erik says, you'll need jtreg, and call "configure --with-jtreg=...". You can get it from the Adopt OpenJDK group here: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > > /Magnus > > > P. > > From: Bob Vandette > Sent: Tuesday, October 24, 2017 8:10 PM > To: Peter Budai > Cc: David Holmes; Erik Joelsson; Magnus Ihse Bursie; build-dev at openjdk.java.net > Subject: Re: Building OpenJDK9 on MSYS2 > > Can you provide some details about your toolchain, processor and os plus > a dump of the native instructions around the SEGV. This might give us > enough info to be able to figure out what?s going on. > > Bob. > > On Oct 24, 2017, at 1:21 PM, Peter Budai > wrote: > > I get that error running in the debugger but also running without/outside of the debugger as well. > > I saw the comment in the code about generating SEGV in function generate_get_cpu_info(), however the debugger can execute that, and the SEGV I experience is coming later in the VM_Version::get_processor_features() function > > Peter > > From: Bob Vandette > Sent: Tuesday, October 24, 2017 6:28 PM > To: Peter Budai > Cc: David Holmes; Erik Joelsson; Magnus Ihse Bursie; build-dev at openjdk.java.net > Subject: Re: Building OpenJDK9 on MSYS2 > > Was this a SEGV while you were running the debugger? > > There is an intentional SEGV generated. This is used to determine if we can use some of newer > CPU features. Try to allow the SEGV to continue to see if you run normally. > > Bob. > > >> On Oct 24, 2017, at 11:37 AM, Peter Budai > wrote: >> >> It seems that the compile is progressing well, I have 49 executables/tools and 38 compiled shared libraries already in the JDK folder. >> >> I have tried to run the product with the simplest ?java -version? command, however I get a SIGSEGV at get_cpu_info_stub() in vm_version_x86.cpp, VM_Version::get_processor_features() >> >> get_cpu_info_stub(&_cpuid_info); >> >> Thread 5 received signal SIGSEGV, Segmentation fault. >> 0x000000002d9a072f in ?? () >> >> I can debug using gdb, but unfortunately this is pure ASM, and my knowledge on this is close to 0. >> >> Any idea help or pointer how could I tackle this? >> >> Peter >> >> From: David Holmes >> Sent: Sunday, October 15, 2017 10:37 PM >> To: Peter Budai; Erik Joelsson; Magnus Ihse Bursie >> Cc: build-dev at openjdk.java.net >> Subject: Re: Building OpenJDK9 on MSYS2 >> >> On 16/10/2017 12:41 AM, Peter Budai wrote: >>> A quick status update: >>> >>> * Hotspot successfully compiled without warnings >>> * I?d like to run the unit tests, but as I see ?make check? does not work, and gtestlauncher expects a command line parameter jdk. Tried to look up some documentation on this, but have not found. So the question is: how can I run unit tests for hotspot? Do I need also JDK compiled for that? Or the bootJDK is good enough? Any help would be appreciated. >> Hotspot has to be tested as part of a full JDK - you can't load the JVM >> without having the "J" part :) >> >> You should be able to drop your built dll into an existing JDK 9 windows >> JDK and test it that way. >> >> David >> ----- >> >>> * Also I?m making progress on compiling jdk, but there are some very interesting solutions on windows linking which makes a bit more difficult to compile with gcc: LIBS_windows contains sometimes simple library names (which I believe is correct) and other times library names with full path (which I believe is not the best solution). I?m trying to rework those places and use simple library names and passing search path for libraries -L (for gcc toolchain) and /LIBPATH: (for Microsoft toolchain). Also I was surprised by a few manual function name exports? >>> * jdk code base contains apparently more MSVC specific part, many places casts/lack of casts are generating errors, static attributes were missing etc. a bit tedious work. >>> >>> P. >>> >>> From: Erik Joelsson >>> Sent: Wednesday, October 11, 2017 4:16 PM >>> To: Magnus Ihse Bursie; Peter Budai >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> Hello, >>> >>> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: >>> >>> For gcc, we let the compiler generate the .d file. For the Microsoft tool chain, we use a clever sed script to extract and create it ourself. >>> >>> I think that logic is checking for "Windows", not "Microsoft". That might be your cause of trouble. >>> >>> Look in NativeCompilation.gmk. >>> >>> That was my initial thought as well, but we do correctly check for microsoft. Also it's not the .d files that are the problem. As Peter just wrote, they look fine. It's the .d.target files which we create using the same technique on all platforms. What we don't account for is the compiler putting Windows mixed paths in the .d files. >>> >>> /Magnus >>> >>> 11 okt. 2017 kl. 14:43 skrev Peter Budai >: >>> Hi Erik, >>> >>> The .d file looks like this: >>> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: \ >>> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp \ >>> >>> I have checked .d.targets file, and looks like it has the first line has not been deleted, and the file names below are also wrong: >>> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj : : >>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp : >>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : >>> >>> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by the ?C:/? >>> -e 's/^[^:]*: *//' >>> >>> Yes, that does indeed look like the problem. I suppose the regexp is unnecessarily strict. It should be ok to rewrite it as something like this: >>> -e 's/^.*: *//' >>> >>> Basically just make sure it ends with : and any number of spaces. >>> >>> /Erik >>> >>> >>> >>> Peter >>> >>> Sent from Mail for Windows 10 >>> >>> From: Erik Joelsson >>> Sent: Wednesday, October 11, 2017 12:16 PM >>> To: Peter Budai; Magnus Ihse Bursie; build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> >>> Hello Peter, >>> >>> On 2017-10-11 00:18, Peter Budai wrote: >>> Thanks Magnus & Erik >>> >>> First thanks for your support and kind words! >>> >>> Magnus, I have checked .bash_profile, .bashrc but they seem to be empty (everything is commented out). You can check with a default MSYS2 install, I have not changed these files at all. If you find thee something specific I can give a try here as well. >>> >>> Let me give also a quick status update, where am I with building hotspot: >>> ? I guess its still the beginning, but I have managed to compile jvm.dll with almost 700 object file: with debug info the dll is around 700 MB ? >>> ? I made only surgical, minimal changes to the source, and so far it looks reasonable. I have encountered 3 scenarios where changes were necessary: >>> o When in makefiles conditionals were using assuming that if target_os is windows then it is visual studio compiler/linker. Obviously these conditionals had to be reviewed in a few places and if necessary were changes to check the toolchain=Microsoft >>> These are not surprising and should be pretty straight forward to fix and it seems you know what to do. >>> >>> >>> ? >>> o I got a few warnings as gcc 7.2 uncovered some code problems in windows specific codes, where before that MSVC I guess did not say a word? >>> To get around this you can configure with --disable-warnings-as-errors until you get things working properly. This is commonly needed when using compiler versions that we normally don't use. >>> >>> >>> ? >>> o And I had like 6-7 places where the code was using MSVC specific __try ? __except structures which gcc does not know. Do you have a suggestion how to approach them? I can do ugly #ifdefs (I would avoid that) but I have also seen some solutions to replace them with a code which gcc can compile (http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh ) ? but before doing that though I would ask first you on the purpose of those >>> This kind of question is probably best to bring to the hotspot mailing list. >>> ? What bothers me is that I was not able to do incremental builds: when an error occurs, and build stops, then after making change in the CPP source the build cannot continue, I always got an error message: >>> >>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.d.targets:1: *** missing target pattern. Stop. >>> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 >>> >>> If I do a ?make clean? and restart the build then it nicely compiles. >>> >>> Question 1: Is there a way to resume such builds without ?make clean?? >>> Well, incremental builds is supposed to work well. We have several extra tricks in there to handle cases where normal make builds would fail. The *.d.targets files is one such trick and it seems to backfire for you. The contents of that file should be something like: >>> >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : >>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : >>> >>> Basically an empty rule for each dependency for the corresponding object file. Declaring these rules makes it possible to delete source files without having to build clean. It seems your file is not generated correctly so please have a look inside it. The file is in make/common/NativeCompilation.gmk, look for DEPENDENCY_TARGET_SED_PATTERN. >>> >>> >>> >>> Question 2: What would be the best way to submit/share the patches for your thorough review? >>> >>> Well, first of all, have you signed the OCA? >>> >>> As for publishing patches and reviews, there is a bit of chicken and egg problem. Once you become an "author" in any of the OpenJDK projects, you get a user name and should be able to publish reviews on cr.openjdk.java.net>>. Before that, if the patch is small, it can be posted inline in an email to the list. If it's large, you will need a current OpenJDK user to host it for you. At least that's how I understand it. Hopefully someone who knows the process better can chime in here. >>> >>> I should also let you know that getting this into JDK 9 is most likely not going to happen. AFAIK we are only doing security updates for 9. It would have to go into the currently active release. I should also warn you that new ports generally need a certain amount of backing to be accepted. It may be that this would have to live in a porting side project. Hopefully someone who knows this better can chime in here as well. >>> >>> /Erik >>> >>> >>> P. >>> >>> Sent from Mail for Windows 10 >>> >>> From: Magnus Ihse Bursie >>> Sent: Tuesday, October 10, 2017 10:04 AM >>> To: Peter Budai; Erik Joelsson; build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> On 2017-10-07 10:14, Peter Budai wrote: >>> The configure of OpenJDK overwrites the SHELL. Actually it is using bash, but for the arguments it was using ?-e -o pipefail?. I have figured that for MSYS2 bash what is needed as bash arguments is ?-e -l -c -o pipefail? >>> >>> That looks like solving this problem, and now the real issues are surfacing. >>> >>> FWIW, "-l" makes bash behave like a login shell. Most likely you are changing bash's behavior in one of your login scripts, and that change is what's really needed. >>> >>> /Magnus >>> >>> >>> >>> >>> >>> Peter >>> >>> From: Peter Budai >>> Sent: Friday, October 6, 2017 6:43 PM >>> To: Magnus Ihse Bursie; Erik Joelsson; build-dev at openjdk.java.net >>> Subject: RE: Building OpenJDK9 on MSYS2 >>> >>> Magnus, >>> >>> I have followed your suggestion and removed the fixpath prefixes from gcc related compile tools, and left only the fixpath prefix _only_ for the Boot JDK related tools in place. >>> >>> 1) As I follow the process, all java and javac related compile steps are running properly >>> 2) When the process reaches gcc related steps I got the error message at the same place as before (no fixpath). If I execute that command from the bash prompt, it creates the output: >>> >>> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template && /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java >>> >>> As I have mentioned the parameters are replaced by the bash automatically >>> 3) Then build continues, then little later stops at a super simple command: >>> >>> mv /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBuffer.java >>> Needless to say, the ByteBuffer.java.tmp file DOES exist. And running the above command from the bash works, and build continues. >>> 4) A few similar cases (stops) with DirectByteBuffer and DirectByteBufferR >>> >>> >>> Currently I try to explore how that might relate to the MSYS2 bash and make, somehow it behaves differently >>> >>> If you have any other suggestion, let me know. >>> >>> Best regards, >>> >>> Peter >>> >>> From: Peter Budai >>> Sent: Thursday, October 5, 2017 3:52 PM >>> To: Magnus Ihse Bursie; Erik Joelsson; build-dev at openjdk.java.net >>> Subject: RE: Building OpenJDK9 on MSYS2 >>> >>> Hi Magnus, >>> >>> So first of all, here is the current patch, which I was not able to attach: https://pastebin.com/pwT4Ynxc >>> >>>>> That's surprising, since gcc is prefixed with fixpath, which it should not. >>> Actually you DO need fixpath IMHO. >>> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), which is a fully functional Windows executable, which expects Windows formatted path arguments. >>> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see that patch), none of the command line arguments are converted from the unix path to Windows, but fixpath does that conversion. There is a wiki describing more details on this: >>> https://github.com/msys2/msys2/wiki/Porting#user-content-filesystem-namespaces >>> >>> >>> >>>>> I have a hard time believing this is a race condition. On the other hand, this stuff is weird, we're misusing the C preprocessor to process defines in java code, so I'm not surprised it breaks down. >>>>> I don't know why it succeeded when run on the command line, though. >>> When I execute that command from the bash command line there is no EXPORT MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic conversion of the arguments. Maybe it has something to do how fixpath does CreateProcess? >>> >>> Does that help? >>> >>> Best regards, >>> >>> Peter >>> >>> Sent from Mail for Windows 10 >>> >>> From: Magnus Ihse Bursie >>> Sent: Thursday, October 5, 2017 12:13 PM >>> To: Peter Budai; Erik Joelsson; build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> >>> On 2017-10-05 11:59, Peter Budai wrote: >>> Hi Magnus and Erik, >>> >>> I really appreciate your quick feedback. I assumed that it won?t be easy, but I just don?t feel I should give up now - maybe later when I see the real scale of work. So bear with me for a time being. >>> >>> Attached is a patch which already includes Magnus? changes, plus a few which I have added: >>> ? basically enabling gcc for windows, >>> ? and modifying a logic for compiling fixpath (before that it was using hard-coded MS VSC compile flags) >>> >>> Actually, you must make sure fixpath is *not* used for the toolchain, since gcc uses unix style paths. >>> (However, other tools such as java will still need it.) >>> >>> >>> >>> >>> >>> >>> So here is what I have as the result of configure: >>> ==================================================== >>> The existing configuration has been successfully updated in >>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release >>> using configure arguments '--disable-freetype-bundling --disable-javac-server'. >>> >>> Configuration summary: >>> * Debug level: release >>> * HS debug level: product >>> * JDK variant: normal >>> * JVM variants: server >>> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 >>> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) >>> >>> Tools summary: >>> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) >>> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) >>> * Toolchain: gcc (GNU Compiler Collection) >>> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) >>> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) >>> >>> Build performance summary: >>> * Cores to use: 4 >>> * Memory limit: 16216 MB >>> >>> Its clear says that the toolchain is gcc 7.2 (BTW there is no Visual Studio on this machine) >>> >>> Now for the details of the config log, you can see here: https://pastebin.com/MN2ZYcHH >>> >>> And about the build process and the error I get: >>> >>> $ make JOBS=1 >>> Building target 'default (exploded-image)' in configuration 'windows-x86_64-normal-server-release' >>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >>> Compiling 17 properties into resource bundles for jdk.compiler >>> Parsing 1 properties into enum-like class for jdk.compiler >>> Compiling 19 properties into resource bundles for jdk.javadoc >>> Compiling 12 properties into resource bundles for jdk.jdeps >>> Compiling 7 properties into resource bundles for jdk.jshell >>> Compiling 117 files for BUILD_INTERIM_java.compiler >>> Compiling 396 files for BUILD_INTERIM_jdk.compiler >>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps >>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc >>> Note: Some input files use or override a deprecated API. >>> Note: Recompile with -Xlint:deprecation for details. >>> Compiling 159 files for BUILD_TOOLS_JDK >>> Note: Some input files use unchecked or unsafe operations. >>> Note: Recompile with -Xlint:unchecked for details. >>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>> make[3]: *** Deleting file '/C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java' >>> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 >>> >>> ERROR: Build failed for target 'default (exploded-image)' in configuration 'windows-x86_64-normal-server-release' (exit code 2) >>> >>> No indication of failed target found. >>> Hint: Try searching the build log for '] Error'. >>> Hint: See common/doc/building.html#troubleshooting for assistance. >>> >>> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 >>> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 >>> >>> If I run here >>> make JOBS=1 LOG=debug >>> The failing line seems to be this: >>> >>> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template && /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java >>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>> >>> Now the interesting is: if I copy this line above to the bash prompt, it runs without problem, and the file support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java >>> That's surprising, since gcc is prefixed with fixpath, which it should not. >>> >>> I have a hard time believing this is a race condition. On the other hand, this stuff is weird, we're misusing the C preprocessor to process defines in java code, so I'm not suprised it breaks down. I don't know why it succeeded when run on the command line, though. My suggestion is to just do some quick and dirty hack around this: take the file you manage to generate and just copy it in during the build instead. If you can get round this, you might start seeing some *real* problems. :-) >>> >>> Also, my suggestion is that you try running "make hotspot" to cut to the chase. Compiling hotspot will likely be the hardest thing. Or even "make -k hotspot" to get an assessment of the amount of work ahead of you. >>> >>> /Magnus >>> Is produced. >>> >>> Then I can again issue >>> make JOBS=1 LOG=debug >>> >>> And the compile process is being continued, until a similar error pops up with a different generated file. I have an assumption that this happens because make is still running parallel jobs, despite JOBS=1 but I?m not sure. >>> >>> How could I best tackle this? >>> >>> Thank you and best regards, >>> >>> Peter >>> >>> Sent from Mail for Windows 10 >>> >>> From: Magnus Ihse Bursie >>> Sent: Thursday, October 5, 2017 11:33 AM >>> To: Erik Joelsson; Peter Budai; build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> On 2017-10-05 10:10, Erik Joelsson wrote: >>>> Hello Peter, >>>> >>>> >>>> On 2017-10-04 21:15, Peter Budai wrote: >>>>> Hi Magnus, >>>>> >>>>> Thanks for the quick reply I?ll check these patches with msys2. >>>>> >>>>> Let me specify with more details what I?d like to achieve: I?d like >>>>> to build OpenJDK9 with MSYS2 MINGW64 environment using gcc toolchain. >>>>> (I?m not sure how familiar are you with MSYS2, but there are 3 >>>>> different environments: MSYS2, MINGW32 and MINGW64). In theory >>>>> MINGW64 with gcc is the closes you can get on Windows platform as a >>>>> gcc unix like build environment, which produces still a native 64-bit >>>>> executable on Windows. >>>>> >>>>> I?m not very familiar with OpenJDK yet, so therefore I?d like to hear >>>>> your opinion: how realistic is that? >>>> Sorry to disappoint, but I would say that requires major work. There >>>> is a strong historic assumption that windows builds are done using >>>> Visual Studio. We have abstracted away some of it in configure (see >>>> TOOLCHAIN_TYPE), but it's very far from enough to change compiler >>>> environment for a Windows build. The native sources are also bound to >>>> make a lot of such assumptions. I would expect the changes needed to >>>> be in the thousands of lines of code. >>> I agree that it requires hard work (even if "thousands" might be an >>> overestimation I think, but "hundreds" is not enough, so it's the right >>> magnitude). On the other hand, it would be really good if we did sort >>> things out, so that we had proper conditions based on OS vs >>> compiler/toolchain. >>> >>> If you really want to start, the first thing is to patch toolchain.m4 to >>> VALID_TOOLCHAINS_windows="microsoft gcc" >>> and then call configure using "bash configure --with-toolchain-type=gcc". >>> >>> As Erik, I doubt you will come very far before things starts tumbling down. >>> >>>> When we say supporting the build in msys2 instead of cygwin, we just >>>> mean using msys2 as the unix emulating layer for our tools like >>>> make/bash/grep/sed etc. >>>> >>>> One think I have done successfully is running the build in WSL >>>> (Windows Subsystem for Linux), but that isn't all that helpful as WSL >>>> for practical purposes is more or less like running Linux in a VM, so >>>> the build sees a Linux system and builds a Linux binary. >>>>> As a side note: with MINGW64 I have managed to run configure phase >>>>> successfully for OpenJDK. The compile process has also started and >>>>> went for a while, but interestingly I run into some kind of race >>>>> conditions as make stopped with an error. Using LOG=debug I have fond >>>>> the failing line and then copying the failed command and pasting it >>>>> to the bash prompt it successfully generated the output target, and >>>>> then the build process run further when a similar situation happened. >>>>> Also pasting the failed command run in the bash without any problem, >>>>> and build continued? until the next. >>>> Without seeing the errors I can't say much. I very much doubt that you >>>> are running with gcc as the compiler though. Configure isn't easily >>>> fooled into using a different compiler to what it prefers, and I would >>>> expect things to crash and burn pretty early if you actually did. >>>> >>>> /Erik >>>>> I have tried to run make JOBS=1, but did not help, strangely I have >>>>> still seen in the log make[3] and make[4] logs which suggested that >>>>> there are more than one make jobs were running. Also tried .configure >>>>> --with-output-sync=recurse without success (same symptoms) >>>>> >>>>> Let me know your thoughts. >>>>> >>>>> Best regards, >>>>> >>>>> Peter >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Magnus Ihse Bursie >>>>> Sent: Wednesday, October 4, 2017 1:04 AM >>>>> To: Peter Budai; >>>>> build-dev at openjdk.java.net >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> Actually, it wasn't so much remaining trouble. :-) I fired up msys2 and >>>>> checked out where I left off. It turned out that the remaining snag was >>>>> that msys2 tries to convert command lines automatically, from "unix" >>>>> style paths to "windows" style paths. Unfortunately, it does not do this >>>>> very well and it breaks all sorts of things. We already have a FIXPATH >>>>> solution in place which deals with this, so basically all I had to do >>>>> was disable this (by setting MSYS2_ARG_CONV_EXCL to "*"). However, this >>>>> broke our cygpath replacement hack (!) so I had to disable it there. >>>>> Sigh. Anyway, with those fixes it ran and worked well. (I also >>>>> discovered and fixed a bug related to how we set up the FIXPATH variable >>>>> on msys, but it only triggers in certain circumstances). >>>>> >>>>> With this patch I now jdk9 seems to build fine on msys2. It should apply >>>>> cleanly on jdk9/jdk9. Since it turned out to be so trivial, I'll try to >>>>> get it in in jdk10. >>>>> >>>>> Here's the patch if you want to apply it yourself: >>>>> >>>>> diff -r a08cbfc0e4ec common/autoconf/basics_windows.m4 >>>>> --- a/common/autoconf/basics_windows.m4 Thu Aug 03 18:56:56 2017 >>>>> +0000 >>>>> +++ b/common/autoconf/basics_windows.m4 Wed Oct 04 00:53:58 2017 >>>>> +0200 >>>>> @@ -42,7 +42,7 @@ >>>>> windows_path=`$CYGPATH -m "$unix_path"` >>>>> $1="$windows_path" >>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then >>>>> - windows_path=`cmd //c echo $unix_path` >>>>> + windows_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $unix_path` >>>>> $1="$windows_path" >>>>> fi >>>>> ]) >>>>> @@ -136,6 +136,16 @@ >>>>> fi >>>>> ]) >>>>> >>>>> +AC_DEFUN([BASIC_MSYS_UPDATE_FIXPATH], >>>>> +[ >>>>> + # Take all collected prefixes and turn them into a >>>>> -m/c/foo@/c/bar at ... command line >>>>> + # @ was chosen as separator to minimize risk of other tools messing >>>>> around with it >>>>> + all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >>>>> + | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>> + fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >>>>> + FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>> +]) >>>>> + >>>>> AC_DEFUN([BASIC_FIXUP_PATH_MSYS], >>>>> [ >>>>> path="[$]$1" >>>>> @@ -143,7 +153,7 @@ >>>>> new_path="$path" >>>>> if test "x$has_colon" = x; then >>>>> # Not in mixed or Windows style, start by that. >>>>> - new_path=`cmd //c echo $path` >>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $path` >>>>> fi >>>>> >>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>> @@ -155,6 +165,8 @@ >>>>> >>>>> # Save the first 10 bytes of this path to the storage, so fixpath >>>>> can work. >>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>> "${new_path:0:10}") >>>>> + # We might need to re-evaluate FIXPATH. >>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>> ]) >>>>> >>>>> AC_DEFUN([BASIC_FIXUP_EXECUTABLE_CYGWIN], >>>>> @@ -293,7 +305,7 @@ >>>>> # Do not save /bin paths to all_fixpath_prefixes! >>>>> else >>>>> # Not in mixed or Windows style, start by that. >>>>> - new_path=`cmd //c echo $new_path` >>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $new_path` >>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>> # Output is in $new_path >>>>> BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(new_path) >>>>> @@ -302,6 +314,8 @@ >>>>> >>>>> # Save the first 10 bytes of this path to the storage, so fixpath >>>>> can work. >>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>> "${new_path:0:10}") >>>>> + # We might need to re-evaluate FIXPATH. >>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>> fi >>>>> ]) >>>>> >>>>> @@ -347,6 +361,10 @@ >>>>> WINDOWS_ENV_VENDOR='msys' >>>>> WINDOWS_ENV_VERSION="$MSYS_VERSION" >>>>> >>>>> + # Prohibit msys2 path conversion from trying to be "intelligent", >>>>> and rely >>>>> + # on fixpath instead. >>>>> + export MSYS2_ARG_CONV_EXCL="*" >>>>> + >>>>> AC_MSG_CHECKING([msys root directory as unix-style path]) >>>>> # The cmd output ends with Windows line endings (CR/LF), the grep >>>>> command will strip that away >>>>> MSYS_ROOT_PATH=`cd / ; cmd /c cd | $GREP ".*"` >>>>> @@ -391,10 +409,7 @@ >>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.msys; then >>>>> # Take all collected prefixes and turn them into a >>>>> -m/c/foo@/c/bar at ... command line >>>>> # @ was chosen as separator to minimize risk of other tools >>>>> messing around with it >>>>> - all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >>>>> - | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>> - fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >>>>> - FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>> fi >>>>> FIXPATH_SRC_W="$FIXPATH_SRC" >>>>> FIXPATH_BIN_W="$FIXPATH_BIN" >>>>> diff -r a08cbfc0e4ec common/autoconf/build-aux/config.sub >>>>> --- a/common/autoconf/build-aux/config.sub Thu Aug 03 18:56:56 >>>>> 2017 +0000 >>>>> +++ b/common/autoconf/build-aux/config.sub Wed Oct 04 00:53:58 >>>>> 2017 +0200 >>>>> @@ -30,7 +30,7 @@ >>>>> DIR=`dirname $0` >>>>> >>>>> # First, filter out everything that doesn't begin with "aarch64-" >>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>> . $DIR/autoconf-config.sub "$@" >>>>> # autoconf-config.sub exits, so we never reach here, but just in >>>>> # case we do: >>>>> @@ -38,13 +38,17 @@ >>>>> fi >>>>> >>>>> while test $# -gt 0 ; do >>>>> - case $1 in >>>>> + case $1 in >>>>> -- ) # Stop option processing >>>>> shift; break ;; >>>>> aarch64-* ) >>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>> sub_args="$sub_args $config" >>>>> shift; ;; >>>>> + *-msys ) >>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>> + sub_args="$sub_args $config" >>>>> + shift; ;; >>>>> - ) # Use stdin as input. >>>>> sub_args="$sub_args $1" >>>>> shift; break ;; >>>>> diff -r a08cbfc0e4ec common/autoconf/spec.gmk.in >>>>> --- a/common/autoconf/spec.gmk.in Thu Aug 03 18:56:56 2017 +0000 >>>>> +++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 +0200 >>>>> @@ -120,6 +120,13 @@ >>>>> # On Windows, the Visual Studio toolchain needs the PATH to be >>>>> adjusted >>>>> # to include Visual Studio tools (this needs to be in cygwin/msys >>>>> style). >>>>> export PATH:=@VS_PATH@ >>>>> + >>>>> +endif >>>>> + >>>>> +ifeq ($(OPENJDK_TARGET_OS_ENV), windows.msys) >>>>> + # On msys2, prohibit msys path conversion from trying to be >>>>> + # "intelligent", and rely on fixpath instead. >>>>> + export MSYS2_ARG_CONV_EXCL:=* >>>>> endif >>>>> >>>>> SYSROOT_CFLAGS := @SYSROOT_CFLAGS@ >>>>> >>>>> /Magnus >>>>> >>>>> On 2017-10-03 22:34, Magnus Ihse Bursie wrote: >>>>>> I gave msys2 a shot some time ago, but it ended up too much trouble. >>>>>> I'll share some of my notes from that attempt, for what it's worth. >>>>>> >>>>>> To install package X/Y, run "pacman -S X/Y". Missing tools and >>>>>> packages where to find them: >>>>>> cmp: msys/diffutils >>>>>> tar: msys/tar >>>>>> make: msys/make >>>>>> unzip: msys/unzip >>>>>> zip: msys/zip >>>>>> >>>>>> config.sub reports msys as "x86_64-pc-mingw32" but msys2 as >>>>>> "x86_64-pc-msys". This patch adds postprocessing in "our" config.sub >>>>>> to report msys2 similar to msys. (Opinions, including my own :-) may >>>>>> vary if this really is the best way..) >>>>>> >>>>>> diff -r b88023f46daa common/autoconf/build-aux/config.sub >>>>>> --- a/common/autoconf/build-aux/config.sub Fri Jan 27 10:15:41 >>>>>> 2017 +0100 >>>>>> +++ b/common/autoconf/build-aux/config.sub Fri Feb 03 05:00:25 >>>>>> 2017 -0700 >>>>>> @@ -30,7 +30,7 @@ >>>>>> DIR=`dirname $0` >>>>>> >>>>>> # First, filter out everything that doesn't begin with "aarch64-" >>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>> . $DIR/autoconf-config.sub "$@" >>>>>> # autoconf-config.sub exits, so we never reach here, but just in >>>>>> # case we do: >>>>>> @@ -45,6 +45,10 @@ >>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>> sub_args="$sub_args $config" >>>>>> shift; ;; >>>>>> + *-msys ) >>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>> + sub_args="$sub_args $config" >>>>>> + shift; ;; >>>>>> - ) # Use stdin as input. >>>>>> sub_args="$sub_args $1" >>>>>> shift; break ;; >>>>>> >>>>>> If I remember correctly, this got me past the configure stage at the >>>>>> time. >>>>>> >>>>>> I don't think it's very hard to get it to work on msys2, I just ran >>>>>> into one snag too many and didn't think msys2 would be used by anyone. >>>>>> >>>>>> /Magnus >>>>>> >>>>>> On 2017-10-03 17:20, Peter Budai wrote: >>>>>>> Hello, >>>>>>> >>>>>>> According to >>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/common/doc/building.html >>>>>>> >>>>>>> ?msys2 and the new Windows Subsystem for Linux (WSL) would likely be >>>>>>> possible to support in a future version but that would require a >>>>>>> community effort to implement? >>>>>>> >>>>>>> I?d like to help making the OpenJDK 9 build working on msys2. What is >>>>>>> the best way to move forward? Is there a similar effort in progress? >>>>>>> >>>>>>> Thank you and best regards, >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> > > > From jonathan.gibbons at oracle.com Wed Nov 22 21:28:38 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 22 Nov 2017 13:28:38 -0800 Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: <1727F532-B9DA-42AC-9B3E-6AB93DF349C7@oracle.com> <44d6d053-0666-c6f1-343e-87dc074543fb@oracle.com> <4da0c111-f13f-a814-09e2-906a02eaacb6@oracle.com> <5D41C052-D10F-4E7C-B6A7-4759274D5753@oracle.com> <565779B5-B2EE-40DC-8587-0B21AC788406@oracle.com> , Message-ID: <5A15EC06.4000203@oracle.com> Peter, With over 120 :tier1 test failures, it would be worth understanding the test failures as part of moving forward. There should normally be no :tier1 test failures. -- Jon On 11/22/2017 01:10 PM, Peter Budai wrote: > Let me give an update on the current status: > > * I have managed to build both the 64 and the 32-bit version. > * The 64-bit version seems reasonable: > > > > ============================== > > Test summary - w64-bit > > ============================== > > TEST TOTAL PASS FAIL ERROR > >>> jtreg:jdk/test:tier1 1645 1610 34 1 << >>> jtreg:langtools/test:tier1 3907 3819 79 9 << > jtreg:nashorn/test:tier1 0 0 0 0 > > jtreg:jaxp/test:tier1 0 0 0 0 > > ============================== > > * However the 32-bit version of hotspot contains a bunch of inline assembly pieces which uses an MSC specific syntax, and my ASM knowledge is really limited. I have managed to get a many inline assembly codes from the Linux version, but there are few pieces where I was not able to find a good solution yet, so although the 32-bit version compiles, unfortunately it is not working > * I have installed VS Express 2013 and made sure that the ?traditional? Microsoft toolchain is still working with the changes > * My OCA has been processed > > I have a changeset which cleanly applies to JDK9 v181, but I recall you have mentioned earlier that you would like to consider this to JDK10 > > So what is the best way to open a PR for review? This page: http://openjdk.java.net/contribute/ says I should send the changeset as attachment, but earlier somebody mentioned here that attachments are removed from the developer mailing lists. > > Best regards, > > Peter > > From: Erik Joelsson > Sent: Thursday, November 2, 2017 1:07 AM > To: Peter Budai; Magnus Ihse Bursie > Cc: build-dev at openjdk.java.net > Subject: Re: Building OpenJDK9 on MSYS2 > > I would say a few hours is way too long for tier1, but it of course > depends on the hardware used. We typically run it on windows in less > than 30 minutes with concurrency set to 6. Not sure what concurrency you > used by default. > > /Erik > > > On 2017-10-27 04:33, Peter Budai wrote: >> Hi Magnus, after a little poking I managed to install and use jtreg, thanks for the guidance. >> >> Make run-test-tier1 resulted a pretty OK result for a first try, at least for run-test-jdk: >> Test results: passed: 1,610; failed: 34; error: 1 >> It took a few hors to run ? is that normal? >> >> I?ll review the patchset, and then share that with you. >> >> P. >> >> From: Magnus Ihse Bursie >> Sent: Thursday, October 26, 2017 11:00 AM >> To: Peter Budai >> Cc: build-dev at openjdk.java.net >> Subject: Re: Building OpenJDK9 on MSYS2 >> >> >> On 2017-10-26 00:01, Peter Budai wrote: >> OK, I have found what was missing, it was actually my fault with a missing exception handler. >> >> So finally OpenJDK build has finished on Windows using gcc toolchain running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it looks promising: >> ./build/windows-x86_64-normal-server-fastdebug/hotspot/variant-server/libjvm/gtest/gtestLauncher.exe --jdk=/home/peterbud/jdk9/build/windows-x86_64-normal-server-fastdebug/jdk >> ?. >> ?. >> ?. >> >> [----------] Global test environment tear-down >> [==========] 346 tests from 54 test cases ran. (3859 ms total) >> [ PASSED ] 346 tests. >> I'm impressed! :-) >> >> Would you care to share your current patchset, just to still my curiosity? :-) >> >> >> >> What is the best way to test the current build more thoroughly? >> "make run-test-tier1". As Erik says, you'll need jtreg, and call "configure --with-jtreg=...". You can get it from the Adopt OpenJDK group here: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >> >> /Magnus >> >> >> P. >> >> From: Bob Vandette >> Sent: Tuesday, October 24, 2017 8:10 PM >> To: Peter Budai >> Cc: David Holmes; Erik Joelsson; Magnus Ihse Bursie; build-dev at openjdk.java.net >> Subject: Re: Building OpenJDK9 on MSYS2 >> >> Can you provide some details about your toolchain, processor and os plus >> a dump of the native instructions around the SEGV. This might give us >> enough info to be able to figure out what?s going on. >> >> Bob. >> >> On Oct 24, 2017, at 1:21 PM, Peter Budai > wrote: >> >> I get that error running in the debugger but also running without/outside of the debugger as well. >> >> I saw the comment in the code about generating SEGV in function generate_get_cpu_info(), however the debugger can execute that, and the SEGV I experience is coming later in the VM_Version::get_processor_features() function >> >> Peter >> >> From: Bob Vandette >> Sent: Tuesday, October 24, 2017 6:28 PM >> To: Peter Budai >> Cc: David Holmes; Erik Joelsson; Magnus Ihse Bursie; build-dev at openjdk.java.net >> Subject: Re: Building OpenJDK9 on MSYS2 >> >> Was this a SEGV while you were running the debugger? >> >> There is an intentional SEGV generated. This is used to determine if we can use some of newer >> CPU features. Try to allow the SEGV to continue to see if you run normally. >> >> Bob. >> >> >>> On Oct 24, 2017, at 11:37 AM, Peter Budai > wrote: >>> >>> It seems that the compile is progressing well, I have 49 executables/tools and 38 compiled shared libraries already in the JDK folder. >>> >>> I have tried to run the product with the simplest ?java -version? command, however I get a SIGSEGV at get_cpu_info_stub() in vm_version_x86.cpp, VM_Version::get_processor_features() >>> >>> get_cpu_info_stub(&_cpuid_info); >>> >>> Thread 5 received signal SIGSEGV, Segmentation fault. >>> 0x000000002d9a072f in ?? () >>> >>> I can debug using gdb, but unfortunately this is pure ASM, and my knowledge on this is close to 0. >>> >>> Any idea help or pointer how could I tackle this? >>> >>> Peter >>> >>> From: David Holmes >>> Sent: Sunday, October 15, 2017 10:37 PM >>> To: Peter Budai; Erik Joelsson; Magnus Ihse Bursie >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> On 16/10/2017 12:41 AM, Peter Budai wrote: >>>> A quick status update: >>>> >>>> * Hotspot successfully compiled without warnings >>>> * I?d like to run the unit tests, but as I see ?make check? does not work, and gtestlauncher expects a command line parameter jdk. Tried to look up some documentation on this, but have not found. So the question is: how can I run unit tests for hotspot? Do I need also JDK compiled for that? Or the bootJDK is good enough? Any help would be appreciated. >>> Hotspot has to be tested as part of a full JDK - you can't load the JVM >>> without having the "J" part :) >>> >>> You should be able to drop your built dll into an existing JDK 9 windows >>> JDK and test it that way. >>> >>> David >>> ----- >>> >>>> * Also I?m making progress on compiling jdk, but there are some very interesting solutions on windows linking which makes a bit more difficult to compile with gcc: LIBS_windows contains sometimes simple library names (which I believe is correct) and other times library names with full path (which I believe is not the best solution). I?m trying to rework those places and use simple library names and passing search path for libraries -L (for gcc toolchain) and /LIBPATH: (for Microsoft toolchain). Also I was surprised by a few manual function name exports? >>>> * jdk code base contains apparently more MSVC specific part, many places casts/lack of casts are generating errors, static attributes were missing etc. a bit tedious work. >>>> >>>> P. >>>> >>>> From: Erik Joelsson >>>> Sent: Wednesday, October 11, 2017 4:16 PM >>>> To: Magnus Ihse Bursie; Peter Budai >>>> Cc: build-dev at openjdk.java.net >>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>> >>>> Hello, >>>> >>>> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: >>>> >>>> For gcc, we let the compiler generate the .d file. For the Microsoft tool chain, we use a clever sed script to extract and create it ourself. >>>> >>>> I think that logic is checking for "Windows", not "Microsoft". That might be your cause of trouble. >>>> >>>> Look in NativeCompilation.gmk. >>>> >>>> That was my initial thought as well, but we do correctly check for microsoft. Also it's not the .d files that are the problem. As Peter just wrote, they look fine. It's the .d.target files which we create using the same technique on all platforms. What we don't account for is the compiler putting Windows mixed paths in the .d files. >>>> >>>> /Magnus >>>> >>>> 11 okt. 2017 kl. 14:43 skrev Peter Budai >: >>>> Hi Erik, >>>> >>>> The .d file looks like this: >>>> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: \ >>>> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp \ >>>> >>>> I have checked .d.targets file, and looks like it has the first line has not been deleted, and the file names below are also wrong: >>>> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj : : >>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp : >>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : >>>> >>>> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by the ?C:/? >>>> -e 's/^[^:]*: *//' >>>> >>>> Yes, that does indeed look like the problem. I suppose the regexp is unnecessarily strict. It should be ok to rewrite it as something like this: >>>> -e 's/^.*: *//' >>>> >>>> Basically just make sure it ends with : and any number of spaces. >>>> >>>> /Erik >>>> >>>> >>>> >>>> Peter >>>> >>>> Sent from Mail for Windows 10 >>>> >>>> From: Erik Joelsson >>>> Sent: Wednesday, October 11, 2017 12:16 PM >>>> To: Peter Budai; Magnus Ihse Bursie; build-dev at openjdk.java.net >>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>> >>>> >>>> Hello Peter, >>>> >>>> On 2017-10-11 00:18, Peter Budai wrote: >>>> Thanks Magnus & Erik >>>> >>>> First thanks for your support and kind words! >>>> >>>> Magnus, I have checked .bash_profile, .bashrc but they seem to be empty (everything is commented out). You can check with a default MSYS2 install, I have not changed these files at all. If you find thee something specific I can give a try here as well. >>>> >>>> Let me give also a quick status update, where am I with building hotspot: >>>> ? I guess its still the beginning, but I have managed to compile jvm.dll with almost 700 object file: with debug info the dll is around 700 MB ? >>>> ? I made only surgical, minimal changes to the source, and so far it looks reasonable. I have encountered 3 scenarios where changes were necessary: >>>> o When in makefiles conditionals were using assuming that if target_os is windows then it is visual studio compiler/linker. Obviously these conditionals had to be reviewed in a few places and if necessary were changes to check the toolchain=Microsoft >>>> These are not surprising and should be pretty straight forward to fix and it seems you know what to do. >>>> >>>> >>>> ? >>>> o I got a few warnings as gcc 7.2 uncovered some code problems in windows specific codes, where before that MSVC I guess did not say a word? >>>> To get around this you can configure with --disable-warnings-as-errors until you get things working properly. This is commonly needed when using compiler versions that we normally don't use. >>>> >>>> >>>> ? >>>> o And I had like 6-7 places where the code was using MSVC specific __try ? __except structures which gcc does not know. Do you have a suggestion how to approach them? I can do ugly #ifdefs (I would avoid that) but I have also seen some solutions to replace them with a code which gcc can compile (http://www.programmingunlimited.net/siteexec/content.cgi?page=mingw-seh ) ? but before doing that though I would ask first you on the purpose of those >>>> This kind of question is probably best to bring to the hotspot mailing list. >>>> ? What bothers me is that I was not able to do incremental builds: when an error occurs, and build stops, then after making change in the CPP source the build cannot continue, I always got an error message: >>>> >>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/hotspot/variant-server/tools/adlc/objs/adlparse.d.targets:1: *** missing target pattern. Stop. >>>> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 >>>> >>>> If I do a ?make clean? and restart the build then it nicely compiles. >>>> >>>> Question 1: Is there a way to resume such builds without ?make clean?? >>>> Well, incremental builds is supposed to work well. We have several extra tricks in there to handle cases where normal make builds would fail. The *.d.targets files is one such trick and it seems to backfire for you. The contents of that file should be something like: >>>> >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : >>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : >>>> >>>> Basically an empty rule for each dependency for the corresponding object file. Declaring these rules makes it possible to delete source files without having to build clean. It seems your file is not generated correctly so please have a look inside it. The file is in make/common/NativeCompilation.gmk, look for DEPENDENCY_TARGET_SED_PATTERN. >>>> >>>> >>>> >>>> Question 2: What would be the best way to submit/share the patches for your thorough review? >>>> >>>> Well, first of all, have you signed the OCA? >>>> >>>> As for publishing patches and reviews, there is a bit of chicken and egg problem. Once you become an "author" in any of the OpenJDK projects, you get a user name and should be able to publish reviews on cr.openjdk.java.net>>. Before that, if the patch is small, it can be posted inline in an email to the list. If it's large, you will need a current OpenJDK user to host it for you. At least that's how I understand it. Hopefully someone who knows the process better can chime in here. >>>> >>>> I should also let you know that getting this into JDK 9 is most likely not going to happen. AFAIK we are only doing security updates for 9. It would have to go into the currently active release. I should also warn you that new ports generally need a certain amount of backing to be accepted. It may be that this would have to live in a porting side project. Hopefully someone who knows this better can chime in here as well. >>>> >>>> /Erik >>>> >>>> >>>> P. >>>> >>>> Sent from Mail for Windows 10 >>>> >>>> From: Magnus Ihse Bursie >>>> Sent: Tuesday, October 10, 2017 10:04 AM >>>> To: Peter Budai; Erik Joelsson; build-dev at openjdk.java.net >>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>> >>>> On 2017-10-07 10:14, Peter Budai wrote: >>>> The configure of OpenJDK overwrites the SHELL. Actually it is using bash, but for the arguments it was using ?-e -o pipefail?. I have figured that for MSYS2 bash what is needed as bash arguments is ?-e -l -c -o pipefail? >>>> >>>> That looks like solving this problem, and now the real issues are surfacing. >>>> >>>> FWIW, "-l" makes bash behave like a login shell. Most likely you are changing bash's behavior in one of your login scripts, and that change is what's really needed. >>>> >>>> /Magnus >>>> >>>> >>>> >>>> >>>> >>>> Peter >>>> >>>> From: Peter Budai >>>> Sent: Friday, October 6, 2017 6:43 PM >>>> To: Magnus Ihse Bursie; Erik Joelsson; build-dev at openjdk.java.net >>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>> >>>> Magnus, >>>> >>>> I have followed your suggestion and removed the fixpath prefixes from gcc related compile tools, and left only the fixpath prefix _only_ for the Boot JDK related tools in place. >>>> >>>> 1) As I follow the process, all java and javac related compile steps are running properly >>>> 2) When the process reaches gcc related steps I got the error message at the same place as before (no fixpath). If I execute that command from the bash prompt, it creates the output: >>>> >>>> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template && /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java >>>> >>>> As I have mentioned the parameters are replaced by the bash automatically >>>> 3) Then build continues, then little later stops at a super simple command: >>>> >>>> mv /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/java/nio/ByteBuffer.java >>>> Needless to say, the ByteBuffer.java.tmp file DOES exist. And running the above command from the bash works, and build continues. >>>> 4) A few similar cases (stops) with DirectByteBuffer and DirectByteBufferR >>>> >>>> >>>> Currently I try to explore how that might relate to the MSYS2 bash and make, somehow it behaves differently >>>> >>>> If you have any other suggestion, let me know. >>>> >>>> Best regards, >>>> >>>> Peter >>>> >>>> From: Peter Budai >>>> Sent: Thursday, October 5, 2017 3:52 PM >>>> To: Magnus Ihse Bursie; Erik Joelsson; build-dev at openjdk.java.net >>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>> >>>> Hi Magnus, >>>> >>>> So first of all, here is the current patch, which I was not able to attach: https://pastebin.com/pwT4Ynxc >>>> >>>>>> That's surprising, since gcc is prefixed with fixpath, which it should not. >>>> Actually you DO need fixpath IMHO. >>>> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), which is a fully functional Windows executable, which expects Windows formatted path arguments. >>>> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see that patch), none of the command line arguments are converted from the unix path to Windows, but fixpath does that conversion. There is a wiki describing more details on this: >>>> https://github.com/msys2/msys2/wiki/Porting#user-content-filesystem-namespaces >>>> >>>> >>>> >>>>>> I have a hard time believing this is a race condition. On the other hand, this stuff is weird, we're misusing the C preprocessor to process defines in java code, so I'm not surprised it breaks down. >>>>>> I don't know why it succeeded when run on the command line, though. >>>> When I execute that command from the bash command line there is no EXPORT MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic conversion of the arguments. Maybe it has something to do how fixpath does CreateProcess? >>>> >>>> Does that help? >>>> >>>> Best regards, >>>> >>>> Peter >>>> >>>> Sent from Mail for Windows 10 >>>> >>>> From: Magnus Ihse Bursie >>>> Sent: Thursday, October 5, 2017 12:13 PM >>>> To: Peter Budai; Erik Joelsson; build-dev at openjdk.java.net >>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>> >>>> >>>> On 2017-10-05 11:59, Peter Budai wrote: >>>> Hi Magnus and Erik, >>>> >>>> I really appreciate your quick feedback. I assumed that it won?t be easy, but I just don?t feel I should give up now - maybe later when I see the real scale of work. So bear with me for a time being. >>>> >>>> Attached is a patch which already includes Magnus? changes, plus a few which I have added: >>>> ? basically enabling gcc for windows, >>>> ? and modifying a logic for compiling fixpath (before that it was using hard-coded MS VSC compile flags) >>>> >>>> Actually, you must make sure fixpath is *not* used for the toolchain, since gcc uses unix style paths. >>>> (However, other tools such as java will still need it.) >>>> >>>> >>>> >>>> >>>> >>>> >>>> So here is what I have as the result of configure: >>>> ==================================================== >>>> The existing configuration has been successfully updated in >>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release >>>> using configure arguments '--disable-freetype-bundling --disable-javac-server'. >>>> >>>> Configuration summary: >>>> * Debug level: release >>>> * HS debug level: product >>>> * JDK variant: normal >>>> * JVM variants: server >>>> * OpenJDK target: OS: windows, CPU architecture: x86, address length: 64 >>>> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) >>>> >>>> Tools summary: >>>> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) >>>> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) >>>> * Toolchain: gcc (GNU Compiler Collection) >>>> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) >>>> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) >>>> >>>> Build performance summary: >>>> * Cores to use: 4 >>>> * Memory limit: 16216 MB >>>> >>>> Its clear says that the toolchain is gcc 7.2 (BTW there is no Visual Studio on this machine) >>>> >>>> Now for the details of the config log, you can see here: https://pastebin.com/MN2ZYcHH >>>> >>>> And about the build process and the error I get: >>>> >>>> $ make JOBS=1 >>>> Building target 'default (exploded-image)' in configuration 'windows-x86_64-normal-server-release' >>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >>>> Compiling 17 properties into resource bundles for jdk.compiler >>>> Parsing 1 properties into enum-like class for jdk.compiler >>>> Compiling 19 properties into resource bundles for jdk.javadoc >>>> Compiling 12 properties into resource bundles for jdk.jdeps >>>> Compiling 7 properties into resource bundles for jdk.jshell >>>> Compiling 117 files for BUILD_INTERIM_java.compiler >>>> Compiling 396 files for BUILD_INTERIM_jdk.compiler >>>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps >>>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc >>>> Note: Some input files use or override a deprecated API. >>>> Note: Recompile with -Xlint:deprecation for details. >>>> Compiling 159 files for BUILD_TOOLS_JDK >>>> Note: Some input files use unchecked or unsafe operations. >>>> Note: Recompile with -Xlint:unchecked for details. >>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>>> make[3]: *** Deleting file '/C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java' >>>> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 >>>> >>>> ERROR: Build failed for target 'default (exploded-image)' in configuration 'windows-x86_64-normal-server-release' (exit code 2) >>>> >>>> No indication of failed target found. >>>> Hint: Try searching the build log for '] Error'. >>>> Hint: See common/doc/building.html#troubleshooting for assistance. >>>> >>>> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 >>>> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 >>>> >>>> If I run here >>>> make JOBS=1 LOG=debug >>>> The failing line seems to be this: >>>> >>>> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template && /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/configure-support/bin/fixpath.exe -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java >>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-server-release/support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>>> >>>> Now the interesting is: if I copy this line above to the bash prompt, it runs without problem, and the file support/gensrc/java.base/sun/nio/ch/SocketOptionRegistry.java >>>> That's surprising, since gcc is prefixed with fixpath, which it should not. >>>> >>>> I have a hard time believing this is a race condition. On the other hand, this stuff is weird, we're misusing the C preprocessor to process defines in java code, so I'm not suprised it breaks down. I don't know why it succeeded when run on the command line, though. My suggestion is to just do some quick and dirty hack around this: take the file you manage to generate and just copy it in during the build instead. If you can get round this, you might start seeing some *real* problems. :-) >>>> >>>> Also, my suggestion is that you try running "make hotspot" to cut to the chase. Compiling hotspot will likely be the hardest thing. Or even "make -k hotspot" to get an assessment of the amount of work ahead of you. >>>> >>>> /Magnus >>>> Is produced. >>>> >>>> Then I can again issue >>>> make JOBS=1 LOG=debug >>>> >>>> And the compile process is being continued, until a similar error pops up with a different generated file. I have an assumption that this happens because make is still running parallel jobs, despite JOBS=1 but I?m not sure. >>>> >>>> How could I best tackle this? >>>> >>>> Thank you and best regards, >>>> >>>> Peter >>>> >>>> Sent from Mail for Windows 10 >>>> >>>> From: Magnus Ihse Bursie >>>> Sent: Thursday, October 5, 2017 11:33 AM >>>> To: Erik Joelsson; Peter Budai; build-dev at openjdk.java.net >>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>> >>>> On 2017-10-05 10:10, Erik Joelsson wrote: >>>>> Hello Peter, >>>>> >>>>> >>>>> On 2017-10-04 21:15, Peter Budai wrote: >>>>>> Hi Magnus, >>>>>> >>>>>> Thanks for the quick reply I?ll check these patches with msys2. >>>>>> >>>>>> Let me specify with more details what I?d like to achieve: I?d like >>>>>> to build OpenJDK9 with MSYS2 MINGW64 environment using gcc toolchain. >>>>>> (I?m not sure how familiar are you with MSYS2, but there are 3 >>>>>> different environments: MSYS2, MINGW32 and MINGW64). In theory >>>>>> MINGW64 with gcc is the closes you can get on Windows platform as a >>>>>> gcc unix like build environment, which produces still a native 64-bit >>>>>> executable on Windows. >>>>>> >>>>>> I?m not very familiar with OpenJDK yet, so therefore I?d like to hear >>>>>> your opinion: how realistic is that? >>>>> Sorry to disappoint, but I would say that requires major work. There >>>>> is a strong historic assumption that windows builds are done using >>>>> Visual Studio. We have abstracted away some of it in configure (see >>>>> TOOLCHAIN_TYPE), but it's very far from enough to change compiler >>>>> environment for a Windows build. The native sources are also bound to >>>>> make a lot of such assumptions. I would expect the changes needed to >>>>> be in the thousands of lines of code. >>>> I agree that it requires hard work (even if "thousands" might be an >>>> overestimation I think, but "hundreds" is not enough, so it's the right >>>> magnitude). On the other hand, it would be really good if we did sort >>>> things out, so that we had proper conditions based on OS vs >>>> compiler/toolchain. >>>> >>>> If you really want to start, the first thing is to patch toolchain.m4 to >>>> VALID_TOOLCHAINS_windows="microsoft gcc" >>>> and then call configure using "bash configure --with-toolchain-type=gcc". >>>> >>>> As Erik, I doubt you will come very far before things starts tumbling down. >>>> >>>>> When we say supporting the build in msys2 instead of cygwin, we just >>>>> mean using msys2 as the unix emulating layer for our tools like >>>>> make/bash/grep/sed etc. >>>>> >>>>> One think I have done successfully is running the build in WSL >>>>> (Windows Subsystem for Linux), but that isn't all that helpful as WSL >>>>> for practical purposes is more or less like running Linux in a VM, so >>>>> the build sees a Linux system and builds a Linux binary. >>>>>> As a side note: with MINGW64 I have managed to run configure phase >>>>>> successfully for OpenJDK. The compile process has also started and >>>>>> went for a while, but interestingly I run into some kind of race >>>>>> conditions as make stopped with an error. Using LOG=debug I have fond >>>>>> the failing line and then copying the failed command and pasting it >>>>>> to the bash prompt it successfully generated the output target, and >>>>>> then the build process run further when a similar situation happened. >>>>>> Also pasting the failed command run in the bash without any problem, >>>>>> and build continued? until the next. >>>>> Without seeing the errors I can't say much. I very much doubt that you >>>>> are running with gcc as the compiler though. Configure isn't easily >>>>> fooled into using a different compiler to what it prefers, and I would >>>>> expect things to crash and burn pretty early if you actually did. >>>>> >>>>> /Erik >>>>>> I have tried to run make JOBS=1, but did not help, strangely I have >>>>>> still seen in the log make[3] and make[4] logs which suggested that >>>>>> there are more than one make jobs were running. Also tried .configure >>>>>> --with-output-sync=recurse without success (same symptoms) >>>>>> >>>>>> Let me know your thoughts. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Peter >>>>>> >>>>>> Sent from Mail for >>>>>> Windows 10 >>>>>> >>>>>> From: Magnus Ihse Bursie >>>>>> Sent: Wednesday, October 4, 2017 1:04 AM >>>>>> To: Peter Budai; >>>>>> build-dev at openjdk.java.net >>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>> >>>>>> Actually, it wasn't so much remaining trouble. :-) I fired up msys2 and >>>>>> checked out where I left off. It turned out that the remaining snag was >>>>>> that msys2 tries to convert command lines automatically, from "unix" >>>>>> style paths to "windows" style paths. Unfortunately, it does not do this >>>>>> very well and it breaks all sorts of things. We already have a FIXPATH >>>>>> solution in place which deals with this, so basically all I had to do >>>>>> was disable this (by setting MSYS2_ARG_CONV_EXCL to "*"). However, this >>>>>> broke our cygpath replacement hack (!) so I had to disable it there. >>>>>> Sigh. Anyway, with those fixes it ran and worked well. (I also >>>>>> discovered and fixed a bug related to how we set up the FIXPATH variable >>>>>> on msys, but it only triggers in certain circumstances). >>>>>> >>>>>> With this patch I now jdk9 seems to build fine on msys2. It should apply >>>>>> cleanly on jdk9/jdk9. Since it turned out to be so trivial, I'll try to >>>>>> get it in in jdk10. >>>>>> >>>>>> Here's the patch if you want to apply it yourself: >>>>>> >>>>>> diff -r a08cbfc0e4ec common/autoconf/basics_windows.m4 >>>>>> --- a/common/autoconf/basics_windows.m4 Thu Aug 03 18:56:56 2017 >>>>>> +0000 >>>>>> +++ b/common/autoconf/basics_windows.m4 Wed Oct 04 00:53:58 2017 >>>>>> +0200 >>>>>> @@ -42,7 +42,7 @@ >>>>>> windows_path=`$CYGPATH -m "$unix_path"` >>>>>> $1="$windows_path" >>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then >>>>>> - windows_path=`cmd //c echo $unix_path` >>>>>> + windows_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $unix_path` >>>>>> $1="$windows_path" >>>>>> fi >>>>>> ]) >>>>>> @@ -136,6 +136,16 @@ >>>>>> fi >>>>>> ]) >>>>>> >>>>>> +AC_DEFUN([BASIC_MSYS_UPDATE_FIXPATH], >>>>>> +[ >>>>>> + # Take all collected prefixes and turn them into a >>>>>> -m/c/foo@/c/bar at ... command line >>>>>> + # @ was chosen as separator to minimize risk of other tools messing >>>>>> around with it >>>>>> + all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >>>>>> + | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>>> + fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >>>>>> + FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>>> +]) >>>>>> + >>>>>> AC_DEFUN([BASIC_FIXUP_PATH_MSYS], >>>>>> [ >>>>>> path="[$]$1" >>>>>> @@ -143,7 +153,7 @@ >>>>>> new_path="$path" >>>>>> if test "x$has_colon" = x; then >>>>>> # Not in mixed or Windows style, start by that. >>>>>> - new_path=`cmd //c echo $path` >>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $path` >>>>>> fi >>>>>> >>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>>> @@ -155,6 +165,8 @@ >>>>>> >>>>>> # Save the first 10 bytes of this path to the storage, so fixpath >>>>>> can work. >>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>>> "${new_path:0:10}") >>>>>> + # We might need to re-evaluate FIXPATH. >>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>> ]) >>>>>> >>>>>> AC_DEFUN([BASIC_FIXUP_EXECUTABLE_CYGWIN], >>>>>> @@ -293,7 +305,7 @@ >>>>>> # Do not save /bin paths to all_fixpath_prefixes! >>>>>> else >>>>>> # Not in mixed or Windows style, start by that. >>>>>> - new_path=`cmd //c echo $new_path` >>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $new_path` >>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>>> # Output is in $new_path >>>>>> BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(new_path) >>>>>> @@ -302,6 +314,8 @@ >>>>>> >>>>>> # Save the first 10 bytes of this path to the storage, so fixpath >>>>>> can work. >>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>>> "${new_path:0:10}") >>>>>> + # We might need to re-evaluate FIXPATH. >>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>> fi >>>>>> ]) >>>>>> >>>>>> @@ -347,6 +361,10 @@ >>>>>> WINDOWS_ENV_VENDOR='msys' >>>>>> WINDOWS_ENV_VERSION="$MSYS_VERSION" >>>>>> >>>>>> + # Prohibit msys2 path conversion from trying to be "intelligent", >>>>>> and rely >>>>>> + # on fixpath instead. >>>>>> + export MSYS2_ARG_CONV_EXCL="*" >>>>>> + >>>>>> AC_MSG_CHECKING([msys root directory as unix-style path]) >>>>>> # The cmd output ends with Windows line endings (CR/LF), the grep >>>>>> command will strip that away >>>>>> MSYS_ROOT_PATH=`cd / ; cmd /c cd | $GREP ".*"` >>>>>> @@ -391,10 +409,7 @@ >>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.msys; then >>>>>> # Take all collected prefixes and turn them into a >>>>>> -m/c/foo@/c/bar at ... command line >>>>>> # @ was chosen as separator to minimize risk of other tools >>>>>> messing around with it >>>>>> - all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >>>>>> - | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>>> - fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >>>>>> - FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>> fi >>>>>> FIXPATH_SRC_W="$FIXPATH_SRC" >>>>>> FIXPATH_BIN_W="$FIXPATH_BIN" >>>>>> diff -r a08cbfc0e4ec common/autoconf/build-aux/config.sub >>>>>> --- a/common/autoconf/build-aux/config.sub Thu Aug 03 18:56:56 >>>>>> 2017 +0000 >>>>>> +++ b/common/autoconf/build-aux/config.sub Wed Oct 04 00:53:58 >>>>>> 2017 +0200 >>>>>> @@ -30,7 +30,7 @@ >>>>>> DIR=`dirname $0` >>>>>> >>>>>> # First, filter out everything that doesn't begin with "aarch64-" >>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>> . $DIR/autoconf-config.sub "$@" >>>>>> # autoconf-config.sub exits, so we never reach here, but just in >>>>>> # case we do: >>>>>> @@ -38,13 +38,17 @@ >>>>>> fi >>>>>> >>>>>> while test $# -gt 0 ; do >>>>>> - case $1 in >>>>>> + case $1 in >>>>>> -- ) # Stop option processing >>>>>> shift; break ;; >>>>>> aarch64-* ) >>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>> sub_args="$sub_args $config" >>>>>> shift; ;; >>>>>> + *-msys ) >>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>> + sub_args="$sub_args $config" >>>>>> + shift; ;; >>>>>> - ) # Use stdin as input. >>>>>> sub_args="$sub_args $1" >>>>>> shift; break ;; >>>>>> diff -r a08cbfc0e4ec common/autoconf/spec.gmk.in >>>>>> --- a/common/autoconf/spec.gmk.in Thu Aug 03 18:56:56 2017 +0000 >>>>>> +++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 +0200 >>>>>> @@ -120,6 +120,13 @@ >>>>>> # On Windows, the Visual Studio toolchain needs the PATH to be >>>>>> adjusted >>>>>> # to include Visual Studio tools (this needs to be in cygwin/msys >>>>>> style). >>>>>> export PATH:=@VS_PATH@ >>>>>> + >>>>>> +endif >>>>>> + >>>>>> +ifeq ($(OPENJDK_TARGET_OS_ENV), windows.msys) >>>>>> + # On msys2, prohibit msys path conversion from trying to be >>>>>> + # "intelligent", and rely on fixpath instead. >>>>>> + export MSYS2_ARG_CONV_EXCL:=* >>>>>> endif >>>>>> >>>>>> SYSROOT_CFLAGS := @SYSROOT_CFLAGS@ >>>>>> >>>>>> /Magnus >>>>>> >>>>>> On 2017-10-03 22:34, Magnus Ihse Bursie wrote: >>>>>>> I gave msys2 a shot some time ago, but it ended up too much trouble. >>>>>>> I'll share some of my notes from that attempt, for what it's worth. >>>>>>> >>>>>>> To install package X/Y, run "pacman -S X/Y". Missing tools and >>>>>>> packages where to find them: >>>>>>> cmp: msys/diffutils >>>>>>> tar: msys/tar >>>>>>> make: msys/make >>>>>>> unzip: msys/unzip >>>>>>> zip: msys/zip >>>>>>> >>>>>>> config.sub reports msys as "x86_64-pc-mingw32" but msys2 as >>>>>>> "x86_64-pc-msys". This patch adds postprocessing in "our" config.sub >>>>>>> to report msys2 similar to msys. (Opinions, including my own :-) may >>>>>>> vary if this really is the best way..) >>>>>>> >>>>>>> diff -r b88023f46daa common/autoconf/build-aux/config.sub >>>>>>> --- a/common/autoconf/build-aux/config.sub Fri Jan 27 10:15:41 >>>>>>> 2017 +0100 >>>>>>> +++ b/common/autoconf/build-aux/config.sub Fri Feb 03 05:00:25 >>>>>>> 2017 -0700 >>>>>>> @@ -30,7 +30,7 @@ >>>>>>> DIR=`dirname $0` >>>>>>> >>>>>>> # First, filter out everything that doesn't begin with "aarch64-" >>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>>> . $DIR/autoconf-config.sub "$@" >>>>>>> # autoconf-config.sub exits, so we never reach here, but just in >>>>>>> # case we do: >>>>>>> @@ -45,6 +45,10 @@ >>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>>> sub_args="$sub_args $config" >>>>>>> shift; ;; >>>>>>> + *-msys ) >>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>>> + sub_args="$sub_args $config" >>>>>>> + shift; ;; >>>>>>> - ) # Use stdin as input. >>>>>>> sub_args="$sub_args $1" >>>>>>> shift; break ;; >>>>>>> >>>>>>> If I remember correctly, this got me past the configure stage at the >>>>>>> time. >>>>>>> >>>>>>> I don't think it's very hard to get it to work on msys2, I just ran >>>>>>> into one snag too many and didn't think msys2 would be used by anyone. >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> On 2017-10-03 17:20, Peter Budai wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> According to >>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/common/doc/building.html >>>>>>>> >>>>>>>> ?msys2 and the new Windows Subsystem for Linux (WSL) would likely be >>>>>>>> possible to support in a future version but that would require a >>>>>>>> community effort to implement? >>>>>>>> >>>>>>>> I?d like to help making the OpenJDK 9 build working on msys2. What is >>>>>>>> the best way to move forward? Is there a similar effort in progress? >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >> >> From denisl at bigsql.com Wed Nov 22 23:40:48 2017 From: denisl at bigsql.com (Lussier, Denis) Date: Wed, 22 Nov 2017 18:40:48 -0500 Subject: Building OpenJDK9 on MSYS2 Message-ID: This is good stuff. Back in 2010 I got OpenJDK compiled and running on the Microsoft Toolchain. I never ran the jtreg tests, but, the binaries worked for running basic Tomcat but definitely not for trying to run Eclipse. These days I am a pretty big fan of MSYS2. In my personal experiences with building a PostgreSQL Windoze distribution, the MSYS2 binaries run a little faster than using the old MS Toolchain. https://www.openscg.com/2016/02/building-postgresql-on-windows-for-performance/ --Luss On Wed, Nov 22, 2017 at 4:28 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Peter, > > With over 120 :tier1 test failures, it would be worth understanding the > test failures as part of moving forward. There should normally be no :tier1 > test failures. > > -- Jon > > > > > On 11/22/2017 01:10 PM, Peter Budai wrote: > >> Let me give an update on the current status: >> >> * I have managed to build both the 64 and the 32-bit version. >> * The 64-bit version seems reasonable: >> >> >> >> ============================== >> >> Test summary - w64-bit >> >> ============================== >> >> TEST TOTAL PASS FAIL >> ERROR >> >> jtreg:jdk/test:tier1 1645 1610 34 1 >>>> << >>>> jtreg:langtools/test:tier1 3907 3819 79 >>>> 9 << >>>> >>> jtreg:nashorn/test:tier1 0 0 0 >> 0 >> >> jtreg:jaxp/test:tier1 0 0 0 >> 0 >> >> ============================== >> >> * However the 32-bit version of hotspot contains a bunch of inline >> assembly pieces which uses an MSC specific syntax, and my ASM knowledge is >> really limited. I have managed to get a many inline assembly codes from the >> Linux version, but there are few pieces where I was not able to find a good >> solution yet, so although the 32-bit version compiles, unfortunately it is >> not working >> * I have installed VS Express 2013 and made sure that the >> ?traditional? Microsoft toolchain is still working with the changes >> * My OCA has been processed >> >> I have a changeset which cleanly applies to JDK9 v181, but I recall you >> have mentioned earlier that you would like to consider this to JDK10 >> >> So what is the best way to open a PR for review? This page: >> http://openjdk.java.net/contribute/ says I should send the changeset as >> attachment, but earlier somebody mentioned here that attachments are >> removed from the developer mailing lists. >> >> Best regards, >> >> Peter >> >> From: Erik Joelsson >> Sent: Thursday, November 2, 2017 1:07 AM >> To: Peter Budai; Magnus Ihse >> Bursie >> Cc: build-dev at openjdk.java.net >> Subject: Re: Building OpenJDK9 on MSYS2 >> >> I would say a few hours is way too long for tier1, but it of course >> depends on the hardware used. We typically run it on windows in less >> than 30 minutes with concurrency set to 6. Not sure what concurrency you >> used by default. >> >> /Erik >> >> >> On 2017-10-27 04:33, Peter Budai wrote: >> >>> Hi Magnus, after a little poking I managed to install and use jtreg, >>> thanks for the guidance. >>> >>> Make run-test-tier1 resulted a pretty OK result for a first try, at >>> least for run-test-jdk: >>> Test results: passed: 1,610; failed: 34; error: 1 >>> It took a few hors to run ? is that normal? >>> >>> I?ll review the patchset, and then share that with you. >>> >>> P. >>> >>> From: Magnus Ihse Bursie >>> Sent: Thursday, October 26, 2017 11:00 AM >>> To: Peter Budai >>> Cc: build-dev at openjdk.java.net >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> >>> On 2017-10-26 00:01, Peter Budai wrote: >>> OK, I have found what was missing, it was actually my fault with a >>> missing exception handler. >>> >>> So finally OpenJDK build has finished on Windows using gcc toolchain >>> running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it looks >>> promising: >>> ./build/windows-x86_64-normal-server-fastdebug/hotspot/varia >>> nt-server/libjvm/gtest/gtestLauncher.exe --jdk=/home/peterbud/jdk9/buil >>> d/windows-x86_64-normal-server-fastdebug/jdk >>> ?. >>> ?. >>> ?. >>> >>> [----------] Global test environment tear-down >>> [==========] 346 tests from 54 test cases ran. (3859 ms total) >>> [ PASSED ] 346 tests. >>> I'm impressed! :-) >>> >>> Would you care to share your current patchset, just to still my >>> curiosity? :-) >>> >>> >>> >>> What is the best way to test the current build more thoroughly? >>> "make run-test-tier1". As Erik says, you'll need jtreg, and call >>> "configure --with-jtreg=...". You can get it from the Adopt OpenJDK group >>> here: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccess >>> fulBuild/artifact/ >>> >>> /Magnus >>> >>> >>> P. >>> >>> From: Bob Vandette >>> Sent: Tuesday, October 24, 2017 8:10 PM >>> To: Peter Budai >>> Cc: David Holmes; Erik Joelsson>> erik.joelsson at oracle.com>; Magnus Ihse Bursie>> ie at oracle.com>; build-dev at openjdk.java.net>> build-dev at openjdk.java.net> >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> Can you provide some details about your toolchain, processor and os plus >>> a dump of the native instructions around the SEGV. This might give us >>> enough info to be able to figure out what?s going on. >>> >>> Bob. >>> >>> On Oct 24, 2017, at 1:21 PM, Peter Budai >> peterbudai at hotmail.com>> wrote: >>> >>> I get that error running in the debugger but also running >>> without/outside of the debugger as well. >>> >>> I saw the comment in the code about generating SEGV in function >>> generate_get_cpu_info(), however the debugger can execute that, and the >>> SEGV I experience is coming later in the VM_Version::get_processor_features() >>> function >>> >>> Peter >>> >>> From: Bob Vandette >>> Sent: Tuesday, October 24, 2017 6:28 PM >>> To: Peter Budai >>> Cc: David Holmes; Erik Joelsson>> erik.joelsson at oracle.com>; Magnus Ihse Bursie>> ie at oracle.com>; build-dev at openjdk.java.net>> build-dev at openjdk.java.net> >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> Was this a SEGV while you were running the debugger? >>> >>> There is an intentional SEGV generated. This is used to determine if we >>> can use some of newer >>> CPU features. Try to allow the SEGV to continue to see if you run >>> normally. >>> >>> Bob. >>> >>> >>> On Oct 24, 2017, at 11:37 AM, Peter Budai >>> :peterbudai at hotmail.com>> wrote: >>>> >>>> It seems that the compile is progressing well, I have 49 >>>> executables/tools and 38 compiled shared libraries already in the JDK >>>> folder. >>>> >>>> I have tried to run the product with the simplest ?java -version? >>>> command, however I get a SIGSEGV at get_cpu_info_stub() in >>>> vm_version_x86.cpp, VM_Version::get_processor_features() >>>> >>>> get_cpu_info_stub(&_cpuid_info); >>>> >>>> Thread 5 received signal SIGSEGV, Segmentation fault. >>>> 0x000000002d9a072f in ?? () >>>> >>>> I can debug using gdb, but unfortunately this is pure ASM, and my >>>> knowledge on this is close to 0. >>>> >>>> Any idea help or pointer how could I tackle this? >>>> >>>> Peter >>>> >>>> From: David Holmes >>>> Sent: Sunday, October 15, 2017 10:37 PM >>>> To: Peter Budai; Erik Joelsson>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie>>> ie at oracle.com> >>>> Cc: build-dev at openjdk.java.net>>> > >>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>> >>>> On 16/10/2017 12:41 AM, Peter Budai wrote: >>>> >>>>> A quick status update: >>>>> >>>>> * Hotspot successfully compiled without warnings >>>>> * I?d like to run the unit tests, but as I see ?make check? does >>>>> not work, and gtestlauncher expects a command line parameter jdk. Tried to >>>>> look up some documentation on this, but have not found. So the question is: >>>>> how can I run unit tests for hotspot? Do I need also JDK compiled for that? >>>>> Or the bootJDK is good enough? Any help would be appreciated. >>>>> >>>> Hotspot has to be tested as part of a full JDK - you can't load the JVM >>>> without having the "J" part :) >>>> >>>> You should be able to drop your built dll into an existing JDK 9 windows >>>> JDK and test it that way. >>>> >>>> David >>>> ----- >>>> >>>> * Also I?m making progress on compiling jdk, but there are some >>>>> very interesting solutions on windows linking which makes a bit more >>>>> difficult to compile with gcc: LIBS_windows contains sometimes simple >>>>> library names (which I believe is correct) and other times library names >>>>> with full path (which I believe is not the best solution). I?m trying to >>>>> rework those places and use simple library names and passing search path >>>>> for libraries -L (for gcc toolchain) and /LIBPATH: (for >>>>> Microsoft toolchain). Also I was surprised by a few manual function name >>>>> exports? >>>>> * jdk code base contains apparently more MSVC specific part, >>>>> many places casts/lack of casts are generating errors, static attributes >>>>> were missing etc. a bit tedious work. >>>>> >>>>> P. >>>>> >>>>> From: Erik Joelsson >>>>> Sent: Wednesday, October 11, 2017 4:16 PM >>>>> To: Magnus Ihse Bursie; Peter >>>>> Budai >>>>> Cc: build-dev at openjdk.java.net>>>> > >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> Hello, >>>>> >>>>> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: >>>>> >>>>> For gcc, we let the compiler generate the .d file. For the Microsoft >>>>> tool chain, we use a clever sed script to extract and create it ourself. >>>>> >>>>> I think that logic is checking for "Windows", not "Microsoft". That >>>>> might be your cause of trouble. >>>>> >>>>> Look in NativeCompilation.gmk. >>>>> >>>>> That was my initial thought as well, but we do correctly check for >>>>> microsoft. Also it's not the .d files that are the problem. As Peter just >>>>> wrote, they look fine. It's the .d.target files which we create using the >>>>> same technique on all platforms. What we don't account for is the compiler >>>>> putting Windows mixed paths in the .d files. >>>>> >>>>> /Magnus >>>>> >>>>> 11 okt. 2017 kl. 14:43 skrev Peter Budai >>>> >: >>>>> Hi Erik, >>>>> >>>>> The .d file looks like this: >>>>> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: \ >>>>> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp \ >>>>> >>>>> I have checked .d.targets file, and looks like it has the first line >>>>> has not been deleted, and the file names below are also wrong: >>>>> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-serve >>>>> r-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj : : >>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp : >>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : >>>>> >>>>> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by >>>>> the ?C:/? >>>>> -e 's/^[^:]*: *//' >>>>> >>>>> Yes, that does indeed look like the problem. I suppose the regexp is >>>>> unnecessarily strict. It should be ok to rewrite it as something like this: >>>>> -e 's/^.*: *//' >>>>> >>>>> Basically just make sure it ends with : and any number of spaces. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> >>>>> Peter >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Erik Joelsson >>>>> Sent: Wednesday, October 11, 2017 12:16 PM >>>>> To: Peter Budai; Magnus Ihse >>>>> Bursie; >>>>> build-dev at openjdk.java.net>>>> build-dev at openjdk.java.net> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> >>>>> Hello Peter, >>>>> >>>>> On 2017-10-11 00:18, Peter Budai wrote: >>>>> Thanks Magnus & Erik >>>>> >>>>> First thanks for your support and kind words! >>>>> >>>>> Magnus, I have checked .bash_profile, .bashrc but they seem to be >>>>> empty (everything is commented out). You can check with a default MSYS2 >>>>> install, I have not changed these files at all. If you find thee something >>>>> specific I can give a try here as well. >>>>> >>>>> Let me give also a quick status update, where am I with building >>>>> hotspot: >>>>> ? I guess its still the beginning, but I have managed to compile >>>>> jvm.dll with almost 700 object file: with debug info the dll is around 700 >>>>> MB ? >>>>> ? I made only surgical, minimal changes to the source, and so >>>>> far it looks reasonable. I have encountered 3 scenarios where changes were >>>>> necessary: >>>>> o When in makefiles conditionals were using assuming that if >>>>> target_os is windows then it is visual studio compiler/linker. Obviously >>>>> these conditionals had to be reviewed in a few places and if necessary were >>>>> changes to check the toolchain=Microsoft >>>>> These are not surprising and should be pretty straight forward to fix >>>>> and it seems you know what to do. >>>>> >>>>> >>>>> ? >>>>> o I got a few warnings as gcc 7.2 uncovered some code problems in >>>>> windows specific codes, where before that MSVC I guess did not say a word? >>>>> To get around this you can configure with --disable-warnings-as-errors >>>>> until you get things working properly. This is commonly needed when using >>>>> compiler versions that we normally don't use. >>>>> >>>>> >>>>> ? >>>>> o And I had like 6-7 places where the code was using MSVC specific >>>>> __try ? __except structures which gcc does not know. Do you have a >>>>> suggestion how to approach them? I can do ugly #ifdefs (I would avoid that) >>>>> but I have also seen some solutions to replace them with a code which gcc >>>>> can compile (http://www.programmingunlimited.net/siteexec/content.cgi? >>>>> page=mingw-seh ) ? but before doing that though I would ask first >>>>> you on the purpose of those >>>>> This kind of question is probably best to bring to the hotspot mailing >>>>> list. >>>>> ? What bothers me is that I was not able to do incremental >>>>> builds: when an error occurs, and build stops, then after making change in >>>>> the CPP source the build cannot continue, I always got an error message: >>>>> >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse.d.targets:1: >>>>> *** missing target pattern. Stop. >>>>> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 >>>>> >>>>> If I do a ?make clean? and restart the build then it nicely compiles. >>>>> >>>>> Question 1: Is there a way to resume such builds without ?make clean?? >>>>> Well, incremental builds is supposed to work well. We have several >>>>> extra tricks in there to handle cases where normal make builds would fail. >>>>> The *.d.targets files is one such trick and it seems to backfire for you. >>>>> The contents of that file should be something like: >>>>> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : >>>>> >>>>> Basically an empty rule for each dependency for the corresponding >>>>> object file. Declaring these rules makes it possible to delete source files >>>>> without having to build clean. It seems your file is not generated >>>>> correctly so please have a look inside it. The file is in >>>>> make/common/NativeCompilation.gmk, look for >>>>> DEPENDENCY_TARGET_SED_PATTERN. >>>>> >>>>> >>>>> >>>>> Question 2: What would be the best way to submit/share the patches for >>>>> your thorough review? >>>>> >>>>> Well, first of all, have you signed the OCA? >>>>> >>>>> As for publishing patches and reviews, there is a bit of chicken and >>>>> egg problem. Once you become an "author" in any of the OpenJDK projects, >>>>> you get a user name and should be able to publish reviews on >>>>> cr.openjdk.java.net>>>> penjdk.java.net>>>> k.java.net/%3e%3chttp:/cr.openjdk.java.net%3chttp:/cr. >>>>> openjdk.java.net/>>>. Before that, if the patch is small, it can be >>>>> posted inline in an email to the list. If it's large, you will need a >>>>> current OpenJDK user to host it for you. At least that's how I understand >>>>> it. Hopefully someone who knows the process better can chime in here. >>>>> >>>>> I should also let you know that getting this into JDK 9 is most likely >>>>> not going to happen. AFAIK we are only doing security updates for 9. It >>>>> would have to go into the currently active release. I should also warn you >>>>> that new ports generally need a certain amount of backing to be accepted. >>>>> It may be that this would have to live in a porting side project. Hopefully >>>>> someone who knows this better can chime in here as well. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> P. >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Magnus Ihse Bursie >>>>> Sent: Tuesday, October 10, 2017 10:04 AM >>>>> To: Peter Budai; Erik Joelsson>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net>>>> build-dev at openjdk.java.net> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> On 2017-10-07 10:14, Peter Budai wrote: >>>>> The configure of OpenJDK overwrites the SHELL. Actually it is using >>>>> bash, but for the arguments it was using ?-e -o pipefail?. I have figured >>>>> that for MSYS2 bash what is needed as bash arguments is ?-e -l -c -o >>>>> pipefail? >>>>> >>>>> That looks like solving this problem, and now the real issues are >>>>> surfacing. >>>>> >>>>> FWIW, "-l" makes bash behave like a login shell. Most likely you are >>>>> changing bash's behavior in one of your login scripts, and that change is >>>>> what's really needed. >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Peter >>>>> >>>>> From: Peter Budai >>>>> Sent: Friday, October 6, 2017 6:43 PM >>>>> To: Magnus Ihse Bursie; Erik >>>>> Joelsson; build-dev at openjdk.java.net >>>>> >>>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>>> >>>>> Magnus, >>>>> >>>>> I have followed your suggestion and removed the fixpath prefixes from >>>>> gcc related compile tools, and left only the fixpath prefix _only_ for the >>>>> Boot JDK related tools in place. >>>>> >>>>> 1) As I follow the process, all java and javac related compile >>>>> steps are running properly >>>>> 2) When the process reaches gcc related steps I got the error >>>>> message at the same place as before (no fixpath). If I execute that command >>>>> from the bash prompt, it creates the output: >>>>> >>>>> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >>>>> /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/j >>>>> dk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template >>>>> 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | >>>>> /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ >>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' >>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption >>>>> Registry.java >>>>> >>>>> As I have mentioned the parameters are replaced by the bash >>>>> automatically >>>>> 3) Then build continues, then little later stops at a super >>>>> simple command: >>>>> >>>>> mv /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java >>>>> Needless to say, the ByteBuffer.java.tmp file DOES exist. >>>>> And running the above command from the bash works, and build continues. >>>>> 4) A few similar cases (stops) with DirectByteBuffer and >>>>> DirectByteBufferR >>>>> >>>>> >>>>> Currently I try to explore how that might relate to the MSYS2 bash and >>>>> make, somehow it behaves differently >>>>> >>>>> If you have any other suggestion, let me know. >>>>> >>>>> Best regards, >>>>> >>>>> Peter >>>>> >>>>> From: Peter Budai >>>>> Sent: Thursday, October 5, 2017 3:52 PM >>>>> To: Magnus Ihse Bursie; Erik >>>>> Joelsson; build-dev at openjdk.java.net >>>>> >>>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>>> >>>>> Hi Magnus, >>>>> >>>>> So first of all, here is the current patch, which I was not able to >>>>> attach: https://pastebin.com/pwT4Ynxc >>>>> >>>>> That's surprising, since gcc is prefixed with fixpath, which it should >>>>>>> not. >>>>>>> >>>>>> Actually you DO need fixpath IMHO. >>>>> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), >>>>> which is a fully functional Windows executable, which expects Windows >>>>> formatted path arguments. >>>>> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see >>>>> that patch), none of the command line arguments are converted from the >>>>> unix path to Windows, but fixpath does that conversion. There is a wiki >>>>> describing more details on this: >>>>> https://github.com/msys2/msys2/wiki/Porting#user-content- >>>>> filesystem-namespaces >>>>> >>>>> >>>>> >>>>> I have a hard time believing this is a race condition. On the other >>>>>>> hand, this stuff is weird, we're misusing the C preprocessor to process >>>>>>> defines in java code, so I'm not surprised it breaks down. >>>>>>> I don't know why it succeeded when run on the command line, though. >>>>>>> >>>>>> When I execute that command from the bash command line there is no >>>>> EXPORT MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic >>>>> conversion of the arguments. Maybe it has something to do how fixpath does >>>>> CreateProcess? >>>>> >>>>> Does that help? >>>>> >>>>> Best regards, >>>>> >>>>> Peter >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Magnus Ihse Bursie >>>>> Sent: Thursday, October 5, 2017 12:13 PM >>>>> To: Peter Budai; Erik Joelsson>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net>>>> build-dev at openjdk.java.net> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> >>>>> On 2017-10-05 11:59, Peter Budai wrote: >>>>> Hi Magnus and Erik, >>>>> >>>>> I really appreciate your quick feedback. I assumed that it won?t be >>>>> easy, but I just don?t feel I should give up now - maybe later when I see >>>>> the real scale of work. So bear with me for a time being. >>>>> >>>>> Attached is a patch which already includes Magnus? changes, plus a few >>>>> which I have added: >>>>> ? basically enabling gcc for windows, >>>>> ? and modifying a logic for compiling fixpath (before that it >>>>> was using hard-coded MS VSC compile flags) >>>>> >>>>> Actually, you must make sure fixpath is *not* used for the toolchain, >>>>> since gcc uses unix style paths. >>>>> (However, other tools such as java will still need it.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So here is what I have as the result of configure: >>>>> ==================================================== >>>>> The existing configuration has been successfully updated in >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release >>>>> using configure arguments '--disable-freetype-bundling >>>>> --disable-javac-server'. >>>>> >>>>> Configuration summary: >>>>> * Debug level: release >>>>> * HS debug level: product >>>>> * JDK variant: normal >>>>> * JVM variants: server >>>>> * OpenJDK target: OS: windows, CPU architecture: x86, address length: >>>>> 64 >>>>> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) >>>>> >>>>> Tools summary: >>>>> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) >>>>> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime >>>>> Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build >>>>> 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) >>>>> * Toolchain: gcc (GNU Compiler Collection) >>>>> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) >>>>> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) >>>>> >>>>> Build performance summary: >>>>> * Cores to use: 4 >>>>> * Memory limit: 16216 MB >>>>> >>>>> Its clear says that the toolchain is gcc 7.2 (BTW there is no Visual >>>>> Studio on this machine) >>>>> >>>>> Now for the details of the config log, you can see here: >>>>> https://pastebin.com/MN2ZYcHH >>>>> >>>>> And about the build process and the error I get: >>>>> >>>>> $ make JOBS=1 >>>>> Building target 'default (exploded-image)' in configuration >>>>> 'windows-x86_64-normal-server-release' >>>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >>>>> Compiling 17 properties into resource bundles for jdk.compiler >>>>> Parsing 1 properties into enum-like class for jdk.compiler >>>>> Compiling 19 properties into resource bundles for jdk.javadoc >>>>> Compiling 12 properties into resource bundles for jdk.jdeps >>>>> Compiling 7 properties into resource bundles for jdk.jshell >>>>> Compiling 117 files for BUILD_INTERIM_java.compiler >>>>> Compiling 396 files for BUILD_INTERIM_jdk.compiler >>>>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps >>>>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc >>>>> Note: Some input files use or override a deprecated API. >>>>> Note: Recompile with -Xlint:deprecation for details. >>>>> Compiling 159 files for BUILD_TOOLS_JDK >>>>> Note: Some input files use unchecked or unsafe operations. >>>>> Note: Recompile with -Xlint:unchecked for details. >>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b >>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav >>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>>>> make[3]: *** Deleting file '/C/msys64/home/peterbud/jdk9/ >>>>> build/windows-x86_64-normal-server-release/support/gensrc/ja >>>>> va.base/sun/nio/ch/SocketOptionRegistry.java' >>>>> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 >>>>> >>>>> ERROR: Build failed for target 'default (exploded-image)' in >>>>> configuration 'windows-x86_64-normal-server-release' (exit code 2) >>>>> >>>>> No indication of failed target found. >>>>> Hint: Try searching the build log for '] Error'. >>>>> Hint: See common/doc/building.html#troubleshooting for assistance. >>>>> >>>>> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 >>>>> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 >>>>> >>>>> If I run here >>>>> make JOBS=1 LOG=debug >>>>> The failing line seems to be this: >>>>> >>>>> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/configure-support/bin/fixpath.exe >>>>> -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x c >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>> /sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep -v >>>>> '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk >>>>> '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ >>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' >>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption >>>>> Registry.java >>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b >>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav >>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>>>> >>>>> Now the interesting is: if I copy this line above to the bash prompt, >>>>> it runs without problem, and the file support/gensrc/java.base/sun/n >>>>> io/ch/SocketOptionRegistry.java >>>>> That's surprising, since gcc is prefixed with fixpath, which it should >>>>> not. >>>>> >>>>> I have a hard time believing this is a race condition. On the other >>>>> hand, this stuff is weird, we're misusing the C preprocessor to process >>>>> defines in java code, so I'm not suprised it breaks down. I don't know why >>>>> it succeeded when run on the command line, though. My suggestion is to just >>>>> do some quick and dirty hack around this: take the file you manage to >>>>> generate and just copy it in during the build instead. If you can get round >>>>> this, you might start seeing some *real* problems. :-) >>>>> >>>>> Also, my suggestion is that you try running "make hotspot" to cut to >>>>> the chase. Compiling hotspot will likely be the hardest thing. Or even >>>>> "make -k hotspot" to get an assessment of the amount of work ahead of you. >>>>> >>>>> /Magnus >>>>> Is produced. >>>>> >>>>> Then I can again issue >>>>> make JOBS=1 LOG=debug >>>>> >>>>> And the compile process is being continued, until a similar error pops >>>>> up with a different generated file. I have an assumption that this happens >>>>> because make is still running parallel jobs, despite JOBS=1 but I?m not >>>>> sure. >>>>> >>>>> How could I best tackle this? >>>>> >>>>> Thank you and best regards, >>>>> >>>>> Peter >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Magnus Ihse Bursie >>>>> Sent: Thursday, October 5, 2017 11:33 AM >>>>> To: Erik Joelsson; Peter >>>>> Budai; build-dev at openjdk.java.net>>>> lto:build-dev at openjdk.java.net> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> On 2017-10-05 10:10, Erik Joelsson wrote: >>>>> >>>>>> Hello Peter, >>>>>> >>>>>> >>>>>> On 2017-10-04 21:15, Peter Budai wrote: >>>>>> >>>>>>> Hi Magnus, >>>>>>> >>>>>>> Thanks for the quick reply I?ll check these patches with msys2. >>>>>>> >>>>>>> Let me specify with more details what I?d like to achieve: I?d like >>>>>>> to build OpenJDK9 with MSYS2 MINGW64 environment using gcc toolchain. >>>>>>> (I?m not sure how familiar are you with MSYS2, but there are 3 >>>>>>> different environments: MSYS2, MINGW32 and MINGW64). In theory >>>>>>> MINGW64 with gcc is the closes you can get on Windows platform as a >>>>>>> gcc unix like build environment, which produces still a native 64-bit >>>>>>> executable on Windows. >>>>>>> >>>>>>> I?m not very familiar with OpenJDK yet, so therefore I?d like to hear >>>>>>> your opinion: how realistic is that? >>>>>>> >>>>>> Sorry to disappoint, but I would say that requires major work. There >>>>>> is a strong historic assumption that windows builds are done using >>>>>> Visual Studio. We have abstracted away some of it in configure (see >>>>>> TOOLCHAIN_TYPE), but it's very far from enough to change compiler >>>>>> environment for a Windows build. The native sources are also bound to >>>>>> make a lot of such assumptions. I would expect the changes needed to >>>>>> be in the thousands of lines of code. >>>>>> >>>>> I agree that it requires hard work (even if "thousands" might be an >>>>> overestimation I think, but "hundreds" is not enough, so it's the right >>>>> magnitude). On the other hand, it would be really good if we did sort >>>>> things out, so that we had proper conditions based on OS vs >>>>> compiler/toolchain. >>>>> >>>>> If you really want to start, the first thing is to patch toolchain.m4 >>>>> to >>>>> VALID_TOOLCHAINS_windows="microsoft gcc" >>>>> and then call configure using "bash configure >>>>> --with-toolchain-type=gcc". >>>>> >>>>> As Erik, I doubt you will come very far before things starts tumbling >>>>> down. >>>>> >>>>> When we say supporting the build in msys2 instead of cygwin, we just >>>>>> mean using msys2 as the unix emulating layer for our tools like >>>>>> make/bash/grep/sed etc. >>>>>> >>>>>> One think I have done successfully is running the build in WSL >>>>>> (Windows Subsystem for Linux), but that isn't all that helpful as WSL >>>>>> for practical purposes is more or less like running Linux in a VM, so >>>>>> the build sees a Linux system and builds a Linux binary. >>>>>> >>>>>>> As a side note: with MINGW64 I have managed to run configure phase >>>>>>> successfully for OpenJDK. The compile process has also started and >>>>>>> went for a while, but interestingly I run into some kind of race >>>>>>> conditions as make stopped with an error. Using LOG=debug I have fond >>>>>>> the failing line and then copying the failed command and pasting it >>>>>>> to the bash prompt it successfully generated the output target, and >>>>>>> then the build process run further when a similar situation happened. >>>>>>> Also pasting the failed command run in the bash without any problem, >>>>>>> and build continued? until the next. >>>>>>> >>>>>> Without seeing the errors I can't say much. I very much doubt that you >>>>>> are running with gcc as the compiler though. Configure isn't easily >>>>>> fooled into using a different compiler to what it prefers, and I would >>>>>> expect things to crash and burn pretty early if you actually did. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> I have tried to run make JOBS=1, but did not help, strangely I have >>>>>>> still seen in the log make[3] and make[4] logs which suggested that >>>>>>> there are more than one make jobs were running. Also tried .configure >>>>>>> --with-output-sync=recurse without success (same symptoms) >>>>>>> >>>>>>> Let me know your thoughts. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> Sent from Mail for >>>>>>> Windows 10 >>>>>>> >>>>>>> From: Magnus Ihse Bursie >>>>>>> Sent: Wednesday, October 4, 2017 1:04 AM >>>>>>> To: Peter Budai; >>>>>>> build-dev at openjdk.java.net>>>>>> >>>>>>> k.java.net> >>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>> >>>>>>> Actually, it wasn't so much remaining trouble. :-) I fired up msys2 >>>>>>> and >>>>>>> checked out where I left off. It turned out that the remaining snag >>>>>>> was >>>>>>> that msys2 tries to convert command lines automatically, from "unix" >>>>>>> style paths to "windows" style paths. Unfortunately, it does not do >>>>>>> this >>>>>>> very well and it breaks all sorts of things. We already have a >>>>>>> FIXPATH >>>>>>> solution in place which deals with this, so basically all I had to do >>>>>>> was disable this (by setting MSYS2_ARG_CONV_EXCL to "*"). However, >>>>>>> this >>>>>>> broke our cygpath replacement hack (!) so I had to disable it there. >>>>>>> Sigh. Anyway, with those fixes it ran and worked well. (I also >>>>>>> discovered and fixed a bug related to how we set up the FIXPATH >>>>>>> variable >>>>>>> on msys, but it only triggers in certain circumstances). >>>>>>> >>>>>>> With this patch I now jdk9 seems to build fine on msys2. It should >>>>>>> apply >>>>>>> cleanly on jdk9/jdk9. Since it turned out to be so trivial, I'll try >>>>>>> to >>>>>>> get it in in jdk10. >>>>>>> >>>>>>> Here's the patch if you want to apply it yourself: >>>>>>> >>>>>>> diff -r a08cbfc0e4ec common/autoconf/basics_windows.m4 >>>>>>> --- a/common/autoconf/basics_windows.m4 Thu Aug 03 18:56:56 2017 >>>>>>> +0000 >>>>>>> +++ b/common/autoconf/basics_windows.m4 Wed Oct 04 00:53:58 2017 >>>>>>> +0200 >>>>>>> @@ -42,7 +42,7 @@ >>>>>>> windows_path=`$CYGPATH -m "$unix_path"` >>>>>>> $1="$windows_path" >>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then >>>>>>> - windows_path=`cmd //c echo $unix_path` >>>>>>> + windows_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $unix_path` >>>>>>> $1="$windows_path" >>>>>>> fi >>>>>>> ]) >>>>>>> @@ -136,6 +136,16 @@ >>>>>>> fi >>>>>>> ]) >>>>>>> >>>>>>> +AC_DEFUN([BASIC_MSYS_UPDATE_FIXPATH], >>>>>>> +[ >>>>>>> + # Take all collected prefixes and turn them into a >>>>>>> -m/c/foo@/c/bar at ... command line >>>>>>> + # @ was chosen as separator to minimize risk of other tools >>>>>>> messing >>>>>>> around with it >>>>>>> + all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >>>>>>> + | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>>>> + fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >>>>>>> + FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>>>> +]) >>>>>>> + >>>>>>> AC_DEFUN([BASIC_FIXUP_PATH_MSYS], >>>>>>> [ >>>>>>> path="[$]$1" >>>>>>> @@ -143,7 +153,7 @@ >>>>>>> new_path="$path" >>>>>>> if test "x$has_colon" = x; then >>>>>>> # Not in mixed or Windows style, start by that. >>>>>>> - new_path=`cmd //c echo $path` >>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $path` >>>>>>> fi >>>>>>> >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>>>> @@ -155,6 +165,8 @@ >>>>>>> >>>>>>> # Save the first 10 bytes of this path to the storage, so >>>>>>> fixpath >>>>>>> can work. >>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>>>> "${new_path:0:10}") >>>>>>> + # We might need to re-evaluate FIXPATH. >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>>> ]) >>>>>>> >>>>>>> AC_DEFUN([BASIC_FIXUP_EXECUTABLE_CYGWIN], >>>>>>> @@ -293,7 +305,7 @@ >>>>>>> # Do not save /bin paths to all_fixpath_prefixes! >>>>>>> else >>>>>>> # Not in mixed or Windows style, start by that. >>>>>>> - new_path=`cmd //c echo $new_path` >>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $new_path` >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>>>> # Output is in $new_path >>>>>>> BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(new_path) >>>>>>> @@ -302,6 +314,8 @@ >>>>>>> >>>>>>> # Save the first 10 bytes of this path to the storage, so >>>>>>> fixpath >>>>>>> can work. >>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>>>> "${new_path:0:10}") >>>>>>> + # We might need to re-evaluate FIXPATH. >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>>> fi >>>>>>> ]) >>>>>>> >>>>>>> @@ -347,6 +361,10 @@ >>>>>>> WINDOWS_ENV_VENDOR='msys' >>>>>>> WINDOWS_ENV_VERSION="$MSYS_VERSION" >>>>>>> >>>>>>> + # Prohibit msys2 path conversion from trying to be >>>>>>> "intelligent", >>>>>>> and rely >>>>>>> + # on fixpath instead. >>>>>>> + export MSYS2_ARG_CONV_EXCL="*" >>>>>>> + >>>>>>> AC_MSG_CHECKING([msys root directory as unix-style path]) >>>>>>> # The cmd output ends with Windows line endings (CR/LF), >>>>>>> the grep >>>>>>> command will strip that away >>>>>>> MSYS_ROOT_PATH=`cd / ; cmd /c cd | $GREP ".*"` >>>>>>> @@ -391,10 +409,7 @@ >>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.msys; then >>>>>>> # Take all collected prefixes and turn them into a >>>>>>> -m/c/foo@/c/bar at ... command line >>>>>>> # @ was chosen as separator to minimize risk of other >>>>>>> tools >>>>>>> messing around with it >>>>>>> - all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" >>>>>>> \ >>>>>>> - | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>>>> - fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' >>>>>>> '@'` >>>>>>> - FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>>> fi >>>>>>> FIXPATH_SRC_W="$FIXPATH_SRC" >>>>>>> FIXPATH_BIN_W="$FIXPATH_BIN" >>>>>>> diff -r a08cbfc0e4ec common/autoconf/build-aux/config.sub >>>>>>> --- a/common/autoconf/build-aux/config.sub Thu Aug 03 18:56:56 >>>>>>> 2017 +0000 >>>>>>> +++ b/common/autoconf/build-aux/config.sub Wed Oct 04 00:53:58 >>>>>>> 2017 +0200 >>>>>>> @@ -30,7 +30,7 @@ >>>>>>> DIR=`dirname $0` >>>>>>> >>>>>>> # First, filter out everything that doesn't begin with >>>>>>> "aarch64-" >>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>>> . $DIR/autoconf-config.sub "$@" >>>>>>> # autoconf-config.sub exits, so we never reach here, but >>>>>>> just in >>>>>>> # case we do: >>>>>>> @@ -38,13 +38,17 @@ >>>>>>> fi >>>>>>> >>>>>>> while test $# -gt 0 ; do >>>>>>> - case $1 in >>>>>>> + case $1 in >>>>>>> -- ) # Stop option processing >>>>>>> shift; break ;; >>>>>>> aarch64-* ) >>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>>> sub_args="$sub_args $config" >>>>>>> shift; ;; >>>>>>> + *-msys ) >>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>>> + sub_args="$sub_args $config" >>>>>>> + shift; ;; >>>>>>> - ) # Use stdin as input. >>>>>>> sub_args="$sub_args $1" >>>>>>> shift; break ;; >>>>>>> diff -r a08cbfc0e4ec common/autoconf/spec.gmk.in >>>>>>> --- a/common/autoconf/spec.gmk.in Thu Aug 03 18:56:56 2017 +0000 >>>>>>> +++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 +0200 >>>>>>> @@ -120,6 +120,13 @@ >>>>>>> # On Windows, the Visual Studio toolchain needs the PATH to be >>>>>>> adjusted >>>>>>> # to include Visual Studio tools (this needs to be in >>>>>>> cygwin/msys >>>>>>> style). >>>>>>> export PATH:=@VS_PATH@ >>>>>>> + >>>>>>> +endif >>>>>>> + >>>>>>> +ifeq ($(OPENJDK_TARGET_OS_ENV), windows.msys) >>>>>>> + # On msys2, prohibit msys path conversion from trying to be >>>>>>> + # "intelligent", and rely on fixpath instead. >>>>>>> + export MSYS2_ARG_CONV_EXCL:=* >>>>>>> endif >>>>>>> >>>>>>> SYSROOT_CFLAGS := @SYSROOT_CFLAGS@ >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> On 2017-10-03 22:34, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>>> I gave msys2 a shot some time ago, but it ended up too much trouble. >>>>>>>> I'll share some of my notes from that attempt, for what it's worth. >>>>>>>> >>>>>>>> To install package X/Y, run "pacman -S X/Y". Missing tools and >>>>>>>> packages where to find them: >>>>>>>> cmp: msys/diffutils >>>>>>>> tar: msys/tar >>>>>>>> make: msys/make >>>>>>>> unzip: msys/unzip >>>>>>>> zip: msys/zip >>>>>>>> >>>>>>>> config.sub reports msys as "x86_64-pc-mingw32" but msys2 as >>>>>>>> "x86_64-pc-msys". This patch adds postprocessing in "our" config.sub >>>>>>>> to report msys2 similar to msys. (Opinions, including my own :-) may >>>>>>>> vary if this really is the best way..) >>>>>>>> >>>>>>>> diff -r b88023f46daa common/autoconf/build-aux/config.sub >>>>>>>> --- a/common/autoconf/build-aux/config.sub Fri Jan 27 10:15:41 >>>>>>>> 2017 +0100 >>>>>>>> +++ b/common/autoconf/build-aux/config.sub Fri Feb 03 05:00:25 >>>>>>>> 2017 -0700 >>>>>>>> @@ -30,7 +30,7 @@ >>>>>>>> DIR=`dirname $0` >>>>>>>> >>>>>>>> # First, filter out everything that doesn't begin with >>>>>>>> "aarch64-" >>>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>>>> . $DIR/autoconf-config.sub "$@" >>>>>>>> # autoconf-config.sub exits, so we never reach here, but >>>>>>>> just in >>>>>>>> # case we do: >>>>>>>> @@ -45,6 +45,10 @@ >>>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>>>> sub_args="$sub_args $config" >>>>>>>> shift; ;; >>>>>>>> + *-msys ) >>>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>>>> + sub_args="$sub_args $config" >>>>>>>> + shift; ;; >>>>>>>> - ) # Use stdin as input. >>>>>>>> sub_args="$sub_args $1" >>>>>>>> shift; break ;; >>>>>>>> >>>>>>>> If I remember correctly, this got me past the configure stage at the >>>>>>>> time. >>>>>>>> >>>>>>>> I don't think it's very hard to get it to work on msys2, I just ran >>>>>>>> into one snag too many and didn't think msys2 would be used by >>>>>>>> anyone. >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> On 2017-10-03 17:20, Peter Budai wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> According to >>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/commo >>>>>>>>> n/doc/building.html >>>>>>>>> >>>>>>>>> ?msys2 and the new Windows Subsystem for Linux (WSL) would likely >>>>>>>>> be >>>>>>>>> possible to support in a future version but that would require a >>>>>>>>> community effort to implement? >>>>>>>>> >>>>>>>>> I?d like to help making the OpenJDK 9 build working on msys2. What >>>>>>>>> is >>>>>>>>> the best way to move forward? Is there a similar effort in >>>>>>>>> progress? >>>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > From sgehwolf at redhat.com Thu Nov 23 09:42:19 2017 From: sgehwolf at redhat.com (Severin Gehwolf) Date: Thu, 23 Nov 2017 10:42:19 +0100 Subject: zero build slow In-Reply-To: References: Message-ID: <1511430139.4103.8.camel@redhat.com> Hi Thomas, On Wed, 2017-11-22 at 17:26 +0100, Thomas St?fe wrote: > Hi guys, > > thanks for your help. > > I think the reason is the combination of zero+slowdebug and the fact that > we run our own binaries during build (at least this is true for jmod). > > I am building on Ubuntu 16.4, "normal" machine (i7, 16G ram, ssd). Normally > my builds take ~5-10 minutes. > > My configure line in this case: > > CONFIGURE_COMMAND_LINE:=--with-boot-jdk=/shared/projects/openjdk/jdks/openjdk9 > --with-debug-level=slowdebug --with-jvm-variants=zero > --with-native-debug-symbols=internal > > Wanted slowdebug to test something. Boot jdk is downloaded from > adoptopenjdk (I was lazy). > > When building (make images), top is dominated by jmod, which is taken from > the output directory, not the bootstrap vm: > > 19710 thomas 30 10 1176348 63480 15800 S 100,0 0,4 2:02.64 > /shared/projects/openjdk/jdk-hs/output-zero/jdk/bin/jmod -J-XX:+UseSerialGC > -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 create --module-version > 10-internal --target-platform linux-amd64 --module-path /sha+ > > Note that my normal (non-zero) slowdebug builds are done in ~5 minutes, but > this thing here is now running for 30 minutes and not done yet. Hence my > assumption, that we need to run jmod from the build directory and that a > zero jmod in slowdebug mode is terrible. > > It probably makes sense, when I run jmod interpreted and the C++ code is > not optimized... Hence my original question, whether I can force the build > to use a different jmod. This would also help in cases when I am developing > and my hotspot is crashy - currently, the build does not go thru in this > case. > > I will retry with fastdebug to see how much faster this is. That matches my experience. FWIW, despite it being slow, running jmod using the just built JDK proved to be a reasonable test case for Zero issues. I've seen asserts being triggered or segfaults to happen during some runs indicating that there were issues. If you don't care about that, Erik pointed you at the solution :) Cheers, Severin From aph at redhat.com Thu Nov 23 09:52:56 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 09:52:56 +0000 Subject: zero build slow In-Reply-To: <58e6f8ee-f9ea-de00-c21c-73a282266134@oracle.com> References: <58e6f8ee-f9ea-de00-c21c-73a282266134@oracle.com> Message-ID: <4bfe10bc-944a-3d79-ea1e-a5d7912a01a0@redhat.com> On 22/11/17 17:09, Erik Joelsson wrote: > There is a configure option: > > ? --with-build-jdk??????? path to JDK of same version as is being built[the > ????????????????????????? newly built JDK] > > If set, this jdk is used instead of the newly built jdk for any tool > that needs to run, like jmod and jlink. I realize the help text could be > more elaborate in explaining this Well, that's great to know. I always assumed the only purpose of this was to override the JDK that is discovered by the configure script. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From ted at tedneward.com Thu Nov 23 10:23:25 2017 From: ted at tedneward.com (Ted Neward) Date: Thu, 23 Nov 2017 02:23:25 -0800 Subject: Problems with JDK8 build on Ubuntu? Message-ID: I?m trying to build JDK8 on a brand-new Ubuntu VM. Fresh forest, fresh dependency setup, the works. When I run it, there?s a problem about OS version detection, which I found a fix for, but then it appears that there?s some kind of syntax error in a generate makefile. Before I attach a ridiculously long logfile, does anybody have a quick fix or know where I should go to get the fix? Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 From glaubitz at physik.fu-berlin.de Thu Nov 23 10:32:42 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 23 Nov 2017 11:32:42 +0100 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: References: Message-ID: Hi Ted! On 11/23/2017 11:23 AM, Ted Neward wrote: > When I run it, there?s a problem about OS version detection, which I found a fix > for, but then it appears that there?s some kind of syntax error in a generate makefile. > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > I should go to get the fix? I suggest having a look at the Debian packaging source for the openjdk-8 package which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. Have a look at the patches in debian/patches as well as the build script in debian/ rules. This should give you the right idea on what is necessary to OpenJDK 8 build on Ubuntu. Please also make sure you have the necessary build dependencies installed: # apt build-dep openjdk-8 Adrian > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From ted at tedneward.com Thu Nov 23 10:50:02 2017 From: ted at tedneward.com (Ted Neward) Date: Thu, 23 Nov 2017 02:50:02 -0800 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: References: Message-ID: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: Hi Ted! On 11/23/2017 11:23 AM, Ted Neward wrote: > When I run it, there?s a problem about OS version detection, which I found a fix > for, but then it appears that there?s some kind of syntax error in a generate makefile. > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > I should go to get the fix? I suggest having a look at the Debian packaging source for the openjdk-8 package which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. Have a look at the patches in debian/patches as well as the build script in debian/ rules. This should give you the right idea on what is necessary to OpenJDK 8 build on Ubuntu. Please also make sure you have the necessary build dependencies installed: # apt build-dep openjdk-8 Adrian > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From dalibor.topic at oracle.com Thu Nov 23 11:08:13 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 23 Nov 2017 12:08:13 +0100 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> Message-ID: You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? cheers, dalibor topic On 23.11.2017 11:50, Ted Neward wrote: > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > Hi Ted! > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > When I run it, there?s a problem about OS version detection, which I found a fix > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > I should go to get the fix? > > I suggest having a look at the Debian packaging source for the openjdk-8 package > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > Have a look at the patches in debian/patches as well as the build script in debian/ > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > on Ubuntu. > > Please also make sure you have the necessary build dependencies installed: > > # apt build-dep openjdk-8 > > Adrian > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From ted at tedneward.com Thu Nov 23 11:12:16 2017 From: ted at tedneward.com (Ted Neward) Date: Thu, 23 Nov 2017 03:12:16 -0800 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> Message-ID: <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> Errr?.. What?s the difference, again? I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? cheers, dalibor topic On 23.11.2017 11:50, Ted Neward wrote: > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > Hi Ted! > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > When I run it, there?s a problem about OS version detection, which I found a fix > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > I should go to get the fix? > > I suggest having a look at the Debian packaging source for the openjdk-8 package > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > Have a look at the patches in debian/patches as well as the build script in debian/ > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > on Ubuntu. > > Please also make sure you have the necessary build dependencies installed: > > # apt build-dep openjdk-8 > > Adrian > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > -- > .''`. John Paul Adrian Glaubitz > : :' : Debian Developer - glaubitz at debian.org > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Nov 23 11:14:32 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 23 Nov 2017 12:14:32 +0100 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> Message-ID: <1845eabe-faa4-941e-8806-81478464767d@oracle.com> Probably - jdk8/jdk8 is the GA source code from a few years ago. jdk8u/jdk8u is the latest JDK 8 updates. cheers, dalibor topic On 23.11.2017 12:12, Ted Neward wrote: > Errr?.. What?s the difference, again? > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > cheers, > dalibor topic > > On 23.11.2017 11:50, Ted Neward wrote: > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > Hi Ted! > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > I should go to get the fix? > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > on Ubuntu. > > > > Please also make sure you have the necessary build dependencies installed: > > > > # apt build-dep openjdk-8 > > > > Adrian > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > -- > > .''`. John Paul Adrian Glaubitz > > : :' : Debian Developer - glaubitz at debian.org > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From ted at tedneward.com Thu Nov 23 11:15:36 2017 From: ted at tedneward.com (Ted Neward) Date: Thu, 23 Nov 2017 03:15:36 -0800 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <1845eabe-faa4-941e-8806-81478464767d@oracle.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> Message-ID: <75BFB179-26B4-4551-92FA-A46D07AE6F0F@tedneward.com> Save me a Google and remind me where that repo URL is? :-) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 11/23/17, 3:14 AM, "dalibor topic" wrote: Probably - jdk8/jdk8 is the GA source code from a few years ago. jdk8u/jdk8u is the latest JDK 8 updates. cheers, dalibor topic On 23.11.2017 12:12, Ted Neward wrote: > Errr?.. What?s the difference, again? > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > cheers, > dalibor topic > > On 23.11.2017 11:50, Ted Neward wrote: > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > Hi Ted! > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > I should go to get the fix? > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > on Ubuntu. > > > > Please also make sure you have the necessary build dependencies installed: > > > > # apt build-dep openjdk-8 > > > > Adrian > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > -- > > .''`. John Paul Adrian Glaubitz > > : :' : Debian Developer - glaubitz at debian.org > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From thomas.stuefe at gmail.com Thu Nov 23 11:18:10 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Nov 2017 12:18:10 +0100 Subject: zero build slow In-Reply-To: <1511430139.4103.8.camel@redhat.com> References: <1511430139.4103.8.camel@redhat.com> Message-ID: On Thu, Nov 23, 2017 at 10:42 AM, Severin Gehwolf wrote: > Hi Thomas, > > On Wed, 2017-11-22 at 17:26 +0100, Thomas St?fe wrote: > > Hi guys, > > > > thanks for your help. > > > > I think the reason is the combination of zero+slowdebug and the fact that > > we run our own binaries during build (at least this is true for jmod). > > > > I am building on Ubuntu 16.4, "normal" machine (i7, 16G ram, ssd). > Normally > > my builds take ~5-10 minutes. > > > > My configure line in this case: > > > > CONFIGURE_COMMAND_LINE:=--with-boot-jdk=/shared/ > projects/openjdk/jdks/openjdk9 > > --with-debug-level=slowdebug --with-jvm-variants=zero > > --with-native-debug-symbols=internal > > > > Wanted slowdebug to test something. Boot jdk is downloaded from > > adoptopenjdk (I was lazy). > > > > When building (make images), top is dominated by jmod, which is taken > from > > the output directory, not the bootstrap vm: > > > > 19710 thomas 30 10 1176348 63480 15800 S 100,0 0,4 2:02.64 > > /shared/projects/openjdk/jdk-hs/output-zero/jdk/bin/jmod > -J-XX:+UseSerialGC > > -J-Xms32M -J-Xmx512M -J-XX:TieredStopAtLevel=1 create --module-version > > 10-internal --target-platform linux-amd64 --module-path /sha+ > > > > Note that my normal (non-zero) slowdebug builds are done in ~5 minutes, > but > > this thing here is now running for 30 minutes and not done yet. Hence my > > assumption, that we need to run jmod from the build directory and that a > > zero jmod in slowdebug mode is terrible. > > > > It probably makes sense, when I run jmod interpreted and the C++ code is > > not optimized... Hence my original question, whether I can force the > build > > to use a different jmod. This would also help in cases when I am > developing > > and my hotspot is crashy - currently, the build does not go thru in this > > case. > > > > I will retry with fastdebug to see how much faster this is. > > That matches my experience. > > FWIW, despite it being slow, running jmod using the just built JDK > proved to be a reasonable test case for Zero issues. I've seen asserts > being triggered or segfaults to happen during some runs indicating that > there were issues. If you don't care about that, Erik pointed you at > the solution :) > > Yeah, sometimes I don't want that :) But I can see what you mean. I find debugging a failing jmod during build cumbersome, you have to dig in the make logs for the exact current dir and options it was started with. I rather deal with a finished image where java itself asserts. ..Thomas Cheers, > Severin > From ted at tedneward.com Thu Nov 23 11:19:36 2017 From: ted at tedneward.com (Ted Neward) Date: Thu, 23 Nov 2017 03:19:36 -0800 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <1845eabe-faa4-941e-8806-81478464767d@oracle.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> Message-ID: Oh, one other more general question: Has anybody built OpenJDK successfully using Ubuntu Server? (I just need a quick build VM, I don?t necessarily need all the GUI bells and whistles, in many/most cases.) I know AdoptOpenJDK has a Docker image, too, but I?m not sure how to use it and sort of gave up fairly quickly when it wasn?t brutally obvious. (I can?t tell if the Docker image there includes the source or not, and/or if the source would need to be mounted in a separate volume, and how then it would be updated when new changes are made, etc.) I should probably figure all that out, but I was trying to go with the least-amount-of-work path to get to a slowdebug version of the OpenJDK that I could use for some diagnostic purposes for digging into the G1 GC. Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 11/23/17, 3:14 AM, "dalibor topic" wrote: Probably - jdk8/jdk8 is the GA source code from a few years ago. jdk8u/jdk8u is the latest JDK 8 updates. cheers, dalibor topic On 23.11.2017 12:12, Ted Neward wrote: > Errr?.. What?s the difference, again? > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > cheers, > dalibor topic > > On 23.11.2017 11:50, Ted Neward wrote: > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > Hi Ted! > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > I should go to get the fix? > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > on Ubuntu. > > > > Please also make sure you have the necessary build dependencies installed: > > > > # apt build-dep openjdk-8 > > > > Adrian > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > -- > > .''`. John Paul Adrian Glaubitz > > : :' : Debian Developer - glaubitz at debian.org > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Nov 23 11:21:35 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 23 Nov 2017 12:21:35 +0100 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <75BFB179-26B4-4551-92FA-A46D07AE6F0F@tedneward.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> <75BFB179-26B4-4551-92FA-A46D07AE6F0F@tedneward.com> Message-ID: <1c9a5e6c-8453-c71f-d10b-f2ee37094307@oracle.com> hg clone http://hg.openjdk.java.net/jdk8u/jdk8u/ and then bash get_source.sh within jdk8u directory. cheers, dalibor topic On 23.11.2017 12:15, Ted Neward wrote: > Save me a Google and remind me where that repo URL is? :-) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:14 AM, "dalibor topic" wrote: > > Probably - jdk8/jdk8 is the GA source code from a few years ago. > jdk8u/jdk8u is the latest JDK 8 updates. > > cheers, > dalibor topic > > On 23.11.2017 12:12, Ted Neward wrote: > > Errr?.. What?s the difference, again? > > > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > > > cheers, > > dalibor topic > > > > On 23.11.2017 11:50, Ted Neward wrote: > > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > > > Ted Neward > > > Author, Speaker, Mentor > > > http://www.newardassociates.com > > > t: @tedneward | m: (425) 647-4526 > > > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > > > Hi Ted! > > > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > > I should go to get the fix? > > > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > > on Ubuntu. > > > > > > Please also make sure you have the necessary build dependencies installed: > > > > > > # apt build-dep openjdk-8 > > > > > > Adrian > > > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > > > -- > > > .''`. John Paul Adrian Glaubitz > > > : :' : Debian Developer - glaubitz at debian.org > > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > > > > > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From ted at tedneward.com Thu Nov 23 11:25:49 2017 From: ted at tedneward.com (Ted Neward) Date: Thu, 23 Nov 2017 03:25:49 -0800 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <1c9a5e6c-8453-c71f-d10b-f2ee37094307@oracle.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> <75BFB179-26B4-4551-92FA-A46D07AE6F0F@tedneward.com> <1c9a5e6c-8453-c71f-d10b-f2ee37094307@oracle.com> Message-ID: OK, so it?s still at java.net; that?s good to know. :-) Out of curiosity, though, what?s the difference? Why maintain two? Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 11/23/17, 3:21 AM, "dalibor topic" wrote: hg clone http://hg.openjdk.java.net/jdk8u/jdk8u/ and then bash get_source.sh within jdk8u directory. cheers, dalibor topic On 23.11.2017 12:15, Ted Neward wrote: > Save me a Google and remind me where that repo URL is? :-) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:14 AM, "dalibor topic" wrote: > > Probably - jdk8/jdk8 is the GA source code from a few years ago. > jdk8u/jdk8u is the latest JDK 8 updates. > > cheers, > dalibor topic > > On 23.11.2017 12:12, Ted Neward wrote: > > Errr?.. What?s the difference, again? > > > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > > > cheers, > > dalibor topic > > > > On 23.11.2017 11:50, Ted Neward wrote: > > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > > > Ted Neward > > > Author, Speaker, Mentor > > > http://www.newardassociates.com > > > t: @tedneward | m: (425) 647-4526 > > > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > > > Hi Ted! > > > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > > I should go to get the fix? > > > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > > on Ubuntu. > > > > > > Please also make sure you have the necessary build dependencies installed: > > > > > > # apt build-dep openjdk-8 > > > > > > Adrian > > > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > > > -- > > > .''`. John Paul Adrian Glaubitz > > > : :' : Debian Developer - glaubitz at debian.org > > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > > > > > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From aph at redhat.com Thu Nov 23 11:31:13 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 11:31:13 +0000 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> <75BFB179-26B4-4551-92FA-A46D07AE6F0F@tedneward.com> <1c9a5e6c-8453-c71f-d10b-f2ee37094307@oracle.com> Message-ID: <9da7eabb-1b49-7c76-721d-4d60d5fd45c6@redhat.com> On 23/11/17 11:25, Ted Neward wrote: > OK, so it?s still at java.net; that?s good to know. :-) > > Out of curiosity, though, what?s the difference? Why maintain two? The old one is not maintained. However, it is the reference implementation of JDK 8 and -- like the laws of the Medes and Persians -- can never be changed. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From dalibor.topic at oracle.com Thu Nov 23 11:31:17 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 23 Nov 2017 12:31:17 +0100 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> <75BFB179-26B4-4551-92FA-A46D07AE6F0F@tedneward.com> <1c9a5e6c-8453-c71f-d10b-f2ee37094307@oracle.com> Message-ID: <40a67107-53d2-8a5a-c1bc-7924acadd07f@oracle.com> On 23.11.2017 12:25, Ted Neward wrote: > OK, so it?s still at java.net; that?s good to know. :-) > > Out of curiosity, though, what?s the difference? Why maintain two? jdk8/jdk8 is the 'historic' source code 'archive' for the development of JDK 8. JDK 8u is what happened since in the updates. JDK Release Projects like JDK 8 have a special status in Bylaws (see http://openjdk.java.net/bylaws#jdk-release-projects) while 'regular' Projects like JDK 8 Updates do not. So updates end up being separate Projects with separate repos. Well ... you asked. ;) cheers, dalibor topic > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:21 AM, "dalibor topic" wrote: > > hg clone http://hg.openjdk.java.net/jdk8u/jdk8u/ and then bash > get_source.sh within jdk8u directory. > > cheers, > dalibor topic > > On 23.11.2017 12:15, Ted Neward wrote: > > Save me a Google and remind me where that repo URL is? :-) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 3:14 AM, "dalibor topic" wrote: > > > > Probably - jdk8/jdk8 is the GA source code from a few years ago. > > jdk8u/jdk8u is the latest JDK 8 updates. > > > > cheers, > > dalibor topic > > > > On 23.11.2017 12:12, Ted Neward wrote: > > > Errr?.. What?s the difference, again? > > > > > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > > > > > Ted Neward > > > Author, Speaker, Mentor > > > http://www.newardassociates.com > > > t: @tedneward | m: (425) 647-4526 > > > > > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > > > > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > > > > > cheers, > > > dalibor topic > > > > > > On 23.11.2017 11:50, Ted Neward wrote: > > > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > > > > > Hi Ted! > > > > > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > > > I should go to get the fix? > > > > > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > > > on Ubuntu. > > > > > > > > Please also make sure you have the necessary build dependencies installed: > > > > > > > > # apt build-dep openjdk-8 > > > > > > > > Adrian > > > > > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > > > > > -- > > > > .''`. John Paul Adrian Glaubitz > > > > : :' : Debian Developer - glaubitz at debian.org > > > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > > > > > > > > > > > -- > > > Dalibor Topic | Principal Product Manager > > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > > > ORACLE Deutschland B.V. & Co. KG > > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > > > Oracle is committed to developing > > > practices and products that help protect the environment > > > > > > > > > > > > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From ted at tedneward.com Thu Nov 23 11:36:43 2017 From: ted at tedneward.com (Ted Neward) Date: Thu, 23 Nov 2017 03:36:43 -0800 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <40a67107-53d2-8a5a-c1bc-7924acadd07f@oracle.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> <75BFB179-26B4-4551-92FA-A46D07AE6F0F@tedneward.com> <1c9a5e6c-8453-c71f-d10b-f2ee37094307@oracle.com> <40a67107-53d2-8a5a-c1bc-7924acadd07f@oracle.com> Message-ID: That is just Byzantine enough to be true. :-) I had a feeling the answer was going to be something along the lines of ?Reasons?and backwards compatibility reasons? or so, and that pretty neatly fits into that category, so?. Got it. :-) Thanks! Downloading source now and trying again. (I knew it had to be something stupidly simple on my end.) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 11/23/17, 3:31 AM, "dalibor topic" wrote: On 23.11.2017 12:25, Ted Neward wrote: > OK, so it?s still at java.net; that?s good to know. :-) > > Out of curiosity, though, what?s the difference? Why maintain two? jdk8/jdk8 is the 'historic' source code 'archive' for the development of JDK 8. JDK 8u is what happened since in the updates. JDK Release Projects like JDK 8 have a special status in Bylaws (see http://openjdk.java.net/bylaws#jdk-release-projects) while 'regular' Projects like JDK 8 Updates do not. So updates end up being separate Projects with separate repos. Well ... you asked. ;) cheers, dalibor topic > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:21 AM, "dalibor topic" wrote: > > hg clone http://hg.openjdk.java.net/jdk8u/jdk8u/ and then bash > get_source.sh within jdk8u directory. > > cheers, > dalibor topic > > On 23.11.2017 12:15, Ted Neward wrote: > > Save me a Google and remind me where that repo URL is? :-) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 3:14 AM, "dalibor topic" wrote: > > > > Probably - jdk8/jdk8 is the GA source code from a few years ago. > > jdk8u/jdk8u is the latest JDK 8 updates. > > > > cheers, > > dalibor topic > > > > On 23.11.2017 12:12, Ted Neward wrote: > > > Errr?.. What?s the difference, again? > > > > > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > > > > > Ted Neward > > > Author, Speaker, Mentor > > > http://www.newardassociates.com > > > t: @tedneward | m: (425) 647-4526 > > > > > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > > > > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > > > > > cheers, > > > dalibor topic > > > > > > On 23.11.2017 11:50, Ted Neward wrote: > > > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > > > > > Hi Ted! > > > > > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > > > I should go to get the fix? > > > > > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > > > on Ubuntu. > > > > > > > > Please also make sure you have the necessary build dependencies installed: > > > > > > > > # apt build-dep openjdk-8 > > > > > > > > Adrian > > > > > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > > > > > -- > > > > .''`. John Paul Adrian Glaubitz > > > > : :' : Debian Developer - glaubitz at debian.org > > > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > > > > > > > > > > > -- > > > Dalibor Topic | Principal Product Manager > > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > > > ORACLE Deutschland B.V. & Co. KG > > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > > > Oracle is committed to developing > > > practices and products that help protect the environment > > > > > > > > > > > > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Nov 23 11:38:00 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 23 Nov 2017 12:38:00 +0100 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> Message-ID: <45cbb1e1-8bbd-adae-5778-46dd5ca93a44@oracle.com> See https://wiki.openjdk.java.net/display/Build/Supported+Build+Platforms Other JDK 8 build platforms Linux x86 and x86_64 (green star) Ubuntu 14.04 gcc 4.8.2 Works flawlessly (green star) Ubuntu 13.10 gcc 4.8.1 Works flawlessly Ubuntu Server seems to be 16.04 or 17.10, so you may need to play with g++ flags to not error out on warnings, in case that g++ on the system is too ... fresh. It should build fine with gcc 6 based systems, too, while you may need to disable warnings as errors with gcc 7. cheers, dalibor topic On 23.11.2017 12:19, Ted Neward wrote: > Oh, one other more general question: Has anybody built OpenJDK successfully using Ubuntu Server? (I just need a quick build VM, I don?t necessarily need all the GUI bells and whistles, in many/most cases.) > > I know AdoptOpenJDK has a Docker image, too, but I?m not sure how to use it and sort of gave up fairly quickly when it wasn?t brutally obvious. (I can?t tell if the Docker image there includes the source or not, and/or if the source would need to be mounted in a separate volume, and how then it would be updated when new changes are made, etc.) I should probably figure all that out, but I was trying to go with the least-amount-of-work path to get to a slowdebug version of the OpenJDK that I could use for some diagnostic purposes for digging into the G1 GC. > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:14 AM, "dalibor topic" wrote: > > Probably - jdk8/jdk8 is the GA source code from a few years ago. > jdk8u/jdk8u is the latest JDK 8 updates. > > cheers, > dalibor topic > > On 23.11.2017 12:12, Ted Neward wrote: > > Errr?.. What?s the difference, again? > > > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > > > cheers, > > dalibor topic > > > > On 23.11.2017 11:50, Ted Neward wrote: > > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > > > Ted Neward > > > Author, Speaker, Mentor > > > http://www.newardassociates.com > > > t: @tedneward | m: (425) 647-4526 > > > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > > > Hi Ted! > > > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > > I should go to get the fix? > > > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > > on Ubuntu. > > > > > > Please also make sure you have the necessary build dependencies installed: > > > > > > # apt build-dep openjdk-8 > > > > > > Adrian > > > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > > > -- > > > .''`. John Paul Adrian Glaubitz > > > : :' : Debian Developer - glaubitz at debian.org > > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > > > > > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From glaubitz at physik.fu-berlin.de Thu Nov 23 12:10:34 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 23 Nov 2017 13:10:34 +0100 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> Message-ID: <8e2ae914-515a-f811-7551-eeb0a9bd3f8f@physik.fu-berlin.de> Hi Ted! On 11/23/2017 11:50 AM, Ted Neward wrote: > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, > but this begs a question: Why hasn?t it been backported to the JDK8 repo, > if it?s a known fix? I have upstreamed many Debian-related fixes to OpenJDK but they are so far only part of OpenJDK-10. I haven't done any backports to OpenJDK yet, but I might start doing this with OpenJDK-9 in the near future. Adrian -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From aph at redhat.com Thu Nov 23 12:15:40 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 23 Nov 2017 12:15:40 +0000 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <8e2ae914-515a-f811-7551-eeb0a9bd3f8f@physik.fu-berlin.de> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <8e2ae914-515a-f811-7551-eeb0a9bd3f8f@physik.fu-berlin.de> Message-ID: <1a6863a6-8f02-aa0c-5c14-9bd242a24a05@redhat.com> On 23/11/17 12:10, John Paul Adrian Glaubitz wrote: > I have upstreamed many Debian-related fixes to OpenJDK but they are so far > only part of OpenJDK-10. I haven't done any backports to OpenJDK yet, but > I might start doing this with OpenJDK-9 in the near future. Are these specifically Debian-related, or also things that we might carry in RPMs too? I've been wondering if it might be interesting to see if we're carrying local fixes for the same problems. -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671 From glaubitz at physik.fu-berlin.de Thu Nov 23 12:19:39 2017 From: glaubitz at physik.fu-berlin.de (John Paul Adrian Glaubitz) Date: Thu, 23 Nov 2017 13:19:39 +0100 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <1a6863a6-8f02-aa0c-5c14-9bd242a24a05@redhat.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <8e2ae914-515a-f811-7551-eeb0a9bd3f8f@physik.fu-berlin.de> <1a6863a6-8f02-aa0c-5c14-9bd242a24a05@redhat.com> Message-ID: <208e068a-79b5-4b9a-7f6e-709f9cf13a63@physik.fu-berlin.de> On 11/23/2017 01:15 PM, Andrew Haley wrote: > On 23/11/17 12:10, John Paul Adrian Glaubitz wrote: >> I have upstreamed many Debian-related fixes to OpenJDK but they are so far >> only part of OpenJDK-10. I haven't done any backports to OpenJDK yet, but >> I might start doing this with OpenJDK-9 in the near future. > > Are these specifically Debian-related, or also things that we might > carry in RPMs too? I've been wondering if it might be interesting to > see if we're carrying local fixes for the same problems. I would say most of them are not Debian-specific. However, many of the patches are just present in Debian because of the multitude of architectures that exist in Debian. The current list of patches used in the openjdk-9 package can be found in [1]. Adrian > [1] https://sources.debian.net/src/openjdk-9/9%7Eb181-2/debian/patches/ -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaubitz at debian.org `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 From magnus.ihse.bursie at oracle.com Thu Nov 23 12:21:02 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 23 Nov 2017 13:21:02 +0100 Subject: RFR: JDK-8191205 Set native-debug-symbols default to "external" In-Reply-To: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> References: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> Message-ID: <6710d591-74d4-77f0-60e8-305cec0ee75a@oracle.com> It turned out that macos bundles does not work correctly with external, non-zipped debug symbols. :-( This has probably never been tested before. This additional patch is also needed: diff --git a/make/Bundles.gmk b/make/Bundles.gmk --- a/make/Bundles.gmk +++ b/make/Bundles.gmk @@ -177,7 +177,7 @@ ?? # Create special filter rules when dealing with unzipped .dSYM directories on ?? # macosx ?? ifeq ($(OPENJDK_TARGET_OS), macosx) -??? ifeq ($(ZIP_DEBUGINFO_FILES), false) +??? ifeq ($(ZIP_EXTERNAL_DEBUG_SYMBOLS), false) ?????? JDK_SYMBOLS_EXCLUDE_PATTERN := $(addprefix %, \ ?????????? $(call containing, .dSYM/, $(patsubst $(JDK_IMAGE_DIR)/%, %, $(ALL_JDK_FILES)))) ???? endif @@ -212,7 +212,7 @@ ?? # Create special filter rules when dealing with unzipped .dSYM directories on ?? # macosx ?? ifeq ($(OPENJDK_TARGET_OS), macosx) -??? ifeq ($(ZIP_DEBUGINFO_FILES), false) +??? ifeq ($(ZIP_EXTERNAL_DEBUG_SYMBOLS), false) ?????? JRE_SYMBOLS_EXCLUDE_PATTERN := $(addprefix %, \ ?????????? $(call containing, .dSYM/, $(patsubst $(JRE_IMAGE_DIR)/%, %, $(ALL_JRE_FILES)))) ???? endif /Magnus On 2017-11-22 15:01, Magnus Ihse Bursie wrote: > We should not have "zipped" as default for native-debug-symbols. In > the future, this option should probably be dropped completely, but for > now, start by not making it default. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191205 > Patch inline: > diff --git a/make/autoconf/jdk-options.m4 b/make/autoconf/jdk-options.m4 > --- a/make/autoconf/jdk-options.m4 > +++ b/make/autoconf/jdk-options.m4 > @@ -296,13 +296,13 @@ > ?????? ], > ?????? [ > ???????? if test "x$OPENJDK_TARGET_OS" = xaix; then > -????????? # AIX doesn't support 'zipped' so use 'internal' as default > +????????? # AIX doesn't support 'external' so use 'internal' as default > ?????????? with_native_debug_symbols="internal" > ???????? else > ?????????? if test "x$STATIC_BUILD" = xtrue; then > ???????????? with_native_debug_symbols="none" > ?????????? else > -??????????? with_native_debug_symbols="zipped" > +??????????? with_native_debug_symbols="external" > ?????????? fi > ???????? fi > ?????? ]) > > /Magnus From mete.balci at antelabs.com Thu Nov 23 13:32:11 2017 From: mete.balci at antelabs.com (Mete Balci) Date: Thu, 23 Nov 2017 14:32:11 +0100 Subject: problem building client variant in 9.0.1+11 Message-ID: Hi, I am trying to build the client variant, but it fails with the output below. Is this a known issue or is there any specific configure option I should use ? Thanks, Mete Compiling 4 files for BUILD_JIGSAW_TOOLS Error: missing `server' JVM at `/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/lib/server/libjvm.so'. Please install or use the JRE or JDK that contains these missing components. ExplodedImageOptimize.gmk:40: recipe for target '/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done' failed make[3]: *** [/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done] Error 4 make/Main.gmk:356: recipe for target 'exploded-image-optimize' failed make[2]: *** [exploded-image-optimize] Error 1 -- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying, disclosure or taking of any action in reliance upon it by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. The sender accepts no liability if this email harms any systems or data of the recipient or if this email is accessed by anyone other than the person(s) to whom it is addressed. antelabs GmbH (CHE-153.180.355) is registered in Zug, Switzerland and its registered office address is Grafenauweg 10, 6301 Zug, Switzerland. From magnus.ihse.bursie at oracle.com Thu Nov 23 14:20:23 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 23 Nov 2017 15:20:23 +0100 Subject: RFR: JDK-8191820 run-test jtreg test selection and component calculation broken since consolidation Message-ID: <3319993c-7364-40f3-0fdc-dd3650dbbe17@oracle.com> The test selection and component calculation for jtreg tests have been broken since the consolidated and restructured forest. This fix will restore component calculation (which solves issues with incorrect component-specific settings, such as nativepath). It also allows for a more flexible test selection mechanism, better suited to the new test structure, while at the same time cleaning up at least a bit of the almost incomprehensible make function. Bug: https://bugs.openjdk.java.net/browse/JDK-8191820 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191820-fix-jtreg-test-selection/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Nov 23 15:56:09 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Nov 2017 07:56:09 -0800 Subject: RFR: JDK-8191205 Set native-debug-symbols default to "external" In-Reply-To: <6710d591-74d4-77f0-60e8-305cec0ee75a@oracle.com> References: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> <6710d591-74d4-77f0-60e8-305cec0ee75a@oracle.com> Message-ID: I'm pretty sure it has worked at some point because I wrote that dSYM logic and must have tested it locally at least, but it does seem weird. Anyway, fix looks good, given that you have actually tried it and checked the bundle contents. (no dSYM in jdk/jre, and all of them in the symbols bundles) /Erik On 2017-11-23 04:21, Magnus Ihse Bursie wrote: > It turned out that macos bundles does not work correctly with > external, non-zipped debug symbols. :-( This has probably never been > tested before. This additional patch is also needed: > > diff --git a/make/Bundles.gmk b/make/Bundles.gmk > --- a/make/Bundles.gmk > +++ b/make/Bundles.gmk > @@ -177,7 +177,7 @@ > ?? # Create special filter rules when dealing with unzipped .dSYM > directories on > ?? # macosx > ?? ifeq ($(OPENJDK_TARGET_OS), macosx) > -??? ifeq ($(ZIP_DEBUGINFO_FILES), false) > +??? ifeq ($(ZIP_EXTERNAL_DEBUG_SYMBOLS), false) > ?????? JDK_SYMBOLS_EXCLUDE_PATTERN := $(addprefix %, \ > ?????????? $(call containing, .dSYM/, $(patsubst $(JDK_IMAGE_DIR)/%, > %, $(ALL_JDK_FILES)))) > ???? endif > @@ -212,7 +212,7 @@ > ?? # Create special filter rules when dealing with unzipped .dSYM > directories on > ?? # macosx > ?? ifeq ($(OPENJDK_TARGET_OS), macosx) > -??? ifeq ($(ZIP_DEBUGINFO_FILES), false) > +??? ifeq ($(ZIP_EXTERNAL_DEBUG_SYMBOLS), false) > ?????? JRE_SYMBOLS_EXCLUDE_PATTERN := $(addprefix %, \ > ?????????? $(call containing, .dSYM/, $(patsubst $(JRE_IMAGE_DIR)/%, > %, $(ALL_JRE_FILES)))) > ???? endif > > /Magnus > > On 2017-11-22 15:01, Magnus Ihse Bursie wrote: >> We should not have "zipped" as default for native-debug-symbols. In >> the future, this option should probably be dropped completely, but >> for now, start by not making it default. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191205 >> Patch inline: >> diff --git a/make/autoconf/jdk-options.m4 b/make/autoconf/jdk-options.m4 >> --- a/make/autoconf/jdk-options.m4 >> +++ b/make/autoconf/jdk-options.m4 >> @@ -296,13 +296,13 @@ >> ?????? ], >> ?????? [ >> ???????? if test "x$OPENJDK_TARGET_OS" = xaix; then >> -????????? # AIX doesn't support 'zipped' so use 'internal' as default >> +????????? # AIX doesn't support 'external' so use 'internal' as default >> ?????????? with_native_debug_symbols="internal" >> ???????? else >> ?????????? if test "x$STATIC_BUILD" = xtrue; then >> ???????????? with_native_debug_symbols="none" >> ?????????? else >> -??????????? with_native_debug_symbols="zipped" >> +??????????? with_native_debug_symbols="external" >> ?????????? fi >> ???????? fi >> ?????? ]) >> >> /Magnus > From erik.joelsson at oracle.com Thu Nov 23 16:03:01 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Nov 2017 08:03:01 -0800 Subject: problem building client variant in 9.0.1+11 In-Reply-To: References: Message-ID: <43cbd94c-10ee-da91-8925-459a86bc83bf@oracle.com> Hello Mete, The options to chose which jvm to build was never completely dynamic like that unfortunately. The jvm.cfg file is still assuming only a few specific combinations. A build of client only has never been an official combination so unfortunately fails. It's really too bad because it shouldn't be hard to fix that build logic, it just has never been a priority. I don't have access to source right now, but if you want to patch your source, look for jvm.cfg* and find the template for your platform and modify it to support client only. At least that's my best guess as to what is failing here. /Erik On 2017-11-23 05:32, Mete Balci wrote: > Hi, > > I am trying to build the client variant, but it fails with the output > below. Is this a known issue or is there any specific configure option I > should use ? > > Thanks, > > Mete > > Compiling 4 files for BUILD_JIGSAW_TOOLS > Error: missing `server' JVM at > `/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/lib/server/libjvm.so'. > Please install or use the JRE or JDK that contains these missing components. > ExplodedImageOptimize.gmk:40: recipe for target > '/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done' > failed > make[3]: *** > [/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done] > Error 4 > make/Main.gmk:356: recipe for target 'exploded-image-optimize' failed > make[2]: *** [exploded-image-optimize] Error 1 > From erik.joelsson at oracle.com Thu Nov 23 16:17:27 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 23 Nov 2017 08:17:27 -0800 Subject: RFR: JDK-8191820 run-test jtreg test selection and component calculation broken since consolidation In-Reply-To: <3319993c-7364-40f3-0fdc-dd3650dbbe17@oracle.com> References: <3319993c-7364-40f3-0fdc-dd3650dbbe17@oracle.com> Message-ID: <6b16dea0-cfea-0f9a-e26a-5902be3faac7@oracle.com> Looks good, except for the indentation of the value for $1_COMPONENT. It's really a shame that you can't add comments inside the big blocks of functional logic. It sure would help in understanding what each sub block was trying to achieve. /Erik On 2017-11-23 06:20, Magnus Ihse Bursie wrote: > The test selection and component calculation for jtreg tests have been > broken since the consolidated and restructured forest. > > This fix will restore component calculation (which solves issues with > incorrect component-specific settings, such as nativepath). It also > allows for a more flexible test selection mechanism, better suited to > the new test structure, while at the same time cleaning up at least a > bit of the almost incomprehensible make function. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191820 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191820-fix-jtreg-test-selection/webrev.01 > > /Magnus From thomas.stuefe at gmail.com Thu Nov 23 21:36:07 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Thu, 23 Nov 2017 22:36:07 +0100 Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: Message-ID: On Thu, Nov 23, 2017 at 12:40 AM, Lussier, Denis wrote: > This is good stuff. Back in 2010 I got OpenJDK compiled and running on the > Microsoft Toolchain. I never ran the jtreg tests, but, the binaries > worked for running basic Tomcat but definitely not for trying to run > Eclipse. > > These days I am a pretty big fan of MSYS2. In my personal experiences with > building a PostgreSQL Windoze distribution, the MSYS2 binaries run a little > faster than using the old MS Toolchain. > > https://www.openscg.com/2016/02/building-postgresql-on- > windows-for-performance/ > > Well, the linked article does claim the msys2 toolchain to be faster than the Visual Studio, but there are no information I can see which compiler and linker options were used. Without this information, the article is difficult to take seriously. While I really respect these efforts, I regret seeing the fragmentation in windows build environments. I rather have one well kept build environment than of multiple buggy ones - and we have not that many folks interested in the windows port in the first place (it always feels like second place to the Posix platforms to me). The official build environment of the openjdk windows port is Cygwin + Visual Studio. Even if we think the gcc toolchain would be an attractive alternative to VS - why not just use the cygwin gcc instead? That way we would at least share the same posix layer. Just my 5c. Kind Regards, Thomas > --Luss > > > On Wed, Nov 22, 2017 at 4:28 PM, Jonathan Gibbons < > jonathan.gibbons at oracle.com> wrote: > > > Peter, > > > > With over 120 :tier1 test failures, it would be worth understanding the > > test failures as part of moving forward. There should normally be no > :tier1 > > test failures. > > > > -- Jon > > > > > > > > > > On 11/22/2017 01:10 PM, Peter Budai wrote: > > > >> Let me give an update on the current status: > >> > >> * I have managed to build both the 64 and the 32-bit version. > >> * The 64-bit version seems reasonable: > >> > >> > >> > >> ============================== > >> > >> Test summary - w64-bit > >> > >> ============================== > >> > >> TEST TOTAL PASS FAIL > >> ERROR > >> > >> jtreg:jdk/test:tier1 1645 1610 34 > 1 > >>>> << > >>>> jtreg:langtools/test:tier1 3907 3819 79 > >>>> 9 << > >>>> > >>> jtreg:nashorn/test:tier1 0 0 0 > >> 0 > >> > >> jtreg:jaxp/test:tier1 0 0 0 > >> 0 > >> > >> ============================== > >> > >> * However the 32-bit version of hotspot contains a bunch of inline > >> assembly pieces which uses an MSC specific syntax, and my ASM knowledge > is > >> really limited. I have managed to get a many inline assembly codes from > the > >> Linux version, but there are few pieces where I was not able to find a > good > >> solution yet, so although the 32-bit version compiles, unfortunately it > is > >> not working > >> * I have installed VS Express 2013 and made sure that the > >> ?traditional? Microsoft toolchain is still working with the changes > >> * My OCA has been processed > >> > >> I have a changeset which cleanly applies to JDK9 v181, but I recall you > >> have mentioned earlier that you would like to consider this to JDK10 > >> > >> So what is the best way to open a PR for review? This page: > >> http://openjdk.java.net/contribute/ says I should send the changeset as > >> attachment, but earlier somebody mentioned here that attachments are > >> removed from the developer mailing lists. > >> > >> Best regards, > >> > >> Peter > >> > >> From: Erik Joelsson > >> Sent: Thursday, November 2, 2017 1:07 AM > >> To: Peter Budai; Magnus Ihse > >> Bursie > >> Cc: build-dev at openjdk.java.net > >> Subject: Re: Building OpenJDK9 on MSYS2 > >> > >> I would say a few hours is way too long for tier1, but it of course > >> depends on the hardware used. We typically run it on windows in less > >> than 30 minutes with concurrency set to 6. Not sure what concurrency you > >> used by default. > >> > >> /Erik > >> > >> > >> On 2017-10-27 04:33, Peter Budai wrote: > >> > >>> Hi Magnus, after a little poking I managed to install and use jtreg, > >>> thanks for the guidance. > >>> > >>> Make run-test-tier1 resulted a pretty OK result for a first try, at > >>> least for run-test-jdk: > >>> Test results: passed: 1,610; failed: 34; error: 1 > >>> It took a few hors to run ? is that normal? > >>> > >>> I?ll review the patchset, and then share that with you. > >>> > >>> P. > >>> > >>> From: Magnus Ihse Bursie > >>> Sent: Thursday, October 26, 2017 11:00 AM > >>> To: Peter Budai > >>> Cc: build-dev at openjdk.java.net > >>> Subject: Re: Building OpenJDK9 on MSYS2 > >>> > >>> > >>> On 2017-10-26 00:01, Peter Budai wrote: > >>> OK, I have found what was missing, it was actually my fault with a > >>> missing exception handler. > >>> > >>> So finally OpenJDK build has finished on Windows using gcc toolchain > >>> running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it looks > >>> promising: > >>> ./build/windows-x86_64-normal-server-fastdebug/hotspot/varia > >>> nt-server/libjvm/gtest/gtestLauncher.exe > --jdk=/home/peterbud/jdk9/buil > >>> d/windows-x86_64-normal-server-fastdebug/jdk > >>> ?. > >>> ?. > >>> ?. > >>> > >>> [----------] Global test environment tear-down > >>> [==========] 346 tests from 54 test cases ran. (3859 ms total) > >>> [ PASSED ] 346 tests. > >>> I'm impressed! :-) > >>> > >>> Would you care to share your current patchset, just to still my > >>> curiosity? :-) > >>> > >>> > >>> > >>> What is the best way to test the current build more thoroughly? > >>> "make run-test-tier1". As Erik says, you'll need jtreg, and call > >>> "configure --with-jtreg=...". You can get it from the Adopt OpenJDK > group > >>> here: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccess > >>> fulBuild/artifact/ > >>> > >>> /Magnus > >>> > >>> > >>> P. > >>> > >>> From: Bob Vandette > >>> Sent: Tuesday, October 24, 2017 8:10 PM > >>> To: Peter Budai > >>> Cc: David Holmes; Erik > Joelsson >>> erik.joelsson at oracle.com>; Magnus Ihse Bursie >>> ie at oracle.com>; build-dev at openjdk.java.net >>> build-dev at openjdk.java.net> > >>> Subject: Re: Building OpenJDK9 on MSYS2 > >>> > >>> Can you provide some details about your toolchain, processor and os > plus > >>> a dump of the native instructions around the SEGV. This might give us > >>> enough info to be able to figure out what?s going on. > >>> > >>> Bob. > >>> > >>> On Oct 24, 2017, at 1:21 PM, Peter Budai mailto: > >>> peterbudai at hotmail.com>> wrote: > >>> > >>> I get that error running in the debugger but also running > >>> without/outside of the debugger as well. > >>> > >>> I saw the comment in the code about generating SEGV in function > >>> generate_get_cpu_info(), however the debugger can execute that, and the > >>> SEGV I experience is coming later in the VM_Version::get_processor_ > features() > >>> function > >>> > >>> Peter > >>> > >>> From: Bob Vandette > >>> Sent: Tuesday, October 24, 2017 6:28 PM > >>> To: Peter Budai > >>> Cc: David Holmes; Erik > Joelsson >>> erik.joelsson at oracle.com>; Magnus Ihse Bursie >>> ie at oracle.com>; build-dev at openjdk.java.net >>> build-dev at openjdk.java.net> > >>> Subject: Re: Building OpenJDK9 on MSYS2 > >>> > >>> Was this a SEGV while you were running the debugger? > >>> > >>> There is an intentional SEGV generated. This is used to determine if > we > >>> can use some of newer > >>> CPU features. Try to allow the SEGV to continue to see if you run > >>> normally. > >>> > >>> Bob. > >>> > >>> > >>> On Oct 24, 2017, at 11:37 AM, Peter Budai >>>> :peterbudai at hotmail.com>> wrote: > >>>> > >>>> It seems that the compile is progressing well, I have 49 > >>>> executables/tools and 38 compiled shared libraries already in the JDK > >>>> folder. > >>>> > >>>> I have tried to run the product with the simplest ?java -version? > >>>> command, however I get a SIGSEGV at get_cpu_info_stub() in > >>>> vm_version_x86.cpp, VM_Version::get_processor_features() > >>>> > >>>> get_cpu_info_stub(&_cpuid_info); > >>>> > >>>> Thread 5 received signal SIGSEGV, Segmentation fault. > >>>> 0x000000002d9a072f in ?? () > >>>> > >>>> I can debug using gdb, but unfortunately this is pure ASM, and my > >>>> knowledge on this is close to 0. > >>>> > >>>> Any idea help or pointer how could I tackle this? > >>>> > >>>> Peter > >>>> > >>>> From: David Holmes > >>>> Sent: Sunday, October 15, 2017 10:37 PM > >>>> To: Peter Budai; Erik Joelsson >>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie >>>> ie at oracle.com> > >>>> Cc: build-dev at openjdk.java.net >>>> > > >>>> Subject: Re: Building OpenJDK9 on MSYS2 > >>>> > >>>> On 16/10/2017 12:41 AM, Peter Budai wrote: > >>>> > >>>>> A quick status update: > >>>>> > >>>>> * Hotspot successfully compiled without warnings > >>>>> * I?d like to run the unit tests, but as I see ?make check? > does > >>>>> not work, and gtestlauncher expects a command line parameter jdk. > Tried to > >>>>> look up some documentation on this, but have not found. So the > question is: > >>>>> how can I run unit tests for hotspot? Do I need also JDK compiled > for that? > >>>>> Or the bootJDK is good enough? Any help would be appreciated. > >>>>> > >>>> Hotspot has to be tested as part of a full JDK - you can't load the > JVM > >>>> without having the "J" part :) > >>>> > >>>> You should be able to drop your built dll into an existing JDK 9 > windows > >>>> JDK and test it that way. > >>>> > >>>> David > >>>> ----- > >>>> > >>>> * Also I?m making progress on compiling jdk, but there are some > >>>>> very interesting solutions on windows linking which makes a bit more > >>>>> difficult to compile with gcc: LIBS_windows contains sometimes simple > >>>>> library names (which I believe is correct) and other times library > names > >>>>> with full path (which I believe is not the best solution). I?m > trying to > >>>>> rework those places and use simple library names and passing search > path > >>>>> for libraries -L (for gcc toolchain) and /LIBPATH: (for > >>>>> Microsoft toolchain). Also I was surprised by a few manual function > name > >>>>> exports? > >>>>> * jdk code base contains apparently more MSVC specific part, > >>>>> many places casts/lack of casts are generating errors, static > attributes > >>>>> were missing etc. a bit tedious work. > >>>>> > >>>>> P. > >>>>> > >>>>> From: Erik Joelsson > >>>>> Sent: Wednesday, October 11, 2017 4:16 PM > >>>>> To: Magnus Ihse Bursie; Peter > >>>>> Budai > >>>>> Cc: build-dev at openjdk.java.net >>>>> > > >>>>> Subject: Re: Building OpenJDK9 on MSYS2 > >>>>> > >>>>> Hello, > >>>>> > >>>>> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: > >>>>> > >>>>> For gcc, we let the compiler generate the .d file. For the Microsoft > >>>>> tool chain, we use a clever sed script to extract and create it > ourself. > >>>>> > >>>>> I think that logic is checking for "Windows", not "Microsoft". That > >>>>> might be your cause of trouble. > >>>>> > >>>>> Look in NativeCompilation.gmk. > >>>>> > >>>>> That was my initial thought as well, but we do correctly check for > >>>>> microsoft. Also it's not the .d files that are the problem. As Peter > just > >>>>> wrote, they look fine. It's the .d.target files which we create > using the > >>>>> same technique on all platforms. What we don't account for is the > compiler > >>>>> putting Windows mixed paths in the .d files. > >>>>> > >>>>> /Magnus > >>>>> > >>>>> 11 okt. 2017 kl. 14:43 skrev Peter Budai >>>>> >: > >>>>> Hi Erik, > >>>>> > >>>>> The .d file looks like this: > >>>>> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser > >>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: \ > >>>>> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp > \ > >>>>> > >>>>> I have checked .d.targets file, and looks like it has the first line > >>>>> has not been deleted, and the file names below are also wrong: > >>>>> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-serve > >>>>> r-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj : : > >>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp : > >>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : > >>>>> > >>>>> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by > >>>>> the ?C:/? > >>>>> -e 's/^[^:]*: *//' > >>>>> > >>>>> Yes, that does indeed look like the problem. I suppose the regexp is > >>>>> unnecessarily strict. It should be ok to rewrite it as something > like this: > >>>>> -e 's/^.*: *//' > >>>>> > >>>>> Basically just make sure it ends with : and any number of spaces. > >>>>> > >>>>> /Erik > >>>>> > >>>>> > >>>>> > >>>>> Peter > >>>>> > >>>>> Sent from Mail for > >>>>> Windows 10 > >>>>> > >>>>> From: Erik Joelsson > >>>>> Sent: Wednesday, October 11, 2017 12:16 PM > >>>>> To: Peter Budai; Magnus Ihse > >>>>> Bursie; > >>>>> build-dev at openjdk.java.net > >>>>> build-dev at openjdk.java.net> > >>>>> Subject: Re: Building OpenJDK9 on MSYS2 > >>>>> > >>>>> > >>>>> Hello Peter, > >>>>> > >>>>> On 2017-10-11 00:18, Peter Budai wrote: > >>>>> Thanks Magnus & Erik > >>>>> > >>>>> First thanks for your support and kind words! > >>>>> > >>>>> Magnus, I have checked .bash_profile, .bashrc but they seem to be > >>>>> empty (everything is commented out). You can check with a default > MSYS2 > >>>>> install, I have not changed these files at all. If you find thee > something > >>>>> specific I can give a try here as well. > >>>>> > >>>>> Let me give also a quick status update, where am I with building > >>>>> hotspot: > >>>>> ? I guess its still the beginning, but I have managed to > compile > >>>>> jvm.dll with almost 700 object file: with debug info the dll is > around 700 > >>>>> MB ? > >>>>> ? I made only surgical, minimal changes to the source, and so > >>>>> far it looks reasonable. I have encountered 3 scenarios where > changes were > >>>>> necessary: > >>>>> o When in makefiles conditionals were using assuming that if > >>>>> target_os is windows then it is visual studio compiler/linker. > Obviously > >>>>> these conditionals had to be reviewed in a few places and if > necessary were > >>>>> changes to check the toolchain=Microsoft > >>>>> These are not surprising and should be pretty straight forward to fix > >>>>> and it seems you know what to do. > >>>>> > >>>>> > >>>>> ? > >>>>> o I got a few warnings as gcc 7.2 uncovered some code problems in > >>>>> windows specific codes, where before that MSVC I guess did not say a > word? > >>>>> To get around this you can configure with > --disable-warnings-as-errors > >>>>> until you get things working properly. This is commonly needed when > using > >>>>> compiler versions that we normally don't use. > >>>>> > >>>>> > >>>>> ? > >>>>> o And I had like 6-7 places where the code was using MSVC specific > >>>>> __try ? __except structures which gcc does not know. Do you have a > >>>>> suggestion how to approach them? I can do ugly #ifdefs (I would > avoid that) > >>>>> but I have also seen some solutions to replace them with a code > which gcc > >>>>> can compile (http://www.programmingunlimited.net/ > siteexec/content.cgi? > >>>>> page=mingw-seh ) ? but before doing that though I would ask first > >>>>> you on the purpose of those > >>>>> This kind of question is probably best to bring to the hotspot > mailing > >>>>> list. > >>>>> ? What bothers me is that I was not able to do incremental > >>>>> builds: when an error occurs, and build stops, then after making > change in > >>>>> the CPP source the build cannot continue, I always got an error > message: > >>>>> > >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser > >>>>> ver-release/hotspot/variant-server/tools/adlc/objs/ > adlparse.d.targets:1: > >>>>> *** missing target pattern. Stop. > >>>>> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 > >>>>> > >>>>> If I do a ?make clean? and restart the build then it nicely compiles. > >>>>> > >>>>> Question 1: Is there a way to resume such builds without ?make > clean?? > >>>>> Well, incremental builds is supposed to work well. We have several > >>>>> extra tricks in there to handle cases where normal make builds would > fail. > >>>>> The *.d.targets files is one such trick and it seems to backfire for > you. > >>>>> The contents of that file should be something like: > >>>>> > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : > >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : > >>>>> > >>>>> Basically an empty rule for each dependency for the corresponding > >>>>> object file. Declaring these rules makes it possible to delete > source files > >>>>> without having to build clean. It seems your file is not generated > >>>>> correctly so please have a look inside it. The file is in > >>>>> make/common/NativeCompilation.gmk, look for > >>>>> DEPENDENCY_TARGET_SED_PATTERN. > >>>>> > >>>>> > >>>>> > >>>>> Question 2: What would be the best way to submit/share the patches > for > >>>>> your thorough review? > >>>>> > >>>>> Well, first of all, have you signed the OCA? > >>>>> > >>>>> As for publishing patches and reviews, there is a bit of chicken and > >>>>> egg problem. Once you become an "author" in any of the OpenJDK > projects, > >>>>> you get a user name and should be able to publish reviews on > >>>>> cr.openjdk.java.net >>>>> penjdk.java.net >>>>> k.java.net/%3e%3chttp:/cr.openjdk.java.net%3chttp:/cr. > >>>>> openjdk.java.net/>>>. Before that, if the patch is small, it can be > >>>>> posted inline in an email to the list. If it's large, you will need a > >>>>> current OpenJDK user to host it for you. At least that's how I > understand > >>>>> it. Hopefully someone who knows the process better can chime in here. > >>>>> > >>>>> I should also let you know that getting this into JDK 9 is most > likely > >>>>> not going to happen. AFAIK we are only doing security updates for 9. > It > >>>>> would have to go into the currently active release. I should also > warn you > >>>>> that new ports generally need a certain amount of backing to be > accepted. > >>>>> It may be that this would have to live in a porting side project. > Hopefully > >>>>> someone who knows this better can chime in here as well. > >>>>> > >>>>> /Erik > >>>>> > >>>>> > >>>>> P. > >>>>> > >>>>> Sent from Mail for > >>>>> Windows 10 > >>>>> > >>>>> From: Magnus Ihse Bursie > >>>>> Sent: Tuesday, October 10, 2017 10:04 AM > >>>>> To: Peter Budai; Erik > Joelsson >>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>> build-dev at openjdk.java.net> > >>>>> Subject: Re: Building OpenJDK9 on MSYS2 > >>>>> > >>>>> On 2017-10-07 10:14, Peter Budai wrote: > >>>>> The configure of OpenJDK overwrites the SHELL. Actually it is using > >>>>> bash, but for the arguments it was using ?-e -o pipefail?. I have > figured > >>>>> that for MSYS2 bash what is needed as bash arguments is ?-e -l -c -o > >>>>> pipefail? > >>>>> > >>>>> That looks like solving this problem, and now the real issues are > >>>>> surfacing. > >>>>> > >>>>> FWIW, "-l" makes bash behave like a login shell. Most likely you are > >>>>> changing bash's behavior in one of your login scripts, and that > change is > >>>>> what's really needed. > >>>>> > >>>>> /Magnus > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> Peter > >>>>> > >>>>> From: Peter Budai > >>>>> Sent: Friday, October 6, 2017 6:43 PM > >>>>> To: Magnus Ihse Bursie; Erik > >>>>> Joelsson; > build-dev at openjdk.java.net > >>>>> openjdk.java.net> > >>>>> Subject: RE: Building OpenJDK9 on MSYS2 > >>>>> > >>>>> Magnus, > >>>>> > >>>>> I have followed your suggestion and removed the fixpath prefixes from > >>>>> gcc related compile tools, and left only the fixpath prefix _only_ > for the > >>>>> Boot JDK related tools in place. > >>>>> > >>>>> 1) As I follow the process, all java and javac related compile > >>>>> steps are running properly > >>>>> 2) When the process reaches gcc related steps I got the error > >>>>> message at the same place as before (no fixpath). If I execute that > command > >>>>> from the bash prompt, it creates the output: > >>>>> > >>>>> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' > >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes > >>>>> /sun/nio/ch/SocketOptionRegistry.java.template && > >>>>> /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/j > >>>>> dk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java. > template > >>>>> 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | > >>>>> /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e > 's/@@START_HERE@@/\/\/ > >>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e > 's/^#.*//' > >>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser > >>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption > >>>>> Registry.java > >>>>> > >>>>> As I have mentioned the parameters are replaced by the bash > >>>>> automatically > >>>>> 3) Then build continues, then little later stops at a super > >>>>> simple command: > >>>>> > >>>>> mv /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser > >>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp > >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser > >>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java > >>>>> Needless to say, the ByteBuffer.java.tmp file DOES > exist. > >>>>> And running the above command from the bash works, and build > continues. > >>>>> 4) A few similar cases (stops) with DirectByteBuffer and > >>>>> DirectByteBufferR > >>>>> > >>>>> > >>>>> Currently I try to explore how that might relate to the MSYS2 bash > and > >>>>> make, somehow it behaves differently > >>>>> > >>>>> If you have any other suggestion, let me know. > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Peter > >>>>> > >>>>> From: Peter Budai > >>>>> Sent: Thursday, October 5, 2017 3:52 PM > >>>>> To: Magnus Ihse Bursie; Erik > >>>>> Joelsson; > build-dev at openjdk.java.net > >>>>> openjdk.java.net> > >>>>> Subject: RE: Building OpenJDK9 on MSYS2 > >>>>> > >>>>> Hi Magnus, > >>>>> > >>>>> So first of all, here is the current patch, which I was not able to > >>>>> attach: https://pastebin.com/pwT4Ynxc > >>>>> > >>>>> That's surprising, since gcc is prefixed with fixpath, which it > should > >>>>>>> not. > >>>>>>> > >>>>>> Actually you DO need fixpath IMHO. > >>>>> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), > >>>>> which is a fully functional Windows executable, which expects Windows > >>>>> formatted path arguments. > >>>>> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see > >>>>> that patch), none of the command line arguments are converted from > the > >>>>> unix path to Windows, but fixpath does that conversion. There is a > wiki > >>>>> describing more details on this: > >>>>> https://github.com/msys2/msys2/wiki/Porting#user-content- > >>>>> filesystem-namespaces > >>>>> > >>>>> > >>>>> > >>>>> I have a hard time believing this is a race condition. On the other > >>>>>>> hand, this stuff is weird, we're misusing the C preprocessor to > process > >>>>>>> defines in java code, so I'm not surprised it breaks down. > >>>>>>> I don't know why it succeeded when run on the command line, though. > >>>>>>> > >>>>>> When I execute that command from the bash command line there is no > >>>>> EXPORT MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic > >>>>> conversion of the arguments. Maybe it has something to do how > fixpath does > >>>>> CreateProcess? > >>>>> > >>>>> Does that help? > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Peter > >>>>> > >>>>> Sent from Mail for > >>>>> Windows 10 > >>>>> > >>>>> From: Magnus Ihse Bursie > >>>>> Sent: Thursday, October 5, 2017 12:13 PM > >>>>> To: Peter Budai; Erik > Joelsson >>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net >>>>> build-dev at openjdk.java.net> > >>>>> Subject: Re: Building OpenJDK9 on MSYS2 > >>>>> > >>>>> > >>>>> On 2017-10-05 11:59, Peter Budai wrote: > >>>>> Hi Magnus and Erik, > >>>>> > >>>>> I really appreciate your quick feedback. I assumed that it won?t be > >>>>> easy, but I just don?t feel I should give up now - maybe later when > I see > >>>>> the real scale of work. So bear with me for a time being. > >>>>> > >>>>> Attached is a patch which already includes Magnus? changes, plus a > few > >>>>> which I have added: > >>>>> ? basically enabling gcc for windows, > >>>>> ? and modifying a logic for compiling fixpath (before that it > >>>>> was using hard-coded MS VSC compile flags) > >>>>> > >>>>> Actually, you must make sure fixpath is *not* used for the toolchain, > >>>>> since gcc uses unix style paths. > >>>>> (However, other tools such as java will still need it.) > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> So here is what I have as the result of configure: > >>>>> ==================================================== > >>>>> The existing configuration has been successfully updated in > >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser > >>>>> ver-release > >>>>> using configure arguments '--disable-freetype-bundling > >>>>> --disable-javac-server'. > >>>>> > >>>>> Configuration summary: > >>>>> * Debug level: release > >>>>> * HS debug level: product > >>>>> * JDK variant: normal > >>>>> * JVM variants: server > >>>>> * OpenJDK target: OS: windows, CPU architecture: x86, address length: > >>>>> 64 > >>>>> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) > >>>>> > >>>>> Tools summary: > >>>>> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) > >>>>> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime > >>>>> Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM > (build > >>>>> 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) > >>>>> * Toolchain: gcc (GNU Compiler Collection) > >>>>> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) > >>>>> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) > >>>>> > >>>>> Build performance summary: > >>>>> * Cores to use: 4 > >>>>> * Memory limit: 16216 MB > >>>>> > >>>>> Its clear says that the toolchain is gcc 7.2 (BTW there is no Visual > >>>>> Studio on this machine) > >>>>> > >>>>> Now for the details of the config log, you can see here: > >>>>> https://pastebin.com/MN2ZYcHH > >>>>> > >>>>> And about the build process and the error I get: > >>>>> > >>>>> $ make JOBS=1 > >>>>> Building target 'default (exploded-image)' in configuration > >>>>> 'windows-x86_64-normal-server-release' > >>>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS > >>>>> Compiling 17 properties into resource bundles for jdk.compiler > >>>>> Parsing 1 properties into enum-like class for jdk.compiler > >>>>> Compiling 19 properties into resource bundles for jdk.javadoc > >>>>> Compiling 12 properties into resource bundles for jdk.jdeps > >>>>> Compiling 7 properties into resource bundles for jdk.jshell > >>>>> Compiling 117 files for BUILD_INTERIM_java.compiler > >>>>> Compiling 396 files for BUILD_INTERIM_jdk.compiler > >>>>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps > >>>>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc > >>>>> Note: Some input files use or override a deprecated API. > >>>>> Note: Recompile with -Xlint:deprecation for details. > >>>>> Compiling 159 files for BUILD_TOOLS_JDK > >>>>> Note: Some input files use unchecked or unsafe operations. > >>>>> Note: Recompile with -Xlint:unchecked for details. > >>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b > >>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav > >>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 > >>>>> make[3]: *** Deleting file '/C/msys64/home/peterbud/jdk9/ > >>>>> build/windows-x86_64-normal-server-release/support/gensrc/ja > >>>>> va.base/sun/nio/ch/SocketOptionRegistry.java' > >>>>> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 > >>>>> > >>>>> ERROR: Build failed for target 'default (exploded-image)' in > >>>>> configuration 'windows-x86_64-normal-server-release' (exit code 2) > >>>>> > >>>>> No indication of failed target found. > >>>>> Hint: Try searching the build log for '] Error'. > >>>>> Hint: See common/doc/building.html#troubleshooting for assistance. > >>>>> > >>>>> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 > >>>>> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 > >>>>> > >>>>> If I run here > >>>>> make JOBS=1 LOG=debug > >>>>> The failing line seems to be this: > >>>>> > >>>>> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' > >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes > >>>>> /sun/nio/ch/SocketOptionRegistry.java.template && > >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser > >>>>> ver-release/configure-support/bin/fixpath.exe > >>>>> -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x c > >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes > >>>>> /sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep -v > >>>>> '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk > >>>>> '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ > >>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e > 's/^#.*//' > >>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser > >>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption > >>>>> Registry.java > >>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b > >>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav > >>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 > >>>>> > >>>>> Now the interesting is: if I copy this line above to the bash prompt, > >>>>> it runs without problem, and the file support/gensrc/java.base/sun/n > >>>>> io/ch/SocketOptionRegistry.java > >>>>> That's surprising, since gcc is prefixed with fixpath, which it > should > >>>>> not. > >>>>> > >>>>> I have a hard time believing this is a race condition. On the other > >>>>> hand, this stuff is weird, we're misusing the C preprocessor to > process > >>>>> defines in java code, so I'm not suprised it breaks down. I don't > know why > >>>>> it succeeded when run on the command line, though. My suggestion is > to just > >>>>> do some quick and dirty hack around this: take the file you manage to > >>>>> generate and just copy it in during the build instead. If you can > get round > >>>>> this, you might start seeing some *real* problems. :-) > >>>>> > >>>>> Also, my suggestion is that you try running "make hotspot" to cut to > >>>>> the chase. Compiling hotspot will likely be the hardest thing. Or > even > >>>>> "make -k hotspot" to get an assessment of the amount of work ahead > of you. > >>>>> > >>>>> /Magnus > >>>>> Is produced. > >>>>> > >>>>> Then I can again issue > >>>>> make JOBS=1 LOG=debug > >>>>> > >>>>> And the compile process is being continued, until a similar error > pops > >>>>> up with a different generated file. I have an assumption that this > happens > >>>>> because make is still running parallel jobs, despite JOBS=1 but I?m > not > >>>>> sure. > >>>>> > >>>>> How could I best tackle this? > >>>>> > >>>>> Thank you and best regards, > >>>>> > >>>>> Peter > >>>>> > >>>>> Sent from Mail for > >>>>> Windows 10 > >>>>> > >>>>> From: Magnus Ihse Bursie > >>>>> Sent: Thursday, October 5, 2017 11:33 AM > >>>>> To: Erik Joelsson; Peter > >>>>> Budai; build-dev at openjdk.java.net >>>>> lto:build-dev at openjdk.java.net> > >>>>> Subject: Re: Building OpenJDK9 on MSYS2 > >>>>> > >>>>> On 2017-10-05 10:10, Erik Joelsson wrote: > >>>>> > >>>>>> Hello Peter, > >>>>>> > >>>>>> > >>>>>> On 2017-10-04 21:15, Peter Budai wrote: > >>>>>> > >>>>>>> Hi Magnus, > >>>>>>> > >>>>>>> Thanks for the quick reply I?ll check these patches with msys2. > >>>>>>> > >>>>>>> Let me specify with more details what I?d like to achieve: I?d like > >>>>>>> to build OpenJDK9 with MSYS2 MINGW64 environment using gcc > toolchain. > >>>>>>> (I?m not sure how familiar are you with MSYS2, but there are 3 > >>>>>>> different environments: MSYS2, MINGW32 and MINGW64). In theory > >>>>>>> MINGW64 with gcc is the closes you can get on Windows platform as a > >>>>>>> gcc unix like build environment, which produces still a native > 64-bit > >>>>>>> executable on Windows. > >>>>>>> > >>>>>>> I?m not very familiar with OpenJDK yet, so therefore I?d like to > hear > >>>>>>> your opinion: how realistic is that? > >>>>>>> > >>>>>> Sorry to disappoint, but I would say that requires major work. There > >>>>>> is a strong historic assumption that windows builds are done using > >>>>>> Visual Studio. We have abstracted away some of it in configure (see > >>>>>> TOOLCHAIN_TYPE), but it's very far from enough to change compiler > >>>>>> environment for a Windows build. The native sources are also bound > to > >>>>>> make a lot of such assumptions. I would expect the changes needed to > >>>>>> be in the thousands of lines of code. > >>>>>> > >>>>> I agree that it requires hard work (even if "thousands" might be an > >>>>> overestimation I think, but "hundreds" is not enough, so it's the > right > >>>>> magnitude). On the other hand, it would be really good if we did sort > >>>>> things out, so that we had proper conditions based on OS vs > >>>>> compiler/toolchain. > >>>>> > >>>>> If you really want to start, the first thing is to patch toolchain.m4 > >>>>> to > >>>>> VALID_TOOLCHAINS_windows="microsoft gcc" > >>>>> and then call configure using "bash configure > >>>>> --with-toolchain-type=gcc". > >>>>> > >>>>> As Erik, I doubt you will come very far before things starts tumbling > >>>>> down. > >>>>> > >>>>> When we say supporting the build in msys2 instead of cygwin, we just > >>>>>> mean using msys2 as the unix emulating layer for our tools like > >>>>>> make/bash/grep/sed etc. > >>>>>> > >>>>>> One think I have done successfully is running the build in WSL > >>>>>> (Windows Subsystem for Linux), but that isn't all that helpful as > WSL > >>>>>> for practical purposes is more or less like running Linux in a VM, > so > >>>>>> the build sees a Linux system and builds a Linux binary. > >>>>>> > >>>>>>> As a side note: with MINGW64 I have managed to run configure phase > >>>>>>> successfully for OpenJDK. The compile process has also started and > >>>>>>> went for a while, but interestingly I run into some kind of race > >>>>>>> conditions as make stopped with an error. Using LOG=debug I have > fond > >>>>>>> the failing line and then copying the failed command and pasting it > >>>>>>> to the bash prompt it successfully generated the output target, and > >>>>>>> then the build process run further when a similar situation > happened. > >>>>>>> Also pasting the failed command run in the bash without any > problem, > >>>>>>> and build continued? until the next. > >>>>>>> > >>>>>> Without seeing the errors I can't say much. I very much doubt that > you > >>>>>> are running with gcc as the compiler though. Configure isn't easily > >>>>>> fooled into using a different compiler to what it prefers, and I > would > >>>>>> expect things to crash and burn pretty early if you actually did. > >>>>>> > >>>>>> /Erik > >>>>>> > >>>>>>> I have tried to run make JOBS=1, but did not help, strangely I have > >>>>>>> still seen in the log make[3] and make[4] logs which suggested that > >>>>>>> there are more than one make jobs were running. Also tried > .configure > >>>>>>> --with-output-sync=recurse without success (same symptoms) > >>>>>>> > >>>>>>> Let me know your thoughts. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> > >>>>>>> Peter > >>>>>>> > >>>>>>> Sent from Mail for > >>>>>>> Windows 10 > >>>>>>> > >>>>>>> From: Magnus Ihse Bursie > >>>>>>> Sent: Wednesday, October 4, 2017 1:04 AM > >>>>>>> To: Peter Budai; > >>>>>>> build-dev at openjdk.java.net >>>>>>> > >>>>>>> k.java.net> > >>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 > >>>>>>> > >>>>>>> Actually, it wasn't so much remaining trouble. :-) I fired up msys2 > >>>>>>> and > >>>>>>> checked out where I left off. It turned out that the remaining snag > >>>>>>> was > >>>>>>> that msys2 tries to convert command lines automatically, from > "unix" > >>>>>>> style paths to "windows" style paths. Unfortunately, it does not do > >>>>>>> this > >>>>>>> very well and it breaks all sorts of things. We already have a > >>>>>>> FIXPATH > >>>>>>> solution in place which deals with this, so basically all I had to > do > >>>>>>> was disable this (by setting MSYS2_ARG_CONV_EXCL to "*"). However, > >>>>>>> this > >>>>>>> broke our cygpath replacement hack (!) so I had to disable it > there. > >>>>>>> Sigh. Anyway, with those fixes it ran and worked well. (I also > >>>>>>> discovered and fixed a bug related to how we set up the FIXPATH > >>>>>>> variable > >>>>>>> on msys, but it only triggers in certain circumstances). > >>>>>>> > >>>>>>> With this patch I now jdk9 seems to build fine on msys2. It should > >>>>>>> apply > >>>>>>> cleanly on jdk9/jdk9. Since it turned out to be so trivial, I'll > try > >>>>>>> to > >>>>>>> get it in in jdk10. > >>>>>>> > >>>>>>> Here's the patch if you want to apply it yourself: > >>>>>>> > >>>>>>> diff -r a08cbfc0e4ec common/autoconf/basics_windows.m4 > >>>>>>> --- a/common/autoconf/basics_windows.m4 Thu Aug 03 18:56:56 > 2017 > >>>>>>> +0000 > >>>>>>> +++ b/common/autoconf/basics_windows.m4 Wed Oct 04 00:53:58 > 2017 > >>>>>>> +0200 > >>>>>>> @@ -42,7 +42,7 @@ > >>>>>>> windows_path=`$CYGPATH -m "$unix_path"` > >>>>>>> $1="$windows_path" > >>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then > >>>>>>> - windows_path=`cmd //c echo $unix_path` > >>>>>>> + windows_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $unix_path` > >>>>>>> $1="$windows_path" > >>>>>>> fi > >>>>>>> ]) > >>>>>>> @@ -136,6 +136,16 @@ > >>>>>>> fi > >>>>>>> ]) > >>>>>>> > >>>>>>> +AC_DEFUN([BASIC_MSYS_UPDATE_FIXPATH], > >>>>>>> +[ > >>>>>>> + # Take all collected prefixes and turn them into a > >>>>>>> -m/c/foo@/c/bar at ... command line > >>>>>>> + # @ was chosen as separator to minimize risk of other tools > >>>>>>> messing > >>>>>>> around with it > >>>>>>> + all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ > >>>>>>> + | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` > >>>>>>> + fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` > >>>>>>> + FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" > >>>>>>> +]) > >>>>>>> + > >>>>>>> AC_DEFUN([BASIC_FIXUP_PATH_MSYS], > >>>>>>> [ > >>>>>>> path="[$]$1" > >>>>>>> @@ -143,7 +153,7 @@ > >>>>>>> new_path="$path" > >>>>>>> if test "x$has_colon" = x; then > >>>>>>> # Not in mixed or Windows style, start by that. > >>>>>>> - new_path=`cmd //c echo $path` > >>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $path` > >>>>>>> fi > >>>>>>> > >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) > >>>>>>> @@ -155,6 +165,8 @@ > >>>>>>> > >>>>>>> # Save the first 10 bytes of this path to the storage, so > >>>>>>> fixpath > >>>>>>> can work. > >>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" > >>>>>>> "${new_path:0:10}") > >>>>>>> + # We might need to re-evaluate FIXPATH. > >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH > >>>>>>> ]) > >>>>>>> > >>>>>>> AC_DEFUN([BASIC_FIXUP_EXECUTABLE_CYGWIN], > >>>>>>> @@ -293,7 +305,7 @@ > >>>>>>> # Do not save /bin paths to all_fixpath_prefixes! > >>>>>>> else > >>>>>>> # Not in mixed or Windows style, start by that. > >>>>>>> - new_path=`cmd //c echo $new_path` > >>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $new_path` > >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) > >>>>>>> # Output is in $new_path > >>>>>>> BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(new_path) > >>>>>>> @@ -302,6 +314,8 @@ > >>>>>>> > >>>>>>> # Save the first 10 bytes of this path to the storage, so > >>>>>>> fixpath > >>>>>>> can work. > >>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" > >>>>>>> "${new_path:0:10}") > >>>>>>> + # We might need to re-evaluate FIXPATH. > >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH > >>>>>>> fi > >>>>>>> ]) > >>>>>>> > >>>>>>> @@ -347,6 +361,10 @@ > >>>>>>> WINDOWS_ENV_VENDOR='msys' > >>>>>>> WINDOWS_ENV_VERSION="$MSYS_VERSION" > >>>>>>> > >>>>>>> + # Prohibit msys2 path conversion from trying to be > >>>>>>> "intelligent", > >>>>>>> and rely > >>>>>>> + # on fixpath instead. > >>>>>>> + export MSYS2_ARG_CONV_EXCL="*" > >>>>>>> + > >>>>>>> AC_MSG_CHECKING([msys root directory as unix-style path]) > >>>>>>> # The cmd output ends with Windows line endings (CR/LF), > >>>>>>> the grep > >>>>>>> command will strip that away > >>>>>>> MSYS_ROOT_PATH=`cd / ; cmd /c cd | $GREP ".*"` > >>>>>>> @@ -391,10 +409,7 @@ > >>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.msys; then > >>>>>>> # Take all collected prefixes and turn them into a > >>>>>>> -m/c/foo@/c/bar at ... command line > >>>>>>> # @ was chosen as separator to minimize risk of other > >>>>>>> tools > >>>>>>> messing around with it > >>>>>>> - all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@: > >@}" > >>>>>>> \ > >>>>>>> - | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` > >>>>>>> - fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' > >>>>>>> '@'` > >>>>>>> - FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" > >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH > >>>>>>> fi > >>>>>>> FIXPATH_SRC_W="$FIXPATH_SRC" > >>>>>>> FIXPATH_BIN_W="$FIXPATH_BIN" > >>>>>>> diff -r a08cbfc0e4ec common/autoconf/build-aux/config.sub > >>>>>>> --- a/common/autoconf/build-aux/config.sub Thu Aug 03 18:56:56 > >>>>>>> 2017 +0000 > >>>>>>> +++ b/common/autoconf/build-aux/config.sub Wed Oct 04 00:53:58 > >>>>>>> 2017 +0200 > >>>>>>> @@ -30,7 +30,7 @@ > >>>>>>> DIR=`dirname $0` > >>>>>>> > >>>>>>> # First, filter out everything that doesn't begin with > >>>>>>> "aarch64-" > >>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then > >>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then > >>>>>>> . $DIR/autoconf-config.sub "$@" > >>>>>>> # autoconf-config.sub exits, so we never reach here, but > >>>>>>> just in > >>>>>>> # case we do: > >>>>>>> @@ -38,13 +38,17 @@ > >>>>>>> fi > >>>>>>> > >>>>>>> while test $# -gt 0 ; do > >>>>>>> - case $1 in > >>>>>>> + case $1 in > >>>>>>> -- ) # Stop option processing > >>>>>>> shift; break ;; > >>>>>>> aarch64-* ) > >>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` > >>>>>>> sub_args="$sub_args $config" > >>>>>>> shift; ;; > >>>>>>> + *-msys ) > >>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` > >>>>>>> + sub_args="$sub_args $config" > >>>>>>> + shift; ;; > >>>>>>> - ) # Use stdin as input. > >>>>>>> sub_args="$sub_args $1" > >>>>>>> shift; break ;; > >>>>>>> diff -r a08cbfc0e4ec common/autoconf/spec.gmk.in > >>>>>>> --- a/common/autoconf/spec.gmk.in Thu Aug 03 18:56:56 2017 > +0000 > >>>>>>> +++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 > +0200 > >>>>>>> @@ -120,6 +120,13 @@ > >>>>>>> # On Windows, the Visual Studio toolchain needs the PATH to > be > >>>>>>> adjusted > >>>>>>> # to include Visual Studio tools (this needs to be in > >>>>>>> cygwin/msys > >>>>>>> style). > >>>>>>> export PATH:=@VS_PATH@ > >>>>>>> + > >>>>>>> +endif > >>>>>>> + > >>>>>>> +ifeq ($(OPENJDK_TARGET_OS_ENV), windows.msys) > >>>>>>> + # On msys2, prohibit msys path conversion from trying to be > >>>>>>> + # "intelligent", and rely on fixpath instead. > >>>>>>> + export MSYS2_ARG_CONV_EXCL:=* > >>>>>>> endif > >>>>>>> > >>>>>>> SYSROOT_CFLAGS := @SYSROOT_CFLAGS@ > >>>>>>> > >>>>>>> /Magnus > >>>>>>> > >>>>>>> On 2017-10-03 22:34, Magnus Ihse Bursie wrote: > >>>>>>> > >>>>>>>> I gave msys2 a shot some time ago, but it ended up too much > trouble. > >>>>>>>> I'll share some of my notes from that attempt, for what it's > worth. > >>>>>>>> > >>>>>>>> To install package X/Y, run "pacman -S X/Y". Missing tools and > >>>>>>>> packages where to find them: > >>>>>>>> cmp: msys/diffutils > >>>>>>>> tar: msys/tar > >>>>>>>> make: msys/make > >>>>>>>> unzip: msys/unzip > >>>>>>>> zip: msys/zip > >>>>>>>> > >>>>>>>> config.sub reports msys as "x86_64-pc-mingw32" but msys2 as > >>>>>>>> "x86_64-pc-msys". This patch adds postprocessing in "our" > config.sub > >>>>>>>> to report msys2 similar to msys. (Opinions, including my own :-) > may > >>>>>>>> vary if this really is the best way..) > >>>>>>>> > >>>>>>>> diff -r b88023f46daa common/autoconf/build-aux/config.sub > >>>>>>>> --- a/common/autoconf/build-aux/config.sub Fri Jan 27 > 10:15:41 > >>>>>>>> 2017 +0100 > >>>>>>>> +++ b/common/autoconf/build-aux/config.sub Fri Feb 03 > 05:00:25 > >>>>>>>> 2017 -0700 > >>>>>>>> @@ -30,7 +30,7 @@ > >>>>>>>> DIR=`dirname $0` > >>>>>>>> > >>>>>>>> # First, filter out everything that doesn't begin with > >>>>>>>> "aarch64-" > >>>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then > >>>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then > >>>>>>>> . $DIR/autoconf-config.sub "$@" > >>>>>>>> # autoconf-config.sub exits, so we never reach here, but > >>>>>>>> just in > >>>>>>>> # case we do: > >>>>>>>> @@ -45,6 +45,10 @@ > >>>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` > >>>>>>>> sub_args="$sub_args $config" > >>>>>>>> shift; ;; > >>>>>>>> + *-msys ) > >>>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` > >>>>>>>> + sub_args="$sub_args $config" > >>>>>>>> + shift; ;; > >>>>>>>> - ) # Use stdin as input. > >>>>>>>> sub_args="$sub_args $1" > >>>>>>>> shift; break ;; > >>>>>>>> > >>>>>>>> If I remember correctly, this got me past the configure stage at > the > >>>>>>>> time. > >>>>>>>> > >>>>>>>> I don't think it's very hard to get it to work on msys2, I just > ran > >>>>>>>> into one snag too many and didn't think msys2 would be used by > >>>>>>>> anyone. > >>>>>>>> > >>>>>>>> /Magnus > >>>>>>>> > >>>>>>>> On 2017-10-03 17:20, Peter Budai wrote: > >>>>>>>> > >>>>>>>>> Hello, > >>>>>>>>> > >>>>>>>>> According to > >>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/commo > >>>>>>>>> n/doc/building.html > >>>>>>>>> > >>>>>>>>> ?msys2 and the new Windows Subsystem for Linux (WSL) would likely > >>>>>>>>> be > >>>>>>>>> possible to support in a future version but that would require a > >>>>>>>>> community effort to implement? > >>>>>>>>> > >>>>>>>>> I?d like to help making the OpenJDK 9 build working on msys2. > What > >>>>>>>>> is > >>>>>>>>> the best way to move forward? Is there a similar effort in > >>>>>>>>> progress? > >>>>>>>>> > >>>>>>>>> Thank you and best regards, > >>>>>>>>> > >>>>>>>>> Peter > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>>>> > >>> > >>> > > > From magnus.ihse.bursie at oracle.com Fri Nov 24 08:23:01 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 24 Nov 2017 09:23:01 +0100 Subject: RFR: JDK-8191820 run-test jtreg test selection and component calculation broken since consolidation In-Reply-To: <6b16dea0-cfea-0f9a-e26a-5902be3faac7@oracle.com> References: <3319993c-7364-40f3-0fdc-dd3650dbbe17@oracle.com> <6b16dea0-cfea-0f9a-e26a-5902be3faac7@oracle.com> Message-ID: On 2017-11-23 17:17, Erik Joelsson wrote: > Looks good, except for the indentation of the value for $1_COMPONENT. Oops. Fixed. > It's really a shame that you can't add comments inside the big blocks > of functional logic. It sure would help in understanding what each sub > block was trying to achieve. Yes, it is. :( I spent some time trying to understand the previous code. Even though it was written by myself... for less then a year ago. :-& I tried to tackle this somewhat by breaking out functionality in functions with descriptive names. /Magnus > > /Erik > > > On 2017-11-23 06:20, Magnus Ihse Bursie wrote: >> The test selection and component calculation for jtreg tests have >> been broken since the consolidated and restructured forest. >> >> This fix will restore component calculation (which solves issues with >> incorrect component-specific settings, such as nativepath). It also >> allows for a more flexible test selection mechanism, better suited to >> the new test structure, while at the same time cleaning up at least a >> bit of the almost incomprehensible make function. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191820 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8191820-fix-jtreg-test-selection/webrev.01 >> >> /Magnus > From magnus.ihse.bursie at oracle.com Fri Nov 24 08:48:27 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 24 Nov 2017 09:48:27 +0100 Subject: RFR: JDK-8191205 Set native-debug-symbols default to "external" In-Reply-To: References: <817a65bc-0d1d-b331-e38d-ef896f3a1b70@oracle.com> <6710d591-74d4-77f0-60e8-305cec0ee75a@oracle.com> Message-ID: On 2017-11-23 16:56, Erik Joelsson wrote: > I'm pretty sure it has worked at some point because I wrote that dSYM > logic and must have tested it locally at least, but it does seem weird. Sorry, I expressed myself a bit to sweeping there. Yes, obviously it has worked at some point, when you wrote it. But it has not worked for quite some time. When I introduced the --with-native-debug-symbols option, I standardized the naming of the make variables that govern debug symbol generation. Somehow I must have missed renaming the variables in Bundles.gmk. (Or it's some later merge issue causing old variables to be resurrected.) I've grepped for ZIP_DEBUGINFO_FILES now anyway, and couldn't find any other places where it's still left. /Magnus > Anyway, fix looks good, given that you have actually tried it and > checked the bundle contents. (no dSYM in jdk/jre, and all of them in > the symbols bundles) > > /Erik > > > On 2017-11-23 04:21, Magnus Ihse Bursie wrote: >> It turned out that macos bundles does not work correctly with >> external, non-zipped debug symbols. :-( This has probably never been >> tested before. This additional patch is also needed: >> >> diff --git a/make/Bundles.gmk b/make/Bundles.gmk >> --- a/make/Bundles.gmk >> +++ b/make/Bundles.gmk >> @@ -177,7 +177,7 @@ >> ?? # Create special filter rules when dealing with unzipped .dSYM >> directories on >> ?? # macosx >> ?? ifeq ($(OPENJDK_TARGET_OS), macosx) >> -??? ifeq ($(ZIP_DEBUGINFO_FILES), false) >> +??? ifeq ($(ZIP_EXTERNAL_DEBUG_SYMBOLS), false) >> ?????? JDK_SYMBOLS_EXCLUDE_PATTERN := $(addprefix %, \ >> ?????????? $(call containing, .dSYM/, $(patsubst $(JDK_IMAGE_DIR)/%, >> %, $(ALL_JDK_FILES)))) >> ???? endif >> @@ -212,7 +212,7 @@ >> ?? # Create special filter rules when dealing with unzipped .dSYM >> directories on >> ?? # macosx >> ?? ifeq ($(OPENJDK_TARGET_OS), macosx) >> -??? ifeq ($(ZIP_DEBUGINFO_FILES), false) >> +??? ifeq ($(ZIP_EXTERNAL_DEBUG_SYMBOLS), false) >> ?????? JRE_SYMBOLS_EXCLUDE_PATTERN := $(addprefix %, \ >> ?????????? $(call containing, .dSYM/, $(patsubst $(JRE_IMAGE_DIR)/%, >> %, $(ALL_JRE_FILES)))) >> ???? endif >> >> /Magnus >> >> On 2017-11-22 15:01, Magnus Ihse Bursie wrote: >>> We should not have "zipped" as default for native-debug-symbols. In >>> the future, this option should probably be dropped completely, but >>> for now, start by not making it default. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191205 >>> Patch inline: >>> diff --git a/make/autoconf/jdk-options.m4 >>> b/make/autoconf/jdk-options.m4 >>> --- a/make/autoconf/jdk-options.m4 >>> +++ b/make/autoconf/jdk-options.m4 >>> @@ -296,13 +296,13 @@ >>> ?????? ], >>> ?????? [ >>> ???????? if test "x$OPENJDK_TARGET_OS" = xaix; then >>> -????????? # AIX doesn't support 'zipped' so use 'internal' as default >>> +????????? # AIX doesn't support 'external' so use 'internal' as >>> default >>> ?????????? with_native_debug_symbols="internal" >>> ???????? else >>> ?????????? if test "x$STATIC_BUILD" = xtrue; then >>> ???????????? with_native_debug_symbols="none" >>> ?????????? else >>> -??????????? with_native_debug_symbols="zipped" >>> +??????????? with_native_debug_symbols="external" >>> ?????????? fi >>> ???????? fi >>> ?????? ]) >>> >>> /Magnus >> > From magnus.ihse.bursie at oracle.com Fri Nov 24 09:28:27 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 24 Nov 2017 10:28:27 +0100 Subject: RFR: JDK-8177957 run-test summary lines look bad/misleading with long test names Message-ID: <47bd3693-1dd8-2a18-60c5-1368669913f0@oracle.com> When running individual tests using run-test, the summary section gets hard to read. For instance: (imagine having a fixed-with font :)) ???TEST TOTAL PASS FAIL ERROR ???jtreg:hotspot/test/gc/stress/gcbasher/TestGCBasherWithG1.java 1 1 0 0 What makes this exact example even worse is that it aligns so bad so that the "1" belonging to the TOTAL column, ends up aligned with the FAIL label, so it looks as if the test failed. If the test name is too long to fit before the number columns, we should add a line break, so the numbers still align on the right columns, but on the line after. This bug also fixes some remaining issues from JDK-8191820: * jtreg test descriptors are now normalized to TOPDIR (or CUSTOM_ROOT, if present). (Without this fix, almost all test names were too long.) * Do not disallow running named test groups for jtreg tests out-of-tree. * And a simplification in the matching for paths (we didn't need to treat absolute paths differently). Bug: https://bugs.openjdk.java.net/browse/JDK-8177957 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8177957-linebreak-long-test-names/webrev.01 /Magnus From ted at tedneward.com Fri Nov 24 09:42:42 2017 From: ted at tedneward.com (Ted Neward) Date: Fri, 24 Nov 2017 01:42:42 -0800 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> <75BFB179-26B4-4551-92FA-A46D07AE6F0F@tedneward.com> <1c9a5e6c-8453-c71f-d10b-f2ee37094307@oracle.com> <40a67107-53d2-8a5a-c1bc-7924acadd07f@oracle.com> Message-ID: <569AD62D-3E86-4B90-AC54-D9D4E10E819C@tedneward.com> Changing it up just a touch?. I got it to build fine inside of Ubuntu 16 (and, just for kicks, Kubuntu, since I prefer KDE as a GUI) without flaw. But when I try to do it in a Docker image, I get a weird configure error: ?Could not find cpio!? Googling around reveals that cpio (as far as apt packaging is concerned) is replaced by tar, which is definitely in the image. And I didn?t run into this problem when I was doing in a real VM (as opposed to Docker), so I?m a little surprised by all this. On top of that, I just got an OpenJDK 9 image to build fine inside of Docker right before I started to do the same for 8. So?. Any thoughts? BTW, if you want to have a look at the Dockerfiles, they?re at https://bitbucket.org/TedNeward/docker . (I put all the images that aren?t part of applications or platforms into this one repo. I find it easier to keep track of them that way for demos and stuff.) They?re in openjdk8 and openjdk9, respectively. Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 11/23/17, 3:36 AM, "build-dev on behalf of Ted Neward" wrote: That is just Byzantine enough to be true. :-) I had a feeling the answer was going to be something along the lines of ?Reasons?and backwards compatibility reasons? or so, and that pretty neatly fits into that category, so?. Got it. :-) Thanks! Downloading source now and trying again. (I knew it had to be something stupidly simple on my end.) Ted Neward Author, Speaker, Mentor http://www.newardassociates.com t: @tedneward | m: (425) 647-4526 On 11/23/17, 3:31 AM, "dalibor topic" wrote: On 23.11.2017 12:25, Ted Neward wrote: > OK, so it?s still at java.net; that?s good to know. :-) > > Out of curiosity, though, what?s the difference? Why maintain two? jdk8/jdk8 is the 'historic' source code 'archive' for the development of JDK 8. JDK 8u is what happened since in the updates. JDK Release Projects like JDK 8 have a special status in Bylaws (see http://openjdk.java.net/bylaws#jdk-release-projects) while 'regular' Projects like JDK 8 Updates do not. So updates end up being separate Projects with separate repos. Well ... you asked. ;) cheers, dalibor topic > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:21 AM, "dalibor topic" wrote: > > hg clone http://hg.openjdk.java.net/jdk8u/jdk8u/ and then bash > get_source.sh within jdk8u directory. > > cheers, > dalibor topic > > On 23.11.2017 12:15, Ted Neward wrote: > > Save me a Google and remind me where that repo URL is? :-) > > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 3:14 AM, "dalibor topic" wrote: > > > > Probably - jdk8/jdk8 is the GA source code from a few years ago. > > jdk8u/jdk8u is the latest JDK 8 updates. > > > > cheers, > > dalibor topic > > > > On 23.11.2017 12:12, Ted Neward wrote: > > > Errr?.. What?s the difference, again? > > > > > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > > > > > Ted Neward > > > Author, Speaker, Mentor > > > http://www.newardassociates.com > > > t: @tedneward | m: (425) 647-4526 > > > > > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > > > > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > > > > > cheers, > > > dalibor topic > > > > > > On 23.11.2017 11:50, Ted Neward wrote: > > > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > > > > > Hi Ted! > > > > > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > > > I should go to get the fix? > > > > > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > > > on Ubuntu. > > > > > > > > Please also make sure you have the necessary build dependencies installed: > > > > > > > > # apt build-dep openjdk-8 > > > > > > > > Adrian > > > > > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > > > > > -- > > > > .''`. John Paul Adrian Glaubitz > > > > : :' : Debian Developer - glaubitz at debian.org > > > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > > > > > > > > > > > -- > > > Dalibor Topic | Principal Product Manager > > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > > > ORACLE Deutschland B.V. & Co. KG > > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > > > Oracle is committed to developing > > > practices and products that help protect the environment > > > > > > > > > > > > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From magnus.ihse.bursie at oracle.com Fri Nov 24 10:14:07 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 24 Nov 2017 11:14:07 +0100 Subject: RFR: JDK-8179554 make run-test does not respect ProblemList.txt Message-ID: When running tests with `make run-test`, tests from jdk/test/ProblemList.txt and/or hotspot/test/ProblemList.txt aren't excluded. Bug: https://bugs.openjdk.java.net/browse/JDK-8179554 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8179554-run-test-should-respect-problem-list/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Nov 24 10:22:13 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 24 Nov 2017 11:22:13 +0100 Subject: RFR: JDK-8189099 JTReg now supports 256 jobs Message-ID: <8916640d-f219-3b22-04d0-b6e9f36485c4@oracle.com> From the bug report: "According to research by Jonathan Gibbons , JTReg now supports 256 jobs, in contrast to the older limit of 50 jobs. This limit is enforced in the make files, and it should be updated to reflect the new limit (or the check removed entirely)." I choose to remove the check. If you send in more than JOBS=256, then JTReg will complain. If that limit is ever increased, it should only be done so in JTReg, not also in the makefiles. Bug: https://bugs.openjdk.java.net/browse/JDK-8189099 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8189099-remove-jtreg-job-limit-of-50/webrev.01 /Magnus From magnus.ihse.bursie at oracle.com Fri Nov 24 10:23:19 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 24 Nov 2017 11:23:19 +0100 Subject: RFR: JDK-8179555 make run-test should always use a fresh, clean JTwork directory Message-ID: When running jtreg tests, make run-test should always run with a fresh, clean JTwork directory in order to avoid issues with code not being recompiled. Bug: https://bugs.openjdk.java.net/browse/JDK-8179555 Patch inline: diff --git a/make/RunTests.gmk b/make/RunTests.gmk --- a/make/RunTests.gmk +++ b/make/RunTests.gmk @@ -407,7 +407,10 @@ ???? $1_JTREG_BASIC_OPTIONS += -cpa:$$(JIB_JAR) ?? endif -? run-test-$1: +? clean-workdir-$1: +?????? $$(RM) -r $$($1_TEST_SUPPORT_DIR) + +? run-test-$1: clean-workdir-$1 ??????? $$(call LogWarn) ??????? $$(call LogWarn, Running test '$$($1_TEST)') ??????? $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR)) /Magnus From mete.balci at antelabs.com Fri Nov 24 10:42:32 2017 From: mete.balci at antelabs.com (Mete Balci) Date: Fri, 24 Nov 2017 11:42:32 +0100 Subject: problem building client variant in 9.0.1+11 In-Reply-To: <43cbd94c-10ee-da91-8925-459a86bc83bf@oracle.com> References: <43cbd94c-10ee-da91-8925-459a86bc83bf@oracle.com> Message-ID: Thanks Erik, I understand. I did patch the jvm.cfg (aliased server to client) and then I had to do something for the errors below, so I added JVMCI_FLAG_CHECKED for both MaxVectorSize and ReduceInitialCardMarks to JVMCIGlobals::check_jvmci_flags_are_consistent() -no idea if this is correct but not important for me for the moment -. Now the client build succeeds. Mete # Internal Error (../src/share/vm/jvmci/jvmci_globals.cpp:95), pid=31194, tid=31195 # assert(MaxVectorSizechecked) failed: MaxVectorSize flag not checked # Internal Error (../src/share/vm/jvmci/jvmci_globals.cpp:97), pid=32358, tid=32359 # assert(ReduceInitialCardMarkschecked) failed: ReduceInitialCardMarks flag not checked On Thu, Nov 23, 2017 at 5:03 PM, Erik Joelsson wrote: > Hello Mete, > > The options to chose which jvm to build was never completely dynamic like > that unfortunately. The jvm.cfg file is still assuming only a few specific > combinations. A build of client only has never been an official combination > so unfortunately fails. It's really too bad because it shouldn't be hard to > fix that build logic, it just has never been a priority. I don't have > access to source right now, but if you want to patch your source, look for > jvm.cfg* and find the template for your platform and modify it to support > client only. > > At least that's my best guess as to what is failing here. > > /Erik > > > On 2017-11-23 05:32, Mete Balci wrote: > >> Hi, >> >> I am trying to build the client variant, but it fails with the output >> below. Is this a known issue or is there any specific configure option I >> should use ? >> >> Thanks, >> >> Mete >> >> Compiling 4 files for BUILD_JIGSAW_TOOLS >> Error: missing `server' JVM at >> `/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release >> /jdk/lib/server/libjvm.so'. >> Please install or use the JRE or JDK that contains these missing >> components. >> ExplodedImageOptimize.gmk:40: recipe for target >> '/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release >> /jdk/_packages_attribute.done' >> failed >> make[3]: *** >> [/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release >> /jdk/_packages_attribute.done] >> Error 4 >> make/Main.gmk:356: recipe for target 'exploded-image-optimize' failed >> make[2]: *** [exploded-image-optimize] Error 1 >> >> > -- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying, disclosure or taking of any action in reliance upon it by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. The sender accepts no liability if this email harms any systems or data of the recipient or if this email is accessed by anyone other than the person(s) to whom it is addressed. antelabs GmbH (CHE-153.180.355) is registered in Zug, Switzerland and its registered office address is Grafenauweg 10, 6301 Zug, Switzerland. From magnus.ihse.bursie at oracle.com Fri Nov 24 10:45:43 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 24 Nov 2017 11:45:43 +0100 Subject: RFR: JDK-8191856 "make clean-test" does not work properly Message-ID: <9725cfb4-eba3-f8f3-9b7e-a35c7176b6dd@oracle.com> With the new layout of make run-test, the test-results and test-support directories are not removed by "make clean-test", and not even "make clean". Bug: https://bugs.openjdk.java.net/browse/JDK-8191856 Patch inline: diff --git a/make/Main.gmk b/make/Main.gmk --- a/make/Main.gmk +++ b/make/Main.gmk @@ -1049,7 +1049,7 @@ ?# file. ?CLEAN_DIRS += hotspot jdk bootcycle-build test buildtools support \ -??? images make-support test-make bundles buildjdk +??? images make-support test-make bundles buildjdk test-results test-support ?CLEAN_DIR_TARGETS := $(addprefix clean-, $(CLEAN_DIRS)) ?CLEAN_SUPPORT_DIRS += demos ?CLEAN_SUPPORT_DIR_TARGETS := $(addprefix clean-, $(CLEAN_SUPPORT_DIRS)) @@ -1094,6 +1094,8 @@ ?# while classes and touch files end up in jdk. ?clean-support: clean-jdk +clean-test: clean-test-results clean-test-support + ?# Remove everything, including configure configuration. If the output ?# directory was created by configure and now becomes empty, remove it as well. ?dist-clean: clean /Magnus From dalibor.topic at oracle.com Fri Nov 24 13:33:02 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 24 Nov 2017 14:33:02 +0100 Subject: Problems with JDK8 build on Ubuntu? In-Reply-To: <569AD62D-3E86-4B90-AC54-D9D4E10E819C@tedneward.com> References: <12BE4ED1-A0F6-49EE-8FB1-334D89AF2C80@tedneward.com> <4DFF8D27-C1E0-47FF-B73F-C090BC3A8B51@tedneward.com> <1845eabe-faa4-941e-8806-81478464767d@oracle.com> <75BFB179-26B4-4551-92FA-A46D07AE6F0F@tedneward.com> <1c9a5e6c-8453-c71f-d10b-f2ee37094307@oracle.com> <40a67107-53d2-8a5a-c1bc-7924acadd07f@oracle.com> <569AD62D-3E86-4B90-AC54-D9D4E10E819C@tedneward.com> Message-ID: <53879410-ae20-5bac-8394-4c91c238ea45@oracle.com> The cpio message comes from OpenJDK's configure script. See http://hg.openjdk.java.net/jdk8u/jdk8u/file/a0672a294b9a/common/autoconf/basics.m4 BASIC_REQUIRE_PROG(CPIO, cpio) I would doubt that all OpenJDK build dependencies are part of the typical docker image, so you should run apt-get build-dep openjdk-8 (or 9, depending on which one you're trying to create a CI image for) as part of your docker build. cheers, dalibor topic On 24.11.2017 10:42, Ted Neward wrote: > Changing it up just a touch?. > > I got it to build fine inside of Ubuntu 16 (and, just for kicks, Kubuntu, since I prefer KDE as a GUI) without flaw. > > But when I try to do it in a Docker image, I get a weird configure error: ?Could not find cpio!? > > Googling around reveals that cpio (as far as apt packaging is concerned) is replaced by tar, which is definitely in the image. And I didn?t run into this problem when I was doing in a real VM (as opposed to Docker), so I?m a little surprised by all this. > > On top of that, I just got an OpenJDK 9 image to build fine inside of Docker right before I started to do the same for 8. > > So?. Any thoughts? > > BTW, if you want to have a look at the Dockerfiles, they?re at https://bitbucket.org/TedNeward/docker . (I put all the images that aren?t part of applications or platforms into this one repo. I find it easier to keep track of them that way for demos and stuff.) They?re in openjdk8 and openjdk9, respectively. > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:36 AM, "build-dev on behalf of Ted Neward" wrote: > > That is just Byzantine enough to be true. :-) > > I had a feeling the answer was going to be something along the lines of ?Reasons?and backwards compatibility reasons? or so, and that pretty neatly fits into that category, so?. Got it. :-) > > Thanks! Downloading source now and trying again. (I knew it had to be something stupidly simple on my end.) > > Ted Neward > Author, Speaker, Mentor > http://www.newardassociates.com > t: @tedneward | m: (425) 647-4526 > > On 11/23/17, 3:31 AM, "dalibor topic" wrote: > > > > On 23.11.2017 12:25, Ted Neward wrote: > > OK, so it?s still at java.net; that?s good to know. :-) > > > > Out of curiosity, though, what?s the difference? Why maintain two? > > jdk8/jdk8 is the 'historic' source code 'archive' for the development of > JDK 8. JDK 8u is what happened since in the updates. > > JDK Release Projects like JDK 8 have a special status in Bylaws (see > http://openjdk.java.net/bylaws#jdk-release-projects) while 'regular' > Projects like JDK 8 Updates do not. So updates end up being separate > Projects with separate repos. > > Well ... you asked. ;) > > cheers, > dalibor topic > > > Ted Neward > > Author, Speaker, Mentor > > http://www.newardassociates.com > > t: @tedneward | m: (425) 647-4526 > > > > On 11/23/17, 3:21 AM, "dalibor topic" wrote: > > > > hg clone http://hg.openjdk.java.net/jdk8u/jdk8u/ and then bash > > get_source.sh within jdk8u directory. > > > > cheers, > > dalibor topic > > > > On 23.11.2017 12:15, Ted Neward wrote: > > > Save me a Google and remind me where that repo URL is? :-) > > > > > > Ted Neward > > > Author, Speaker, Mentor > > > http://www.newardassociates.com > > > t: @tedneward | m: (425) 647-4526 > > > > > > On 11/23/17, 3:14 AM, "dalibor topic" wrote: > > > > > > Probably - jdk8/jdk8 is the GA source code from a few years ago. > > > jdk8u/jdk8u is the latest JDK 8 updates. > > > > > > cheers, > > > dalibor topic > > > > > > On 23.11.2017 12:12, Ted Neward wrote: > > > > Errr?.. What?s the difference, again? > > > > > > > > I cloned java.net/jdk8/jdk8, which is what I thought was the correct repo?is there a new URL? I haven?t done this in a while, so I jumped onto Google and took the first URL in a description that seemed correct. Am I trying to clone the wrong repo? > > > > > > > > Ted Neward > > > > Author, Speaker, Mentor > > > > http://www.newardassociates.com > > > > t: @tedneward | m: (425) 647-4526 > > > > > > > > On 11/23/17, 3:08 AM, "build-dev on behalf of dalibor topic" wrote: > > > > > > > > You're not trying to build jdk8/jdk8 instead of jdk8u/jdk8u, right? > > > > > > > > cheers, > > > > dalibor topic > > > > > > > > On 23.11.2017 11:50, Ted Neward wrote: > > > > > Yeah, I?ve got build-dep and openjdk-8. I?ll have a look at the source, but this begs a question: Why hasn?t it been backported to the JDK8 repo, if it?s a known fix? > > > > > > > > > > Ted Neward > > > > > Author, Speaker, Mentor > > > > > http://www.newardassociates.com > > > > > t: @tedneward | m: (425) 647-4526 > > > > > > > > > > On 11/23/17, 2:32 AM, "John Paul Adrian Glaubitz" wrote: > > > > > > > > > > Hi Ted! > > > > > > > > > > On 11/23/2017 11:23 AM, Ted Neward wrote: > > > > > > When I run it, there?s a problem about OS version detection, which I found a fix > > > > > > for, but then it appears that there?s some kind of syntax error in a generate makefile. > > > > > > Before I attach a ridiculously long logfile, does anybody have a quick fix or know where > > > > > > I should go to get the fix? > > > > > > > > > > I suggest having a look at the Debian packaging source for the openjdk-8 package > > > > > which is also used in Ubuntu (the maintainer is Matthias Klose in both cases) [1]. > > > > > > > > > > Have a look at the patches in debian/patches as well as the build script in debian/ > > > > > rules. This should give you the right idea on what is necessary to OpenJDK 8 build > > > > > on Ubuntu. > > > > > > > > > > Please also make sure you have the necessary build dependencies installed: > > > > > > > > > > # apt build-dep openjdk-8 > > > > > > > > > > Adrian > > > > > > > > > > > [1] http://bazaar.launchpad.net/~openjdk/openjdk/openjdk8/files > > > > > > > > > > -- > > > > > .''`. John Paul Adrian Glaubitz > > > > > : :' : Debian Developer - glaubitz at debian.org > > > > > `. `' Freie Universitaet Berlin - glaubitz at physik.fu-berlin.de > > > > > `- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913 > > > > > > > > > > > > > > > > > > > > > > > -- > > > > Dalibor Topic | Principal Product Manager > > > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > > > > > ORACLE Deutschland B.V. & Co. KG > > > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > > > > > Oracle is committed to developing > > > > practices and products that help protect the environment > > > > > > > > > > > > > > > > > > -- > > > Dalibor Topic | Principal Product Manager > > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > > > ORACLE Deutschland B.V. & Co. KG > > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > > > Oracle is committed to developing > > > practices and products that help protect the environment > > > > > > > > > > > > > -- > > Dalibor Topic | Principal Product Manager > > Phone: +494089091214 | Mobile: +491737185961 > > > > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > > > ORACLE Deutschland B.V. & Co. KG > > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > > Registergericht: Amtsgericht M?nchen, HRA 95603 > > > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > > > Oracle is committed to developing > > practices and products that help protect the environment > > > > > > > > -- > Dalibor Topic | Principal Product Manager > Phone: +494089091214 | Mobile: +491737185961 > > > ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg > > ORACLE Deutschland B.V. & Co. KG > Hauptverwaltung: Riesstr. 25, D-80992 M?nchen > Registergericht: Amtsgericht M?nchen, HRA 95603 > > Komplement?rin: ORACLE Deutschland Verwaltung B.V. > Hertogswetering 163/167, 3543 AS Utrecht, Niederlande > Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 > Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher > > Oracle is committed to developing > practices and products that help protect the environment > > > > > > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From martinrb at google.com Fri Nov 24 23:19:13 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 24 Nov 2017 15:19:13 -0800 Subject: RFR: JDK-8191856 "make clean-test" does not work properly In-Reply-To: <9725cfb4-eba3-f8f3-9b7e-a35c7176b6dd@oracle.com> References: <9725cfb4-eba3-f8f3-9b7e-a35c7176b6dd@oracle.com> Message-ID: Should all phony targets be listed in a .PHONY line? On Fri, Nov 24, 2017 at 2:45 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > With the new layout of make run-test, the test-results and test-support > directories are not removed by "make clean-test", and not even "make clean". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191856 > Patch inline: > diff --git a/make/Main.gmk b/make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -1049,7 +1049,7 @@ > # file. > > CLEAN_DIRS += hotspot jdk bootcycle-build test buildtools support \ > - images make-support test-make bundles buildjdk > + images make-support test-make bundles buildjdk test-results > test-support > CLEAN_DIR_TARGETS := $(addprefix clean-, $(CLEAN_DIRS)) > CLEAN_SUPPORT_DIRS += demos > CLEAN_SUPPORT_DIR_TARGETS := $(addprefix clean-, $(CLEAN_SUPPORT_DIRS)) > @@ -1094,6 +1094,8 @@ > # while classes and touch files end up in jdk. > clean-support: clean-jdk > > +clean-test: clean-test-results clean-test-support > + > # Remove everything, including configure configuration. If the output > # directory was created by configure and now becomes empty, remove it as > well. > dist-clean: clean > > /Magnus > From martinrb at google.com Fri Nov 24 23:23:27 2017 From: martinrb at google.com (Martin Buchholz) Date: Fri, 24 Nov 2017 15:23:27 -0800 Subject: RFR: JDK-8189099 JTReg now supports 256 jobs In-Reply-To: <8916640d-f219-3b22-04d0-b6e9f36485c4@oracle.com> References: <8916640d-f219-3b22-04d0-b6e9f36485c4@oracle.com> Message-ID: Looks good. On Fri, Nov 24, 2017 at 2:22 AM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > From the bug report: > "According to research by Jonathan Gibbons , JTReg now supports 256 jobs, > in contrast to the older limit of 50 jobs. This limit is enforced in the > make files, and it should be updated to reflect the new limit (or the check > removed entirely)." > > I choose to remove the check. If you send in more than JOBS=256, then > JTReg will complain. If that limit is ever increased, it should only be > done so in JTReg, not also in the makefiles. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189099 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8189099-remove-jtreg-jo > b-limit-of-50/webrev.01 > > /Magnus > > From magnus.ihse.bursie at oracle.com Mon Nov 27 10:30:23 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 27 Nov 2017 11:30:23 +0100 Subject: RFR: JDK-8191856 "make clean-test" does not work properly In-Reply-To: References: <9725cfb4-eba3-f8f3-9b7e-a35c7176b6dd@oracle.com> Message-ID: On 2017-11-25 00:19, Martin Buchholz wrote: > Should all phony targets be listed in a .PHONY line? Yes, that's our policy. We do that using the ALL_TARGETS variable, which has a .PHONY: $(ALL_TARGETS) rule at the end. Things can break subtly if you don't have phony targets declared as such. /Magnus > > On Fri, Nov 24, 2017 at 2:45 AM, Magnus Ihse Bursie > > > wrote: > > With the new layout of make run-test, the test-results and > test-support directories are not removed by "make clean-test", and > not even "make clean". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191856 > > Patch inline: > diff --git a/make/Main.gmk b/make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -1049,7 +1049,7 @@ > ?# file. > > ?CLEAN_DIRS += hotspot jdk bootcycle-build test buildtools support \ > -??? images make-support test-make bundles buildjdk > +??? images make-support test-make bundles buildjdk test-results > test-support > ?CLEAN_DIR_TARGETS := $(addprefix clean-, $(CLEAN_DIRS)) > ?CLEAN_SUPPORT_DIRS += demos > ?CLEAN_SUPPORT_DIR_TARGETS := $(addprefix clean-, > $(CLEAN_SUPPORT_DIRS)) > @@ -1094,6 +1094,8 @@ > ?# while classes and touch files end up in jdk. > ?clean-support: clean-jdk > > +clean-test: clean-test-results clean-test-support > + > ?# Remove everything, including configure configuration. If the output > ?# directory was created by configure and now becomes empty, > remove it as well. > ?dist-clean: clean > > /Magnus > > From peterbudai at hotmail.com Mon Nov 27 11:12:22 2017 From: peterbudai at hotmail.com (Peter Budai) Date: Mon, 27 Nov 2017 11:12:22 +0000 Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: , Message-ID: MSYS2 or Cygwin should be similar from the technical point of view IMHO. I?m familiar with MSYS2, but not with Cygwin. The big change as you called out is to make sure that gcc toolchain can build successfully also for a Windows platform and produce a properly working binaries. BTW I don?t belie there are big performance differences whether you are building with GCC or MSC Once again, please advise on what is the best way to move forward, or stop this effort. Peter ________________________________ From: Thomas St?fe Sent: Thursday, November 23, 2017 10:36:07 PM To: Lussier, Denis Cc: Jonathan Gibbons; build-dev at openjdk.java.net; Peter Budai Subject: Re: Building OpenJDK9 on MSYS2 On Thu, Nov 23, 2017 at 12:40 AM, Lussier, Denis > wrote: This is good stuff. Back in 2010 I got OpenJDK compiled and running on the Microsoft Toolchain. I never ran the jtreg tests, but, the binaries worked for running basic Tomcat but definitely not for trying to run Eclipse. These days I am a pretty big fan of MSYS2. In my personal experiences with building a PostgreSQL Windoze distribution, the MSYS2 binaries run a little faster than using the old MS Toolchain. https://www.openscg.com/2016/02/building-postgresql-on-windows-for-performance/ Well, the linked article does claim the msys2 toolchain to be faster than the Visual Studio, but there are no information I can see which compiler and linker options were used. Without this information, the article is difficult to take seriously. While I really respect these efforts, I regret seeing the fragmentation in windows build environments. I rather have one well kept build environment than of multiple buggy ones - and we have not that many folks interested in the windows port in the first place (it always feels like second place to the Posix platforms to me). The official build environment of the openjdk windows port is Cygwin + Visual Studio. Even if we think the gcc toolchain would be an attractive alternative to VS - why not just use the cygwin gcc instead? That way we would at least share the same posix layer. Just my 5c. Kind Regards, Thomas --Luss On Wed, Nov 22, 2017 at 4:28 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > Peter, > > With over 120 :tier1 test failures, it would be worth understanding the > test failures as part of moving forward. There should normally be no :tier1 > test failures. > > -- Jon > > > > > On 11/22/2017 01:10 PM, Peter Budai wrote: > >> Let me give an update on the current status: >> >> * I have managed to build both the 64 and the 32-bit version. >> * The 64-bit version seems reasonable: >> >> >> >> ============================== >> >> Test summary - w64-bit >> >> ============================== >> >> TEST TOTAL PASS FAIL >> ERROR >> >> jtreg:jdk/test:tier1 1645 1610 34 1 >>>> << >>>> jtreg:langtools/test:tier1 3907 3819 79 >>>> 9 << >>>> >>> jtreg:nashorn/test:tier1 0 0 0 >> 0 >> >> jtreg:jaxp/test:tier1 0 0 0 >> 0 >> >> ============================== >> >> * However the 32-bit version of hotspot contains a bunch of inline >> assembly pieces which uses an MSC specific syntax, and my ASM knowledge is >> really limited. I have managed to get a many inline assembly codes from the >> Linux version, but there are few pieces where I was not able to find a good >> solution yet, so although the 32-bit version compiles, unfortunately it is >> not working >> * I have installed VS Express 2013 and made sure that the >> ?traditional? Microsoft toolchain is still working with the changes >> * My OCA has been processed >> >> I have a changeset which cleanly applies to JDK9 v181, but I recall you >> have mentioned earlier that you would like to consider this to JDK10 >> >> So what is the best way to open a PR for review? This page: >> http://openjdk.java.net/contribute/ says I should send the changeset as >> attachment, but earlier somebody mentioned here that attachments are >> removed from the developer mailing lists. >> >> Best regards, >> >> Peter >> >> From: Erik Joelsson> >> Sent: Thursday, November 2, 2017 1:07 AM >> To: Peter Budai>; Magnus Ihse >> Bursie> >> Cc: build-dev at openjdk.java.net> >> Subject: Re: Building OpenJDK9 on MSYS2 >> >> I would say a few hours is way too long for tier1, but it of course >> depends on the hardware used. We typically run it on windows in less >> than 30 minutes with concurrency set to 6. Not sure what concurrency you >> used by default. >> >> /Erik >> >> >> On 2017-10-27 04:33, Peter Budai wrote: >> >>> Hi Magnus, after a little poking I managed to install and use jtreg, >>> thanks for the guidance. >>> >>> Make run-test-tier1 resulted a pretty OK result for a first try, at >>> least for run-test-jdk: >>> Test results: passed: 1,610; failed: 34; error: 1 >>> It took a few hors to run ? is that normal? >>> >>> I?ll review the patchset, and then share that with you. >>> >>> P. >>> >>> From: Magnus Ihse Bursie> >>> Sent: Thursday, October 26, 2017 11:00 AM >>> To: Peter Budai> >>> Cc: build-dev at openjdk.java.net> >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> >>> On 2017-10-26 00:01, Peter Budai wrote: >>> OK, I have found what was missing, it was actually my fault with a >>> missing exception handler. >>> >>> So finally OpenJDK build has finished on Windows using gcc toolchain >>> running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it looks >>> promising: >>> ./build/windows-x86_64-normal-server-fastdebug/hotspot/varia >>> nt-server/libjvm/gtest/gtestLauncher.exe --jdk=/home/peterbud/jdk9/buil >>> d/windows-x86_64-normal-server-fastdebug/jdk >>> ?. >>> ?. >>> ?. >>> >>> [----------] Global test environment tear-down >>> [==========] 346 tests from 54 test cases ran. (3859 ms total) >>> [ PASSED ] 346 tests. >>> I'm impressed! :-) >>> >>> Would you care to share your current patchset, just to still my >>> curiosity? :-) >>> >>> >>> >>> What is the best way to test the current build more thoroughly? >>> "make run-test-tier1". As Erik says, you'll need jtreg, and call >>> "configure --with-jtreg=...". You can get it from the Adopt OpenJDK group >>> here: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccess >>> fulBuild/artifact/ >>> >>> /Magnus >>> >>> >>> P. >>> >>> From: Bob Vandette> >>> Sent: Tuesday, October 24, 2017 8:10 PM >>> To: Peter Budai> >>> Cc: David Holmes>; Erik Joelsson>> erik.joelsson at oracle.com>; Magnus Ihse Bursie >>> ie at oracle.com>; build-dev at openjdk.java.net>> build-dev at openjdk.java.net> >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> Can you provide some details about your toolchain, processor and os plus >>> a dump of the native instructions around the SEGV. This might give us >>> enough info to be able to figure out what?s going on. >>> >>> Bob. >>> >>> On Oct 24, 2017, at 1:21 PM, Peter Budai >> peterbudai at hotmail.com>> wrote: >>> >>> I get that error running in the debugger but also running >>> without/outside of the debugger as well. >>> >>> I saw the comment in the code about generating SEGV in function >>> generate_get_cpu_info(), however the debugger can execute that, and the >>> SEGV I experience is coming later in the VM_Version::get_processor_features() >>> function >>> >>> Peter >>> >>> From: Bob Vandette> >>> Sent: Tuesday, October 24, 2017 6:28 PM >>> To: Peter Budai> >>> Cc: David Holmes>; Erik Joelsson>> erik.joelsson at oracle.com>; Magnus Ihse Bursie >>> ie at oracle.com>; build-dev at openjdk.java.net>> build-dev at openjdk.java.net> >>> Subject: Re: Building OpenJDK9 on MSYS2 >>> >>> Was this a SEGV while you were running the debugger? >>> >>> There is an intentional SEGV generated. This is used to determine if we >>> can use some of newer >>> CPU features. Try to allow the SEGV to continue to see if you run >>> normally. >>> >>> Bob. >>> >>> >>> On Oct 24, 2017, at 11:37 AM, Peter Budai >>> :peterbudai at hotmail.com>> wrote: >>>> >>>> It seems that the compile is progressing well, I have 49 >>>> executables/tools and 38 compiled shared libraries already in the JDK >>>> folder. >>>> >>>> I have tried to run the product with the simplest ?java -version? >>>> command, however I get a SIGSEGV at get_cpu_info_stub() in >>>> vm_version_x86.cpp, VM_Version::get_processor_features() >>>> >>>> get_cpu_info_stub(&_cpuid_info); >>>> >>>> Thread 5 received signal SIGSEGV, Segmentation fault. >>>> 0x000000002d9a072f in ?? () >>>> >>>> I can debug using gdb, but unfortunately this is pure ASM, and my >>>> knowledge on this is close to 0. >>>> >>>> Any idea help or pointer how could I tackle this? >>>> >>>> Peter >>>> >>>> From: David Holmes> >>>> Sent: Sunday, October 15, 2017 10:37 PM >>>> To: Peter Budai>; Erik Joelsson>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie >>>> ie at oracle.com> >>>> Cc: build-dev at openjdk.java.net >>>> >> >>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>> >>>> On 16/10/2017 12:41 AM, Peter Budai wrote: >>>> >>>>> A quick status update: >>>>> >>>>> * Hotspot successfully compiled without warnings >>>>> * I?d like to run the unit tests, but as I see ?make check? does >>>>> not work, and gtestlauncher expects a command line parameter jdk. Tried to >>>>> look up some documentation on this, but have not found. So the question is: >>>>> how can I run unit tests for hotspot? Do I need also JDK compiled for that? >>>>> Or the bootJDK is good enough? Any help would be appreciated. >>>>> >>>> Hotspot has to be tested as part of a full JDK - you can't load the JVM >>>> without having the "J" part :) >>>> >>>> You should be able to drop your built dll into an existing JDK 9 windows >>>> JDK and test it that way. >>>> >>>> David >>>> ----- >>>> >>>> * Also I?m making progress on compiling jdk, but there are some >>>>> very interesting solutions on windows linking which makes a bit more >>>>> difficult to compile with gcc: LIBS_windows contains sometimes simple >>>>> library names (which I believe is correct) and other times library names >>>>> with full path (which I believe is not the best solution). I?m trying to >>>>> rework those places and use simple library names and passing search path >>>>> for libraries -L (for gcc toolchain) and /LIBPATH: (for >>>>> Microsoft toolchain). Also I was surprised by a few manual function name >>>>> exports? >>>>> * jdk code base contains apparently more MSVC specific part, >>>>> many places casts/lack of casts are generating errors, static attributes >>>>> were missing etc. a bit tedious work. >>>>> >>>>> P. >>>>> >>>>> From: Erik Joelsson> >>>>> Sent: Wednesday, October 11, 2017 4:16 PM >>>>> To: Magnus Ihse Bursie>; Peter >>>>> Budai> >>>>> Cc: build-dev at openjdk.java.net >>>>> >> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> Hello, >>>>> >>>>> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: >>>>> >>>>> For gcc, we let the compiler generate the .d file. For the Microsoft >>>>> tool chain, we use a clever sed script to extract and create it ourself. >>>>> >>>>> I think that logic is checking for "Windows", not "Microsoft". That >>>>> might be your cause of trouble. >>>>> >>>>> Look in NativeCompilation.gmk. >>>>> >>>>> That was my initial thought as well, but we do correctly check for >>>>> microsoft. Also it's not the .d files that are the problem. As Peter just >>>>> wrote, they look fine. It's the .d.target files which we create using the >>>>> same technique on all platforms. What we don't account for is the compiler >>>>> putting Windows mixed paths in the .d files. >>>>> >>>>> /Magnus >>>>> >>>>> 11 okt. 2017 kl. 14:43 skrev Peter Budai >>>>> >>>: >>>>> Hi Erik, >>>>> >>>>> The .d file looks like this: >>>>> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: \ >>>>> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp \ >>>>> >>>>> I have checked .d.targets file, and looks like it has the first line >>>>> has not been deleted, and the file names below are also wrong: >>>>> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-serve >>>>> r-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj : : >>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp : >>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : >>>>> >>>>> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by >>>>> the ?C:/? >>>>> -e 's/^[^:]*: *//' >>>>> >>>>> Yes, that does indeed look like the problem. I suppose the regexp is >>>>> unnecessarily strict. It should be ok to rewrite it as something like this: >>>>> -e 's/^.*: *//' >>>>> >>>>> Basically just make sure it ends with : and any number of spaces. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> >>>>> Peter >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Erik Joelsson> >>>>> Sent: Wednesday, October 11, 2017 12:16 PM >>>>> To: Peter Budai>; Magnus Ihse >>>>> Bursie>; >>>>> build-dev at openjdk.java.net>>>>> build-dev at openjdk.java.net> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> >>>>> Hello Peter, >>>>> >>>>> On 2017-10-11 00:18, Peter Budai wrote: >>>>> Thanks Magnus & Erik >>>>> >>>>> First thanks for your support and kind words! >>>>> >>>>> Magnus, I have checked .bash_profile, .bashrc but they seem to be >>>>> empty (everything is commented out). You can check with a default MSYS2 >>>>> install, I have not changed these files at all. If you find thee something >>>>> specific I can give a try here as well. >>>>> >>>>> Let me give also a quick status update, where am I with building >>>>> hotspot: >>>>> ? I guess its still the beginning, but I have managed to compile >>>>> jvm.dll with almost 700 object file: with debug info the dll is around 700 >>>>> MB ? >>>>> ? I made only surgical, minimal changes to the source, and so >>>>> far it looks reasonable. I have encountered 3 scenarios where changes were >>>>> necessary: >>>>> o When in makefiles conditionals were using assuming that if >>>>> target_os is windows then it is visual studio compiler/linker. Obviously >>>>> these conditionals had to be reviewed in a few places and if necessary were >>>>> changes to check the toolchain=Microsoft >>>>> These are not surprising and should be pretty straight forward to fix >>>>> and it seems you know what to do. >>>>> >>>>> >>>>> ? >>>>> o I got a few warnings as gcc 7.2 uncovered some code problems in >>>>> windows specific codes, where before that MSVC I guess did not say a word? >>>>> To get around this you can configure with --disable-warnings-as-errors >>>>> until you get things working properly. This is commonly needed when using >>>>> compiler versions that we normally don't use. >>>>> >>>>> >>>>> ? >>>>> o And I had like 6-7 places where the code was using MSVC specific >>>>> __try ? __except structures which gcc does not know. Do you have a >>>>> suggestion how to approach them? I can do ugly #ifdefs (I would avoid that) >>>>> but I have also seen some solutions to replace them with a code which gcc >>>>> can compile (http://www.programmingunlimited.net/siteexec/content.cgi? >>>>> page=mingw-seh ) ? but before doing that though I would ask first >>>>> you on the purpose of those >>>>> This kind of question is probably best to bring to the hotspot mailing >>>>> list. >>>>> ? What bothers me is that I was not able to do incremental >>>>> builds: when an error occurs, and build stops, then after making change in >>>>> the CPP source the build cannot continue, I always got an error message: >>>>> >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse.d.targets:1: >>>>> *** missing target pattern. Stop. >>>>> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 >>>>> >>>>> If I do a ?make clean? and restart the build then it nicely compiles. >>>>> >>>>> Question 1: Is there a way to resume such builds without ?make clean?? >>>>> Well, incremental builds is supposed to work well. We have several >>>>> extra tricks in there to handle cases where normal make builds would fail. >>>>> The *.d.targets files is one such trick and it seems to backfire for you. >>>>> The contents of that file should be something like: >>>>> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : >>>>> >>>>> Basically an empty rule for each dependency for the corresponding >>>>> object file. Declaring these rules makes it possible to delete source files >>>>> without having to build clean. It seems your file is not generated >>>>> correctly so please have a look inside it. The file is in >>>>> make/common/NativeCompilation.gmk, look for >>>>> DEPENDENCY_TARGET_SED_PATTERN. >>>>> >>>>> >>>>> >>>>> Question 2: What would be the best way to submit/share the patches for >>>>> your thorough review? >>>>> >>>>> Well, first of all, have you signed the OCA? >>>>> >>>>> As for publishing patches and reviews, there is a bit of chicken and >>>>> egg problem. Once you become an "author" in any of the OpenJDK projects, >>>>> you get a user name and should be able to publish reviews on >>>>> cr.openjdk.java.net>>>> penjdk.java.net>>>> k.java.net/%3e%3chttp:/cr.openjdk.java.net%3chttp:/cr. >>>>> openjdk.java.net/>>>. Before that, if the patch is small, it can be >>>>> posted inline in an email to the list. If it's large, you will need a >>>>> current OpenJDK user to host it for you. At least that's how I understand >>>>> it. Hopefully someone who knows the process better can chime in here. >>>>> >>>>> I should also let you know that getting this into JDK 9 is most likely >>>>> not going to happen. AFAIK we are only doing security updates for 9. It >>>>> would have to go into the currently active release. I should also warn you >>>>> that new ports generally need a certain amount of backing to be accepted. >>>>> It may be that this would have to live in a porting side project. Hopefully >>>>> someone who knows this better can chime in here as well. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> P. >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Magnus Ihse Bursie> >>>>> Sent: Tuesday, October 10, 2017 10:04 AM >>>>> To: Peter Budai>; Erik Joelsson>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net>>>> build-dev at openjdk.java.net>> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> On 2017-10-07 10:14, Peter Budai wrote: >>>>> The configure of OpenJDK overwrites the SHELL. Actually it is using >>>>> bash, but for the arguments it was using ?-e -o pipefail?. I have figured >>>>> that for MSYS2 bash what is needed as bash arguments is ?-e -l -c -o >>>>> pipefail? >>>>> >>>>> That looks like solving this problem, and now the real issues are >>>>> surfacing. >>>>> >>>>> FWIW, "-l" makes bash behave like a login shell. Most likely you are >>>>> changing bash's behavior in one of your login scripts, and that change is >>>>> what's really needed. >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> Peter >>>>> >>>>> From: Peter Budai> >>>>> Sent: Friday, October 6, 2017 6:43 PM >>>>> To: Magnus Ihse Bursie>; Erik >>>>> Joelsson>; build-dev at openjdk.java.net >>>>> >> >>>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>>> >>>>> Magnus, >>>>> >>>>> I have followed your suggestion and removed the fixpath prefixes from >>>>> gcc related compile tools, and left only the fixpath prefix _only_ for the >>>>> Boot JDK related tools in place. >>>>> >>>>> 1) As I follow the process, all java and javac related compile >>>>> steps are running properly >>>>> 2) When the process reaches gcc related steps I got the error >>>>> message at the same place as before (no fixpath). If I execute that command >>>>> from the bash prompt, it creates the output: >>>>> >>>>> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >>>>> /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/j >>>>> dk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegistry.java.template >>>>> 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | >>>>> /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ >>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' >>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption >>>>> Registry.java >>>>> >>>>> As I have mentioned the parameters are replaced by the bash >>>>> automatically >>>>> 3) Then build continues, then little later stops at a super >>>>> simple command: >>>>> >>>>> mv /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java >>>>> Needless to say, the ByteBuffer.java.tmp file DOES exist. >>>>> And running the above command from the bash works, and build continues. >>>>> 4) A few similar cases (stops) with DirectByteBuffer and >>>>> DirectByteBufferR >>>>> >>>>> >>>>> Currently I try to explore how that might relate to the MSYS2 bash and >>>>> make, somehow it behaves differently >>>>> >>>>> If you have any other suggestion, let me know. >>>>> >>>>> Best regards, >>>>> >>>>> Peter >>>>> >>>>> From: Peter Budai> >>>>> Sent: Thursday, October 5, 2017 3:52 PM >>>>> To: Magnus Ihse Bursie>; Erik >>>>> Joelsson>; build-dev at openjdk.java.net >>>>> >> >>>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>>> >>>>> Hi Magnus, >>>>> >>>>> So first of all, here is the current patch, which I was not able to >>>>> attach: https://pastebin.com/pwT4Ynxc >>>>> >>>>> That's surprising, since gcc is prefixed with fixpath, which it should >>>>>>> not. >>>>>>> >>>>>> Actually you DO need fixpath IMHO. >>>>> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), >>>>> which is a fully functional Windows executable, which expects Windows >>>>> formatted path arguments. >>>>> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see >>>>> that patch), none of the command line arguments are converted from the >>>>> unix path to Windows, but fixpath does that conversion. There is a wiki >>>>> describing more details on this: >>>>> https://github.com/msys2/msys2/wiki/Porting#user-content- >>>>> filesystem-namespaces >>>>> >>>>> >>>>> >>>>> I have a hard time believing this is a race condition. On the other >>>>>>> hand, this stuff is weird, we're misusing the C preprocessor to process >>>>>>> defines in java code, so I'm not surprised it breaks down. >>>>>>> I don't know why it succeeded when run on the command line, though. >>>>>>> >>>>>> When I execute that command from the bash command line there is no >>>>> EXPORT MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic >>>>> conversion of the arguments. Maybe it has something to do how fixpath does >>>>> CreateProcess? >>>>> >>>>> Does that help? >>>>> >>>>> Best regards, >>>>> >>>>> Peter >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Magnus Ihse Bursie> >>>>> Sent: Thursday, October 5, 2017 12:13 PM >>>>> To: Peter Budai>; Erik Joelsson>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net>>>> build-dev at openjdk.java.net>> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> >>>>> On 2017-10-05 11:59, Peter Budai wrote: >>>>> Hi Magnus and Erik, >>>>> >>>>> I really appreciate your quick feedback. I assumed that it won?t be >>>>> easy, but I just don?t feel I should give up now - maybe later when I see >>>>> the real scale of work. So bear with me for a time being. >>>>> >>>>> Attached is a patch which already includes Magnus? changes, plus a few >>>>> which I have added: >>>>> ? basically enabling gcc for windows, >>>>> ? and modifying a logic for compiling fixpath (before that it >>>>> was using hard-coded MS VSC compile flags) >>>>> >>>>> Actually, you must make sure fixpath is *not* used for the toolchain, >>>>> since gcc uses unix style paths. >>>>> (However, other tools such as java will still need it.) >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> So here is what I have as the result of configure: >>>>> ==================================================== >>>>> The existing configuration has been successfully updated in >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release >>>>> using configure arguments '--disable-freetype-bundling >>>>> --disable-javac-server'. >>>>> >>>>> Configuration summary: >>>>> * Debug level: release >>>>> * HS debug level: product >>>>> * JDK variant: normal >>>>> * JVM variants: server >>>>> * OpenJDK target: OS: windows, CPU architecture: x86, address length: >>>>> 64 >>>>> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) >>>>> >>>>> Tools summary: >>>>> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) >>>>> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime >>>>> Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server VM (build >>>>> 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) >>>>> * Toolchain: gcc (GNU Compiler Collection) >>>>> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) >>>>> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) >>>>> >>>>> Build performance summary: >>>>> * Cores to use: 4 >>>>> * Memory limit: 16216 MB >>>>> >>>>> Its clear says that the toolchain is gcc 7.2 (BTW there is no Visual >>>>> Studio on this machine) >>>>> >>>>> Now for the details of the config log, you can see here: >>>>> https://pastebin.com/MN2ZYcHH >>>>> >>>>> And about the build process and the error I get: >>>>> >>>>> $ make JOBS=1 >>>>> Building target 'default (exploded-image)' in configuration >>>>> 'windows-x86_64-normal-server-release' >>>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >>>>> Compiling 17 properties into resource bundles for jdk.compiler >>>>> Parsing 1 properties into enum-like class for jdk.compiler >>>>> Compiling 19 properties into resource bundles for jdk.javadoc >>>>> Compiling 12 properties into resource bundles for jdk.jdeps >>>>> Compiling 7 properties into resource bundles for jdk.jshell >>>>> Compiling 117 files for BUILD_INTERIM_java.compiler >>>>> Compiling 396 files for BUILD_INTERIM_jdk.compiler >>>>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps >>>>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc >>>>> Note: Some input files use or override a deprecated API. >>>>> Note: Recompile with -Xlint:deprecation for details. >>>>> Compiling 159 files for BUILD_TOOLS_JDK >>>>> Note: Some input files use unchecked or unsafe operations. >>>>> Note: Recompile with -Xlint:unchecked for details. >>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b >>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav >>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>>>> make[3]: *** Deleting file '/C/msys64/home/peterbud/jdk9/ >>>>> build/windows-x86_64-normal-server-release/support/gensrc/ja >>>>> va.base/sun/nio/ch/SocketOptionRegistry.java' >>>>> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 >>>>> >>>>> ERROR: Build failed for target 'default (exploded-image)' in >>>>> configuration 'windows-x86_64-normal-server-release' (exit code 2) >>>>> >>>>> No indication of failed target found. >>>>> Hint: Try searching the build log for '] Error'. >>>>> Hint: See common/doc/building.html#troubleshooting for assistance. >>>>> >>>>> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 >>>>> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 >>>>> >>>>> If I run here >>>>> make JOBS=1 LOG=debug >>>>> The failing line seems to be this: >>>>> >>>>> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/configure-support/bin/fixpath.exe >>>>> -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x c >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>> /sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep -v >>>>> '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk >>>>> '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ >>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e 's/^#.*//' >>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption >>>>> Registry.java >>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b >>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav >>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>>>> >>>>> Now the interesting is: if I copy this line above to the bash prompt, >>>>> it runs without problem, and the file support/gensrc/java.base/sun/n >>>>> io/ch/SocketOptionRegistry.java >>>>> That's surprising, since gcc is prefixed with fixpath, which it should >>>>> not. >>>>> >>>>> I have a hard time believing this is a race condition. On the other >>>>> hand, this stuff is weird, we're misusing the C preprocessor to process >>>>> defines in java code, so I'm not suprised it breaks down. I don't know why >>>>> it succeeded when run on the command line, though. My suggestion is to just >>>>> do some quick and dirty hack around this: take the file you manage to >>>>> generate and just copy it in during the build instead. If you can get round >>>>> this, you might start seeing some *real* problems. :-) >>>>> >>>>> Also, my suggestion is that you try running "make hotspot" to cut to >>>>> the chase. Compiling hotspot will likely be the hardest thing. Or even >>>>> "make -k hotspot" to get an assessment of the amount of work ahead of you. >>>>> >>>>> /Magnus >>>>> Is produced. >>>>> >>>>> Then I can again issue >>>>> make JOBS=1 LOG=debug >>>>> >>>>> And the compile process is being continued, until a similar error pops >>>>> up with a different generated file. I have an assumption that this happens >>>>> because make is still running parallel jobs, despite JOBS=1 but I?m not >>>>> sure. >>>>> >>>>> How could I best tackle this? >>>>> >>>>> Thank you and best regards, >>>>> >>>>> Peter >>>>> >>>>> Sent from Mail for >>>>> Windows 10 >>>>> >>>>> From: Magnus Ihse Bursie> >>>>> Sent: Thursday, October 5, 2017 11:33 AM >>>>> To: Erik Joelsson>; Peter >>>>> Budai>; build-dev at openjdk.java.net>>>> lto:build-dev at openjdk.java.net>> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> On 2017-10-05 10:10, Erik Joelsson wrote: >>>>> >>>>>> Hello Peter, >>>>>> >>>>>> >>>>>> On 2017-10-04 21:15, Peter Budai wrote: >>>>>> >>>>>>> Hi Magnus, >>>>>>> >>>>>>> Thanks for the quick reply I?ll check these patches with msys2. >>>>>>> >>>>>>> Let me specify with more details what I?d like to achieve: I?d like >>>>>>> to build OpenJDK9 with MSYS2 MINGW64 environment using gcc toolchain. >>>>>>> (I?m not sure how familiar are you with MSYS2, but there are 3 >>>>>>> different environments: MSYS2, MINGW32 and MINGW64). In theory >>>>>>> MINGW64 with gcc is the closes you can get on Windows platform as a >>>>>>> gcc unix like build environment, which produces still a native 64-bit >>>>>>> executable on Windows. >>>>>>> >>>>>>> I?m not very familiar with OpenJDK yet, so therefore I?d like to hear >>>>>>> your opinion: how realistic is that? >>>>>>> >>>>>> Sorry to disappoint, but I would say that requires major work. There >>>>>> is a strong historic assumption that windows builds are done using >>>>>> Visual Studio. We have abstracted away some of it in configure (see >>>>>> TOOLCHAIN_TYPE), but it's very far from enough to change compiler >>>>>> environment for a Windows build. The native sources are also bound to >>>>>> make a lot of such assumptions. I would expect the changes needed to >>>>>> be in the thousands of lines of code. >>>>>> >>>>> I agree that it requires hard work (even if "thousands" might be an >>>>> overestimation I think, but "hundreds" is not enough, so it's the right >>>>> magnitude). On the other hand, it would be really good if we did sort >>>>> things out, so that we had proper conditions based on OS vs >>>>> compiler/toolchain. >>>>> >>>>> If you really want to start, the first thing is to patch toolchain.m4 >>>>> to >>>>> VALID_TOOLCHAINS_windows="microsoft gcc" >>>>> and then call configure using "bash configure >>>>> --with-toolchain-type=gcc". >>>>> >>>>> As Erik, I doubt you will come very far before things starts tumbling >>>>> down. >>>>> >>>>> When we say supporting the build in msys2 instead of cygwin, we just >>>>>> mean using msys2 as the unix emulating layer for our tools like >>>>>> make/bash/grep/sed etc. >>>>>> >>>>>> One think I have done successfully is running the build in WSL >>>>>> (Windows Subsystem for Linux), but that isn't all that helpful as WSL >>>>>> for practical purposes is more or less like running Linux in a VM, so >>>>>> the build sees a Linux system and builds a Linux binary. >>>>>> >>>>>>> As a side note: with MINGW64 I have managed to run configure phase >>>>>>> successfully for OpenJDK. The compile process has also started and >>>>>>> went for a while, but interestingly I run into some kind of race >>>>>>> conditions as make stopped with an error. Using LOG=debug I have fond >>>>>>> the failing line and then copying the failed command and pasting it >>>>>>> to the bash prompt it successfully generated the output target, and >>>>>>> then the build process run further when a similar situation happened. >>>>>>> Also pasting the failed command run in the bash without any problem, >>>>>>> and build continued? until the next. >>>>>>> >>>>>> Without seeing the errors I can't say much. I very much doubt that you >>>>>> are running with gcc as the compiler though. Configure isn't easily >>>>>> fooled into using a different compiler to what it prefers, and I would >>>>>> expect things to crash and burn pretty early if you actually did. >>>>>> >>>>>> /Erik >>>>>> >>>>>>> I have tried to run make JOBS=1, but did not help, strangely I have >>>>>>> still seen in the log make[3] and make[4] logs which suggested that >>>>>>> there are more than one make jobs were running. Also tried .configure >>>>>>> --with-output-sync=recurse without success (same symptoms) >>>>>>> >>>>>>> Let me know your thoughts. >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> Sent from Mail for >>>>>>> Windows 10 >>>>>>> >>>>>>> From: Magnus Ihse Bursie> >>>>>>> Sent: Wednesday, October 4, 2017 1:04 AM >>>>>>> To: Peter Budai>; >>>>>>> build-dev at openjdk.java.net >>>>>>> >> >>>>>>> k.java.net>> >>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>> >>>>>>> Actually, it wasn't so much remaining trouble. :-) I fired up msys2 >>>>>>> and >>>>>>> checked out where I left off. It turned out that the remaining snag >>>>>>> was >>>>>>> that msys2 tries to convert command lines automatically, from "unix" >>>>>>> style paths to "windows" style paths. Unfortunately, it does not do >>>>>>> this >>>>>>> very well and it breaks all sorts of things. We already have a >>>>>>> FIXPATH >>>>>>> solution in place which deals with this, so basically all I had to do >>>>>>> was disable this (by setting MSYS2_ARG_CONV_EXCL to "*"). However, >>>>>>> this >>>>>>> broke our cygpath replacement hack (!) so I had to disable it there. >>>>>>> Sigh. Anyway, with those fixes it ran and worked well. (I also >>>>>>> discovered and fixed a bug related to how we set up the FIXPATH >>>>>>> variable >>>>>>> on msys, but it only triggers in certain circumstances). >>>>>>> >>>>>>> With this patch I now jdk9 seems to build fine on msys2. It should >>>>>>> apply >>>>>>> cleanly on jdk9/jdk9. Since it turned out to be so trivial, I'll try >>>>>>> to >>>>>>> get it in in jdk10. >>>>>>> >>>>>>> Here's the patch if you want to apply it yourself: >>>>>>> >>>>>>> diff -r a08cbfc0e4ec common/autoconf/basics_windows.m4 >>>>>>> --- a/common/autoconf/basics_windows.m4 Thu Aug 03 18:56:56 2017 >>>>>>> +0000 >>>>>>> +++ b/common/autoconf/basics_windows.m4 Wed Oct 04 00:53:58 2017 >>>>>>> +0200 >>>>>>> @@ -42,7 +42,7 @@ >>>>>>> windows_path=`$CYGPATH -m "$unix_path"` >>>>>>> $1="$windows_path" >>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then >>>>>>> - windows_path=`cmd //c echo $unix_path` >>>>>>> + windows_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $unix_path` >>>>>>> $1="$windows_path" >>>>>>> fi >>>>>>> ]) >>>>>>> @@ -136,6 +136,16 @@ >>>>>>> fi >>>>>>> ]) >>>>>>> >>>>>>> +AC_DEFUN([BASIC_MSYS_UPDATE_FIXPATH], >>>>>>> +[ >>>>>>> + # Take all collected prefixes and turn them into a >>>>>>> -m/c/foo@/c/bar at ... command line >>>>>>> + # @ was chosen as separator to minimize risk of other tools >>>>>>> messing >>>>>>> around with it >>>>>>> + all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >>>>>>> + | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>>>> + fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >>>>>>> + FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>>>> +]) >>>>>>> + >>>>>>> AC_DEFUN([BASIC_FIXUP_PATH_MSYS], >>>>>>> [ >>>>>>> path="[$]$1" >>>>>>> @@ -143,7 +153,7 @@ >>>>>>> new_path="$path" >>>>>>> if test "x$has_colon" = x; then >>>>>>> # Not in mixed or Windows style, start by that. >>>>>>> - new_path=`cmd //c echo $path` >>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $path` >>>>>>> fi >>>>>>> >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>>>> @@ -155,6 +165,8 @@ >>>>>>> >>>>>>> # Save the first 10 bytes of this path to the storage, so >>>>>>> fixpath >>>>>>> can work. >>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>>>> "${new_path:0:10}") >>>>>>> + # We might need to re-evaluate FIXPATH. >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>>> ]) >>>>>>> >>>>>>> AC_DEFUN([BASIC_FIXUP_EXECUTABLE_CYGWIN], >>>>>>> @@ -293,7 +305,7 @@ >>>>>>> # Do not save /bin paths to all_fixpath_prefixes! >>>>>>> else >>>>>>> # Not in mixed or Windows style, start by that. >>>>>>> - new_path=`cmd //c echo $new_path` >>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $new_path` >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>>>> # Output is in $new_path >>>>>>> BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(new_path) >>>>>>> @@ -302,6 +314,8 @@ >>>>>>> >>>>>>> # Save the first 10 bytes of this path to the storage, so >>>>>>> fixpath >>>>>>> can work. >>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>>>> "${new_path:0:10}") >>>>>>> + # We might need to re-evaluate FIXPATH. >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>>> fi >>>>>>> ]) >>>>>>> >>>>>>> @@ -347,6 +361,10 @@ >>>>>>> WINDOWS_ENV_VENDOR='msys' >>>>>>> WINDOWS_ENV_VERSION="$MSYS_VERSION" >>>>>>> >>>>>>> + # Prohibit msys2 path conversion from trying to be >>>>>>> "intelligent", >>>>>>> and rely >>>>>>> + # on fixpath instead. >>>>>>> + export MSYS2_ARG_CONV_EXCL="*" >>>>>>> + >>>>>>> AC_MSG_CHECKING([msys root directory as unix-style path]) >>>>>>> # The cmd output ends with Windows line endings (CR/LF), >>>>>>> the grep >>>>>>> command will strip that away >>>>>>> MSYS_ROOT_PATH=`cd / ; cmd /c cd | $GREP ".*"` >>>>>>> @@ -391,10 +409,7 @@ >>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.msys; then >>>>>>> # Take all collected prefixes and turn them into a >>>>>>> -m/c/foo@/c/bar at ... command line >>>>>>> # @ was chosen as separator to minimize risk of other >>>>>>> tools >>>>>>> messing around with it >>>>>>> - all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" >>>>>>> \ >>>>>>> - | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>>>> - fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' >>>>>>> '@'` >>>>>>> - FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>>> fi >>>>>>> FIXPATH_SRC_W="$FIXPATH_SRC" >>>>>>> FIXPATH_BIN_W="$FIXPATH_BIN" >>>>>>> diff -r a08cbfc0e4ec common/autoconf/build-aux/config.sub >>>>>>> --- a/common/autoconf/build-aux/config.sub Thu Aug 03 18:56:56 >>>>>>> 2017 +0000 >>>>>>> +++ b/common/autoconf/build-aux/config.sub Wed Oct 04 00:53:58 >>>>>>> 2017 +0200 >>>>>>> @@ -30,7 +30,7 @@ >>>>>>> DIR=`dirname $0` >>>>>>> >>>>>>> # First, filter out everything that doesn't begin with >>>>>>> "aarch64-" >>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>>> . $DIR/autoconf-config.sub "$@" >>>>>>> # autoconf-config.sub exits, so we never reach here, but >>>>>>> just in >>>>>>> # case we do: >>>>>>> @@ -38,13 +38,17 @@ >>>>>>> fi >>>>>>> >>>>>>> while test $# -gt 0 ; do >>>>>>> - case $1 in >>>>>>> + case $1 in >>>>>>> -- ) # Stop option processing >>>>>>> shift; break ;; >>>>>>> aarch64-* ) >>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>>> sub_args="$sub_args $config" >>>>>>> shift; ;; >>>>>>> + *-msys ) >>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>>> + sub_args="$sub_args $config" >>>>>>> + shift; ;; >>>>>>> - ) # Use stdin as input. >>>>>>> sub_args="$sub_args $1" >>>>>>> shift; break ;; >>>>>>> diff -r a08cbfc0e4ec common/autoconf/spec.gmk.in >>>>>>> --- a/common/autoconf/spec.gmk.in Thu Aug 03 18:56:56 2017 +0000 >>>>>>> +++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 +0200 >>>>>>> @@ -120,6 +120,13 @@ >>>>>>> # On Windows, the Visual Studio toolchain needs the PATH to be >>>>>>> adjusted >>>>>>> # to include Visual Studio tools (this needs to be in >>>>>>> cygwin/msys >>>>>>> style). >>>>>>> export PATH:=@VS_PATH@ >>>>>>> + >>>>>>> +endif >>>>>>> + >>>>>>> +ifeq ($(OPENJDK_TARGET_OS_ENV), windows.msys) >>>>>>> + # On msys2, prohibit msys path conversion from trying to be >>>>>>> + # "intelligent", and rely on fixpath instead. >>>>>>> + export MSYS2_ARG_CONV_EXCL:=* >>>>>>> endif >>>>>>> >>>>>>> SYSROOT_CFLAGS := @SYSROOT_CFLAGS@ >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> On 2017-10-03 22:34, Magnus Ihse Bursie wrote: >>>>>>> >>>>>>>> I gave msys2 a shot some time ago, but it ended up too much trouble. >>>>>>>> I'll share some of my notes from that attempt, for what it's worth. >>>>>>>> >>>>>>>> To install package X/Y, run "pacman -S X/Y". Missing tools and >>>>>>>> packages where to find them: >>>>>>>> cmp: msys/diffutils >>>>>>>> tar: msys/tar >>>>>>>> make: msys/make >>>>>>>> unzip: msys/unzip >>>>>>>> zip: msys/zip >>>>>>>> >>>>>>>> config.sub reports msys as "x86_64-pc-mingw32" but msys2 as >>>>>>>> "x86_64-pc-msys". This patch adds postprocessing in "our" config.sub >>>>>>>> to report msys2 similar to msys. (Opinions, including my own :-) may >>>>>>>> vary if this really is the best way..) >>>>>>>> >>>>>>>> diff -r b88023f46daa common/autoconf/build-aux/config.sub >>>>>>>> --- a/common/autoconf/build-aux/config.sub Fri Jan 27 10:15:41 >>>>>>>> 2017 +0100 >>>>>>>> +++ b/common/autoconf/build-aux/config.sub Fri Feb 03 05:00:25 >>>>>>>> 2017 -0700 >>>>>>>> @@ -30,7 +30,7 @@ >>>>>>>> DIR=`dirname $0` >>>>>>>> >>>>>>>> # First, filter out everything that doesn't begin with >>>>>>>> "aarch64-" >>>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>>>> . $DIR/autoconf-config.sub "$@" >>>>>>>> # autoconf-config.sub exits, so we never reach here, but >>>>>>>> just in >>>>>>>> # case we do: >>>>>>>> @@ -45,6 +45,10 @@ >>>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>>>> sub_args="$sub_args $config" >>>>>>>> shift; ;; >>>>>>>> + *-msys ) >>>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>>>> + sub_args="$sub_args $config" >>>>>>>> + shift; ;; >>>>>>>> - ) # Use stdin as input. >>>>>>>> sub_args="$sub_args $1" >>>>>>>> shift; break ;; >>>>>>>> >>>>>>>> If I remember correctly, this got me past the configure stage at the >>>>>>>> time. >>>>>>>> >>>>>>>> I don't think it's very hard to get it to work on msys2, I just ran >>>>>>>> into one snag too many and didn't think msys2 would be used by >>>>>>>> anyone. >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> On 2017-10-03 17:20, Peter Budai wrote: >>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> According to >>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/commo >>>>>>>>> n/doc/building.html >>>>>>>>> >>>>>>>>> ?msys2 and the new Windows Subsystem for Linux (WSL) would likely >>>>>>>>> be >>>>>>>>> possible to support in a future version but that would require a >>>>>>>>> community effort to implement? >>>>>>>>> >>>>>>>>> I?d like to help making the OpenJDK 9 build working on msys2. What >>>>>>>>> is >>>>>>>>> the best way to move forward? Is there a similar effort in >>>>>>>>> progress? >>>>>>>>> >>>>>>>>> Thank you and best regards, >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> >>> > From thomas.stuefe at gmail.com Mon Nov 27 13:36:48 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Nov 2017 14:36:48 +0100 Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: Message-ID: Hi Peter, sorry if I came over too harsh. I gave this some thoughts and now I think getting the openjdk to build with gcc on Windows may be beneficial. Please find more comments inline. On Mon, Nov 27, 2017 at 12:12 PM, Peter Budai wrote: > MSYS2 or Cygwin should be similar from the technical point of view IMHO. > I?m familiar with MSYS2, but not with Cygwin. > > > I would prefer cygwin, as this is the officially adopted tool chain, and the work is already done and we need to maintain it anyway. I can see the value in having a different compiler, but not in having a different tool chain. Again, my personal opinions, others may think differently. A quick grep through our sources yields a number of hits on cygwin specific code. Some are really cygwin specific (e.g. calls to cygpath.exe to calculate the cygwin specific path) whereas others seem to just mean "any posix like windows environment as opposed to native windows cmd.exe". If we add msys2 to the list, would we not have to revise all these places? The big change as you called out is to make sure that gcc toolchain can > build successfully also for a Windows platform and produce a properly > working binaries. > > > > BTW I don?t belie there are big performance differences whether you are > building with GCC or MSC > > > Maybe you are right on the performance front, but I personally would still be careful using gcc as a compiler for production builds. On one hand I have an established tool chain with a company behind it I can pay for support if something goes wrong. On the other hand a quiet exotic solution for this platform. > Once again, please advise on what is the best way to move forward, or stop > this effort. > > It is not my place to advice you or to decide anything. People from the build group would have to decide whether we want to add support for msys2+gcc and whether we want to support it. ..Thomas > > Peter > > > ------------------------------ > *From:* Thomas St?fe > *Sent:* Thursday, November 23, 2017 10:36:07 PM > *To:* Lussier, Denis > *Cc:* Jonathan Gibbons; build-dev at openjdk.java.net; Peter Budai > > *Subject:* Re: Building OpenJDK9 on MSYS2 > > > > On Thu, Nov 23, 2017 at 12:40 AM, Lussier, Denis > wrote: > >> This is good stuff. Back in 2010 I got OpenJDK compiled and running on >> the >> Microsoft Toolchain. I never ran the jtreg tests, but, the binaries >> worked for running basic Tomcat but definitely not for trying to run >> Eclipse. >> >> These days I am a pretty big fan of MSYS2. In my personal experiences >> with >> building a PostgreSQL Windoze distribution, the MSYS2 binaries run a >> little >> faster than using the old MS Toolchain. >> >> https://www.openscg.com/2016/02/building-postgresql-on-windo >> ws-for-performance/ >> >> > Well, the linked article does claim the msys2 toolchain to be faster than > the Visual Studio, but there are no information I can see which compiler > and linker options were used. Without this information, the article is > difficult to take seriously. > > While I really respect these efforts, I regret seeing the fragmentation in > windows build environments. I rather have one well kept build environment > than of multiple buggy ones - and we have not that many folks interested in > the windows port in the first place (it always feels like second place to > the Posix platforms to me). The official build environment of the openjdk > windows port is Cygwin + Visual Studio. Even if we think the gcc toolchain > would be an attractive alternative to VS - why not just use the cygwin gcc > instead? That way we would at least share the same posix layer. > > Just my 5c. > > Kind Regards, Thomas > > > >> --Luss >> >> >> On Wed, Nov 22, 2017 at 4:28 PM, Jonathan Gibbons < >> jonathan.gibbons at oracle.com> wrote: >> >> > Peter, >> > >> > With over 120 :tier1 test failures, it would be worth understanding the >> > test failures as part of moving forward. There should normally be no >> :tier1 >> > test failures. >> > >> > -- Jon >> > >> > >> > >> > >> > On 11/22/2017 01:10 PM, Peter Budai wrote: >> > >> >> Let me give an update on the current status: >> >> >> >> * I have managed to build both the 64 and the 32-bit version. >> >> * The 64-bit version seems reasonable: >> >> >> >> >> >> >> >> ============================== >> >> >> >> Test summary - w64-bit >> >> >> >> ============================== >> >> >> >> TEST TOTAL PASS FAIL >> >> ERROR >> >> >> >> jtreg:jdk/test:tier1 1645 1610 34 >> 1 >> >>>> << >> >>>> jtreg:langtools/test:tier1 3907 3819 79 >> >>>> 9 << >> >>>> >> >>> jtreg:nashorn/test:tier1 0 0 >> 0 >> >> 0 >> >> >> >> jtreg:jaxp/test:tier1 0 0 0 >> >> 0 >> >> >> >> ============================== >> >> >> >> * However the 32-bit version of hotspot contains a bunch of inline >> >> assembly pieces which uses an MSC specific syntax, and my ASM >> knowledge is >> >> really limited. I have managed to get a many inline assembly codes >> from the >> >> Linux version, but there are few pieces where I was not able to find a >> good >> >> solution yet, so although the 32-bit version compiles, unfortunately >> it is >> >> not working >> >> * I have installed VS Express 2013 and made sure that the >> >> ?traditional? Microsoft toolchain is still working with the changes >> >> * My OCA has been processed >> >> >> >> I have a changeset which cleanly applies to JDK9 v181, but I recall you >> >> have mentioned earlier that you would like to consider this to JDK10 >> >> >> >> So what is the best way to open a PR for review? This page: >> >> http://openjdk.java.net/contribute/ says I should send the changeset >> as >> >> attachment, but earlier somebody mentioned here that attachments are >> >> removed from the developer mailing lists. >> >> >> >> Best regards, >> >> >> >> Peter >> >> >> >> From: Erik Joelsson >> >> Sent: Thursday, November 2, 2017 1:07 AM >> >> To: Peter Budai; Magnus Ihse >> >> Bursie >> >> Cc: build-dev at openjdk.java.net >> >> Subject: Re: Building OpenJDK9 on MSYS2 >> >> >> >> I would say a few hours is way too long for tier1, but it of course >> >> depends on the hardware used. We typically run it on windows in less >> >> than 30 minutes with concurrency set to 6. Not sure what concurrency >> you >> >> used by default. >> >> >> >> /Erik >> >> >> >> >> >> On 2017-10-27 04:33, Peter Budai wrote: >> >> >> >>> Hi Magnus, after a little poking I managed to install and use jtreg, >> >>> thanks for the guidance. >> >>> >> >>> Make run-test-tier1 resulted a pretty OK result for a first try, at >> >>> least for run-test-jdk: >> >>> Test results: passed: 1,610; failed: 34; error: 1 >> >>> It took a few hors to run ? is that normal? >> >>> >> >>> I?ll review the patchset, and then share that with you. >> >>> >> >>> P. >> >>> >> >>> From: Magnus Ihse Bursie >> >>> Sent: Thursday, October 26, 2017 11:00 AM >> >>> To: Peter Budai >> >>> Cc: build-dev at openjdk.java.net >> >>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>> >> >>> >> >>> On 2017-10-26 00:01, Peter Budai wrote: >> >>> OK, I have found what was missing, it was actually my fault with a >> >>> missing exception handler. >> >>> >> >>> So finally OpenJDK build has finished on Windows using gcc toolchain >> >>> running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it looks >> >>> promising: >> >>> ./build/windows-x86_64-normal-server-fastdebug/hotspot/varia >> >>> nt-server/libjvm/gtest/gtestLauncher.exe >> --jdk=/home/peterbud/jdk9/buil >> >>> d/windows-x86_64-normal-server-fastdebug/jdk >> >>> ?. >> >>> ?. >> >>> ?. >> >>> >> >>> [----------] Global test environment tear-down >> >>> [==========] 346 tests from 54 test cases ran. (3859 ms total) >> >>> [ PASSED ] 346 tests. >> >>> I'm impressed! :-) >> >>> >> >>> Would you care to share your current patchset, just to still my >> >>> curiosity? :-) >> >>> >> >>> >> >>> >> >>> What is the best way to test the current build more thoroughly? >> >>> "make run-test-tier1". As Erik says, you'll need jtreg, and call >> >>> "configure --with-jtreg=...". You can get it from the Adopt OpenJDK >> group >> >>> here: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccess >> >>> fulBuild/artifact/ >> >>> >> >>> /Magnus >> >>> >> >>> >> >>> P. >> >>> >> >>> From: Bob Vandette >> >>> Sent: Tuesday, October 24, 2017 8:10 PM >> >>> To: Peter Budai >> >>> Cc: David Holmes; Erik >> Joelsson> >>> erik.joelsson at oracle.com>; Magnus Ihse Bursie> >>> ie at oracle.com>; build-dev at openjdk.java.net> >>> build-dev at openjdk.java.net> >> >>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>> >> >>> Can you provide some details about your toolchain, processor and os >> plus >> >>> a dump of the native instructions around the SEGV. This might give us >> >>> enough info to be able to figure out what?s going on. >> >>> >> >>> Bob. >> >>> >> >>> On Oct 24, 2017, at 1:21 PM, Peter Budai > > >>> peterbudai at hotmail.com>> wrote: >> >>> >> >>> I get that error running in the debugger but also running >> >>> without/outside of the debugger as well. >> >>> >> >>> I saw the comment in the code about generating SEGV in function >> >>> generate_get_cpu_info(), however the debugger can execute that, and >> the >> >>> SEGV I experience is coming later in the >> VM_Version::get_processor_features() >> >>> function >> >>> >> >>> Peter >> >>> >> >>> From: Bob Vandette >> >>> Sent: Tuesday, October 24, 2017 6:28 PM >> >>> To: Peter Budai >> >>> Cc: David Holmes; Erik >> Joelsson> >>> erik.joelsson at oracle.com>; Magnus Ihse Bursie> >>> ie at oracle.com>; build-dev at openjdk.java.net> >>> build-dev at openjdk.java.net> >> >>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>> >> >>> Was this a SEGV while you were running the debugger? >> >>> >> >>> There is an intentional SEGV generated. This is used to determine if >> we >> >>> can use some of newer >> >>> CPU features. Try to allow the SEGV to continue to see if you run >> >>> normally. >> >>> >> >>> Bob. >> >>> >> >>> >> >>> On Oct 24, 2017, at 11:37 AM, Peter Budai > > >>>> :peterbudai at hotmail.com>> wrote: >> >>>> >> >>>> It seems that the compile is progressing well, I have 49 >> >>>> executables/tools and 38 compiled shared libraries already in the JDK >> >>>> folder. >> >>>> >> >>>> I have tried to run the product with the simplest ?java -version? >> >>>> command, however I get a SIGSEGV at get_cpu_info_stub() in >> >>>> vm_version_x86.cpp, VM_Version::get_processor_features() >> >>>> >> >>>> get_cpu_info_stub(&_cpuid_info); >> >>>> >> >>>> Thread 5 received signal SIGSEGV, Segmentation fault. >> >>>> 0x000000002d9a072f in ?? () >> >>>> >> >>>> I can debug using gdb, but unfortunately this is pure ASM, and my >> >>>> knowledge on this is close to 0. >> >>>> >> >>>> Any idea help or pointer how could I tackle this? >> >>>> >> >>>> Peter >> >>>> >> >>>> From: David Holmes >> >>>> Sent: Sunday, October 15, 2017 10:37 PM >> >>>> To: Peter Budai; Erik >> Joelsson> >>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie> magnus.ihse.burs >> >>>> ie at oracle.com> >> >>>> Cc: build-dev at openjdk.java.net> >>>> > >> >>>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>>> >> >>>> On 16/10/2017 12:41 AM, Peter Budai wrote: >> >>>> >> >>>>> A quick status update: >> >>>>> >> >>>>> * Hotspot successfully compiled without warnings >> >>>>> * I?d like to run the unit tests, but as I see ?make check? >> does >> >>>>> not work, and gtestlauncher expects a command line parameter jdk. >> Tried to >> >>>>> look up some documentation on this, but have not found. So the >> question is: >> >>>>> how can I run unit tests for hotspot? Do I need also JDK compiled >> for that? >> >>>>> Or the bootJDK is good enough? Any help would be appreciated. >> >>>>> >> >>>> Hotspot has to be tested as part of a full JDK - you can't load the >> JVM >> >>>> without having the "J" part :) >> >>>> >> >>>> You should be able to drop your built dll into an existing JDK 9 >> windows >> >>>> JDK and test it that way. >> >>>> >> >>>> David >> >>>> ----- >> >>>> >> >>>> * Also I?m making progress on compiling jdk, but there are some >> >>>>> very interesting solutions on windows linking which makes a bit more >> >>>>> difficult to compile with gcc: LIBS_windows contains sometimes >> simple >> >>>>> library names (which I believe is correct) and other times library >> names >> >>>>> with full path (which I believe is not the best solution). I?m >> trying to >> >>>>> rework those places and use simple library names and passing search >> path >> >>>>> for libraries -L (for gcc toolchain) and /LIBPATH: (for >> >>>>> Microsoft toolchain). Also I was surprised by a few manual function >> name >> >>>>> exports? >> >>>>> * jdk code base contains apparently more MSVC specific part, >> >>>>> many places casts/lack of casts are generating errors, static >> attributes >> >>>>> were missing etc. a bit tedious work. >> >>>>> >> >>>>> P. >> >>>>> >> >>>>> From: Erik Joelsson >> >>>>> Sent: Wednesday, October 11, 2017 4:16 PM >> >>>>> To: Magnus Ihse Bursie; Peter >> >>>>> Budai >> >>>>> Cc: build-dev at openjdk.java.net> >>>>> > >> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>>>> >> >>>>> Hello, >> >>>>> >> >>>>> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: >> >>>>> >> >>>>> For gcc, we let the compiler generate the .d file. For the Microsoft >> >>>>> tool chain, we use a clever sed script to extract and create it >> ourself. >> >>>>> >> >>>>> I think that logic is checking for "Windows", not "Microsoft". That >> >>>>> might be your cause of trouble. >> >>>>> >> >>>>> Look in NativeCompilation.gmk. >> >>>>> >> >>>>> That was my initial thought as well, but we do correctly check for >> >>>>> microsoft. Also it's not the .d files that are the problem. As >> Peter just >> >>>>> wrote, they look fine. It's the .d.target files which we create >> using the >> >>>>> same technique on all platforms. What we don't account for is the >> compiler >> >>>>> putting Windows mixed paths in the .d files. >> >>>>> >> >>>>> /Magnus >> >>>>> >> >>>>> 11 okt. 2017 kl. 14:43 skrev Peter Budai > >>>>> >: >> >>>>> Hi Erik, >> >>>>> >> >>>>> The .d file looks like this: >> >>>>> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >> >>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: \ >> >>>>> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp >> \ >> >>>>> >> >>>>> I have checked .d.targets file, and looks like it has the first line >> >>>>> has not been deleted, and the file names below are also wrong: >> >>>>> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-serve >> >>>>> r-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj : : >> >>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp : >> >>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : >> >>>>> >> >>>>> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by >> >>>>> the ?C:/? >> >>>>> -e 's/^[^:]*: *//' >> >>>>> >> >>>>> Yes, that does indeed look like the problem. I suppose the regexp is >> >>>>> unnecessarily strict. It should be ok to rewrite it as something >> like this: >> >>>>> -e 's/^.*: *//' >> >>>>> >> >>>>> Basically just make sure it ends with : and any number of spaces. >> >>>>> >> >>>>> /Erik >> >>>>> >> >>>>> >> >>>>> >> >>>>> Peter >> >>>>> >> >>>>> Sent from Mail for >> >>>>> Windows 10 >> >>>>> >> >>>>> From: Erik Joelsson >> >>>>> Sent: Wednesday, October 11, 2017 12:16 PM >> >>>>> To: Peter Budai; Magnus Ihse >> >>>>> Bursie; >> >>>>> build-dev at openjdk.java.net> >> >>>>> build-dev at openjdk.java.net> >> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>>>> >> >>>>> >> >>>>> Hello Peter, >> >>>>> >> >>>>> On 2017-10-11 00:18, Peter Budai wrote: >> >>>>> Thanks Magnus & Erik >> >>>>> >> >>>>> First thanks for your support and kind words! >> >>>>> >> >>>>> Magnus, I have checked .bash_profile, .bashrc but they seem to be >> >>>>> empty (everything is commented out). You can check with a default >> MSYS2 >> >>>>> install, I have not changed these files at all. If you find thee >> something >> >>>>> specific I can give a try here as well. >> >>>>> >> >>>>> Let me give also a quick status update, where am I with building >> >>>>> hotspot: >> >>>>> ? I guess its still the beginning, but I have managed to >> compile >> >>>>> jvm.dll with almost 700 object file: with debug info the dll is >> around 700 >> >>>>> MB ? >> >>>>> ? I made only surgical, minimal changes to the source, and so >> >>>>> far it looks reasonable. I have encountered 3 scenarios where >> changes were >> >>>>> necessary: >> >>>>> o When in makefiles conditionals were using assuming that if >> >>>>> target_os is windows then it is visual studio compiler/linker. >> Obviously >> >>>>> these conditionals had to be reviewed in a few places and if >> necessary were >> >>>>> changes to check the toolchain=Microsoft >> >>>>> These are not surprising and should be pretty straight forward to >> fix >> >>>>> and it seems you know what to do. >> >>>>> >> >>>>> >> >>>>> ? >> >>>>> o I got a few warnings as gcc 7.2 uncovered some code problems in >> >>>>> windows specific codes, where before that MSVC I guess did not say >> a word? >> >>>>> To get around this you can configure with >> --disable-warnings-as-errors >> >>>>> until you get things working properly. This is commonly needed when >> using >> >>>>> compiler versions that we normally don't use. >> >>>>> >> >>>>> >> >>>>> ? >> >>>>> o And I had like 6-7 places where the code was using MSVC specific >> >>>>> __try ? __except structures which gcc does not know. Do you have a >> >>>>> suggestion how to approach them? I can do ugly #ifdefs (I would >> avoid that) >> >>>>> but I have also seen some solutions to replace them with a code >> which gcc >> >>>>> can compile (http://www.programmingunlimit >> ed.net/siteexec/content.cgi? >> >>>>> page=mingw-seh ) ? but before doing that though I would ask first >> >>>>> you on the purpose of those >> >>>>> This kind of question is probably best to bring to the hotspot >> mailing >> >>>>> list. >> >>>>> ? What bothers me is that I was not able to do incremental >> >>>>> builds: when an error occurs, and build stops, then after making >> change in >> >>>>> the CPP source the build cannot continue, I always got an error >> message: >> >>>>> >> >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >> >>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse. >> d.targets:1: >> >>>>> *** missing target pattern. Stop. >> >>>>> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 >> >>>>> >> >>>>> If I do a ?make clean? and restart the build then it nicely >> compiles. >> >>>>> >> >>>>> Question 1: Is there a way to resume such builds without ?make >> clean?? >> >>>>> Well, incremental builds is supposed to work well. We have several >> >>>>> extra tricks in there to handle cases where normal make builds >> would fail. >> >>>>> The *.d.targets files is one such trick and it seems to backfire >> for you. >> >>>>> The contents of that file should be something like: >> >>>>> >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : >> >>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : >> >>>>> >> >>>>> Basically an empty rule for each dependency for the corresponding >> >>>>> object file. Declaring these rules makes it possible to delete >> source files >> >>>>> without having to build clean. It seems your file is not generated >> >>>>> correctly so please have a look inside it. The file is in >> >>>>> make/common/NativeCompilation.gmk, look for >> >>>>> DEPENDENCY_TARGET_SED_PATTERN. >> >>>>> >> >>>>> >> >>>>> >> >>>>> Question 2: What would be the best way to submit/share the patches >> for >> >>>>> your thorough review? >> >>>>> >> >>>>> Well, first of all, have you signed the OCA? >> >>>>> >> >>>>> As for publishing patches and reviews, there is a bit of chicken and >> >>>>> egg problem. Once you become an "author" in any of the OpenJDK >> projects, >> >>>>> you get a user name and should be able to publish reviews on >> >>>>> cr.openjdk.java.net> >>>>> penjdk.java.net> >>>>> k.java.net/%3e%3chttp:/cr.openjdk.java.net%3chttp:/cr. >> >>>>> openjdk.java.net/>>>. Before that, if the patch is small, it can be >> >>>>> posted inline in an email to the list. If it's large, you will need >> a >> >>>>> current OpenJDK user to host it for you. At least that's how I >> understand >> >>>>> it. Hopefully someone who knows the process better can chime in >> here. >> >>>>> >> >>>>> I should also let you know that getting this into JDK 9 is most >> likely >> >>>>> not going to happen. AFAIK we are only doing security updates for >> 9. It >> >>>>> would have to go into the currently active release. I should also >> warn you >> >>>>> that new ports generally need a certain amount of backing to be >> accepted. >> >>>>> It may be that this would have to live in a porting side project. >> Hopefully >> >>>>> someone who knows this better can chime in here as well. >> >>>>> >> >>>>> /Erik >> >>>>> >> >>>>> >> >>>>> P. >> >>>>> >> >>>>> Sent from Mail for >> >>>>> Windows 10 >> >>>>> >> >>>>> From: Magnus Ihse Bursie >> >>>>> Sent: Tuesday, October 10, 2017 10:04 AM >> >>>>> To: Peter Budai; Erik >> Joelsson> >>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net> >>>>> build-dev at openjdk.java.net> >> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>>>> >> >>>>> On 2017-10-07 10:14, Peter Budai wrote: >> >>>>> The configure of OpenJDK overwrites the SHELL. Actually it is using >> >>>>> bash, but for the arguments it was using ?-e -o pipefail?. I have >> figured >> >>>>> that for MSYS2 bash what is needed as bash arguments is ?-e -l -c -o >> >>>>> pipefail? >> >>>>> >> >>>>> That looks like solving this problem, and now the real issues are >> >>>>> surfacing. >> >>>>> >> >>>>> FWIW, "-l" makes bash behave like a login shell. Most likely you are >> >>>>> changing bash's behavior in one of your login scripts, and that >> change is >> >>>>> what's really needed. >> >>>>> >> >>>>> /Magnus >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> Peter >> >>>>> >> >>>>> From: Peter Budai >> >>>>> Sent: Friday, October 6, 2017 6:43 PM >> >>>>> To: Magnus Ihse Bursie; Erik >> >>>>> Joelsson; >> build-dev at openjdk.java.net >> >>>>> > .java.net> >> >>>>> Subject: RE: Building OpenJDK9 on MSYS2 >> >>>>> >> >>>>> Magnus, >> >>>>> >> >>>>> I have followed your suggestion and removed the fixpath prefixes >> from >> >>>>> gcc related compile tools, and left only the fixpath prefix _only_ >> for the >> >>>>> Boot JDK related tools in place. >> >>>>> >> >>>>> 1) As I follow the process, all java and javac related compile >> >>>>> steps are running properly >> >>>>> 2) When the process reaches gcc related steps I got the error >> >>>>> message at the same place as before (no fixpath). If I execute that >> command >> >>>>> from the bash prompt, it creates the output: >> >>>>> >> >>>>> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >> >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >> >>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >> >>>>> /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/j >> >>>>> dk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegist >> ry.java.template >> >>>>> 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | >> >>>>> /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e >> 's/@@START_HERE@@/\/\/ >> >>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e >> 's/^#.*//' >> >>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >> >>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption >> >>>>> Registry.java >> >>>>> >> >>>>> As I have mentioned the parameters are replaced by the bash >> >>>>> automatically >> >>>>> 3) Then build continues, then little later stops at a super >> >>>>> simple command: >> >>>>> >> >>>>> mv /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >> >>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp >> >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >> >>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java >> >>>>> Needless to say, the ByteBuffer.java.tmp file DOES >> exist. >> >>>>> And running the above command from the bash works, and build >> continues. >> >>>>> 4) A few similar cases (stops) with DirectByteBuffer and >> >>>>> DirectByteBufferR >> >>>>> >> >>>>> >> >>>>> Currently I try to explore how that might relate to the MSYS2 bash >> and >> >>>>> make, somehow it behaves differently >> >>>>> >> >>>>> If you have any other suggestion, let me know. >> >>>>> >> >>>>> Best regards, >> >>>>> >> >>>>> Peter >> >>>>> >> >>>>> From: Peter Budai >> >>>>> Sent: Thursday, October 5, 2017 3:52 PM >> >>>>> To: Magnus Ihse Bursie; Erik >> >>>>> Joelsson; >> build-dev at openjdk.java.net >> >>>>> > .java.net> >> >>>>> Subject: RE: Building OpenJDK9 on MSYS2 >> >>>>> >> >>>>> Hi Magnus, >> >>>>> >> >>>>> So first of all, here is the current patch, which I was not able to >> >>>>> attach: https://pastebin.com/pwT4Ynxc >> >>>>> >> >>>>> That's surprising, since gcc is prefixed with fixpath, which it >> should >> >>>>>>> not. >> >>>>>>> >> >>>>>> Actually you DO need fixpath IMHO. >> >>>>> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), >> >>>>> which is a fully functional Windows executable, which expects >> Windows >> >>>>> formatted path arguments. >> >>>>> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see >> >>>>> that patch), none of the command line arguments are converted from >> the >> >>>>> unix path to Windows, but fixpath does that conversion. There is a >> wiki >> >>>>> describing more details on this: >> >>>>> https://github.com/msys2/msys2/wiki/Porting#user-content- >> >>>>> filesystem-namespaces >> >>>>> >> >>>>> >> >>>>> >> >>>>> I have a hard time believing this is a race condition. On the other >> >>>>>>> hand, this stuff is weird, we're misusing the C preprocessor to >> process >> >>>>>>> defines in java code, so I'm not surprised it breaks down. >> >>>>>>> I don't know why it succeeded when run on the command line, >> though. >> >>>>>>> >> >>>>>> When I execute that command from the bash command line there is no >> >>>>> EXPORT MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic >> >>>>> conversion of the arguments. Maybe it has something to do how >> fixpath does >> >>>>> CreateProcess? >> >>>>> >> >>>>> Does that help? >> >>>>> >> >>>>> Best regards, >> >>>>> >> >>>>> Peter >> >>>>> >> >>>>> Sent from Mail for >> >>>>> Windows 10 >> >>>>> >> >>>>> From: Magnus Ihse Bursie >> >>>>> Sent: Thursday, October 5, 2017 12:13 PM >> >>>>> To: Peter Budai; Erik >> Joelsson> >>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net> >>>>> build-dev at openjdk.java.net> >> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>>>> >> >>>>> >> >>>>> On 2017-10-05 11:59, Peter Budai wrote: >> >>>>> Hi Magnus and Erik, >> >>>>> >> >>>>> I really appreciate your quick feedback. I assumed that it won?t be >> >>>>> easy, but I just don?t feel I should give up now - maybe later >> when I see >> >>>>> the real scale of work. So bear with me for a time being. >> >>>>> >> >>>>> Attached is a patch which already includes Magnus? changes, plus a >> few >> >>>>> which I have added: >> >>>>> ? basically enabling gcc for windows, >> >>>>> ? and modifying a logic for compiling fixpath (before that it >> >>>>> was using hard-coded MS VSC compile flags) >> >>>>> >> >>>>> Actually, you must make sure fixpath is *not* used for the >> toolchain, >> >>>>> since gcc uses unix style paths. >> >>>>> (However, other tools such as java will still need it.) >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> So here is what I have as the result of configure: >> >>>>> ==================================================== >> >>>>> The existing configuration has been successfully updated in >> >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >> >>>>> ver-release >> >>>>> using configure arguments '--disable-freetype-bundling >> >>>>> --disable-javac-server'. >> >>>>> >> >>>>> Configuration summary: >> >>>>> * Debug level: release >> >>>>> * HS debug level: product >> >>>>> * JDK variant: normal >> >>>>> * JVM variants: server >> >>>>> * OpenJDK target: OS: windows, CPU architecture: x86, address >> length: >> >>>>> 64 >> >>>>> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) >> >>>>> >> >>>>> Tools summary: >> >>>>> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) >> >>>>> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime >> >>>>> Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server >> VM (build >> >>>>> 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) >> >>>>> * Toolchain: gcc (GNU Compiler Collection) >> >>>>> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) >> >>>>> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) >> >>>>> >> >>>>> Build performance summary: >> >>>>> * Cores to use: 4 >> >>>>> * Memory limit: 16216 MB >> >>>>> >> >>>>> Its clear says that the toolchain is gcc 7.2 (BTW there is no Visual >> >>>>> Studio on this machine) >> >>>>> >> >>>>> Now for the details of the config log, you can see here: >> >>>>> https://pastebin.com/MN2ZYcHH >> >>>>> >> >>>>> And about the build process and the error I get: >> >>>>> >> >>>>> $ make JOBS=1 >> >>>>> Building target 'default (exploded-image)' in configuration >> >>>>> 'windows-x86_64-normal-server-release' >> >>>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >> >>>>> Compiling 17 properties into resource bundles for jdk.compiler >> >>>>> Parsing 1 properties into enum-like class for jdk.compiler >> >>>>> Compiling 19 properties into resource bundles for jdk.javadoc >> >>>>> Compiling 12 properties into resource bundles for jdk.jdeps >> >>>>> Compiling 7 properties into resource bundles for jdk.jshell >> >>>>> Compiling 117 files for BUILD_INTERIM_java.compiler >> >>>>> Compiling 396 files for BUILD_INTERIM_jdk.compiler >> >>>>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps >> >>>>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc >> >>>>> Note: Some input files use or override a deprecated API. >> >>>>> Note: Recompile with -Xlint:deprecation for details. >> >>>>> Compiling 159 files for BUILD_TOOLS_JDK >> >>>>> Note: Some input files use unchecked or unsafe operations. >> >>>>> Note: Recompile with -Xlint:unchecked for details. >> >>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b >> >>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav >> >>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >> >>>>> make[3]: *** Deleting file '/C/msys64/home/peterbud/jdk9/ >> >>>>> build/windows-x86_64-normal-server-release/support/gensrc/ja >> >>>>> va.base/sun/nio/ch/SocketOptionRegistry.java' >> >>>>> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 >> >>>>> >> >>>>> ERROR: Build failed for target 'default (exploded-image)' in >> >>>>> configuration 'windows-x86_64-normal-server-release' (exit code 2) >> >>>>> >> >>>>> No indication of failed target found. >> >>>>> Hint: Try searching the build log for '] Error'. >> >>>>> Hint: See common/doc/building.html#troubleshooting for assistance. >> >>>>> >> >>>>> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 >> >>>>> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 >> >>>>> >> >>>>> If I run here >> >>>>> make JOBS=1 LOG=debug >> >>>>> The failing line seems to be this: >> >>>>> >> >>>>> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >> >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >> >>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >> >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >> >>>>> ver-release/configure-support/bin/fixpath.exe >> >>>>> -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x >> c >> >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >> >>>>> /sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep >> -v >> >>>>> '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk >> >>>>> '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ >> >>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e >> 's/^#.*//' >> >>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >> >>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption >> >>>>> Registry.java >> >>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b >> >>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav >> >>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >> >>>>> >> >>>>> Now the interesting is: if I copy this line above to the bash >> prompt, >> >>>>> it runs without problem, and the file support/gensrc/java.base/sun/n >> >>>>> io/ch/SocketOptionRegistry.java >> >>>>> That's surprising, since gcc is prefixed with fixpath, which it >> should >> >>>>> not. >> >>>>> >> >>>>> I have a hard time believing this is a race condition. On the other >> >>>>> hand, this stuff is weird, we're misusing the C preprocessor to >> process >> >>>>> defines in java code, so I'm not suprised it breaks down. I don't >> know why >> >>>>> it succeeded when run on the command line, though. My suggestion is >> to just >> >>>>> do some quick and dirty hack around this: take the file you manage >> to >> >>>>> generate and just copy it in during the build instead. If you can >> get round >> >>>>> this, you might start seeing some *real* problems. :-) >> >>>>> >> >>>>> Also, my suggestion is that you try running "make hotspot" to cut to >> >>>>> the chase. Compiling hotspot will likely be the hardest thing. Or >> even >> >>>>> "make -k hotspot" to get an assessment of the amount of work ahead >> of you. >> >>>>> >> >>>>> /Magnus >> >>>>> Is produced. >> >>>>> >> >>>>> Then I can again issue >> >>>>> make JOBS=1 LOG=debug >> >>>>> >> >>>>> And the compile process is being continued, until a similar error >> pops >> >>>>> up with a different generated file. I have an assumption that this >> happens >> >>>>> because make is still running parallel jobs, despite JOBS=1 but I?m >> not >> >>>>> sure. >> >>>>> >> >>>>> How could I best tackle this? >> >>>>> >> >>>>> Thank you and best regards, >> >>>>> >> >>>>> Peter >> >>>>> >> >>>>> Sent from Mail for >> >>>>> Windows 10 >> >>>>> >> >>>>> From: Magnus Ihse Bursie >> >>>>> Sent: Thursday, October 5, 2017 11:33 AM >> >>>>> To: Erik Joelsson; Peter >> >>>>> Budai; build-dev at openjdk.java.net >> > >>>>> lto:build-dev at openjdk.java.net> >> >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>>>> >> >>>>> On 2017-10-05 10:10, Erik Joelsson wrote: >> >>>>> >> >>>>>> Hello Peter, >> >>>>>> >> >>>>>> >> >>>>>> On 2017-10-04 21:15, Peter Budai wrote: >> >>>>>> >> >>>>>>> Hi Magnus, >> >>>>>>> >> >>>>>>> Thanks for the quick reply I?ll check these patches with msys2. >> >>>>>>> >> >>>>>>> Let me specify with more details what I?d like to achieve: I?d >> like >> >>>>>>> to build OpenJDK9 with MSYS2 MINGW64 environment using gcc >> toolchain. >> >>>>>>> (I?m not sure how familiar are you with MSYS2, but there are 3 >> >>>>>>> different environments: MSYS2, MINGW32 and MINGW64). In theory >> >>>>>>> MINGW64 with gcc is the closes you can get on Windows platform as >> a >> >>>>>>> gcc unix like build environment, which produces still a native >> 64-bit >> >>>>>>> executable on Windows. >> >>>>>>> >> >>>>>>> I?m not very familiar with OpenJDK yet, so therefore I?d like to >> hear >> >>>>>>> your opinion: how realistic is that? >> >>>>>>> >> >>>>>> Sorry to disappoint, but I would say that requires major work. >> There >> >>>>>> is a strong historic assumption that windows builds are done using >> >>>>>> Visual Studio. We have abstracted away some of it in configure (see >> >>>>>> TOOLCHAIN_TYPE), but it's very far from enough to change compiler >> >>>>>> environment for a Windows build. The native sources are also bound >> to >> >>>>>> make a lot of such assumptions. I would expect the changes needed >> to >> >>>>>> be in the thousands of lines of code. >> >>>>>> >> >>>>> I agree that it requires hard work (even if "thousands" might be an >> >>>>> overestimation I think, but "hundreds" is not enough, so it's the >> right >> >>>>> magnitude). On the other hand, it would be really good if we did >> sort >> >>>>> things out, so that we had proper conditions based on OS vs >> >>>>> compiler/toolchain. >> >>>>> >> >>>>> If you really want to start, the first thing is to patch >> toolchain.m4 >> >>>>> to >> >>>>> VALID_TOOLCHAINS_windows="microsoft gcc" >> >>>>> and then call configure using "bash configure >> >>>>> --with-toolchain-type=gcc". >> >>>>> >> >>>>> As Erik, I doubt you will come very far before things starts >> tumbling >> >>>>> down. >> >>>>> >> >>>>> When we say supporting the build in msys2 instead of cygwin, we just >> >>>>>> mean using msys2 as the unix emulating layer for our tools like >> >>>>>> make/bash/grep/sed etc. >> >>>>>> >> >>>>>> One think I have done successfully is running the build in WSL >> >>>>>> (Windows Subsystem for Linux), but that isn't all that helpful as >> WSL >> >>>>>> for practical purposes is more or less like running Linux in a VM, >> so >> >>>>>> the build sees a Linux system and builds a Linux binary. >> >>>>>> >> >>>>>>> As a side note: with MINGW64 I have managed to run configure phase >> >>>>>>> successfully for OpenJDK. The compile process has also started and >> >>>>>>> went for a while, but interestingly I run into some kind of race >> >>>>>>> conditions as make stopped with an error. Using LOG=debug I have >> fond >> >>>>>>> the failing line and then copying the failed command and pasting >> it >> >>>>>>> to the bash prompt it successfully generated the output target, >> and >> >>>>>>> then the build process run further when a similar situation >> happened. >> >>>>>>> Also pasting the failed command run in the bash without any >> problem, >> >>>>>>> and build continued? until the next. >> >>>>>>> >> >>>>>> Without seeing the errors I can't say much. I very much doubt that >> you >> >>>>>> are running with gcc as the compiler though. Configure isn't easily >> >>>>>> fooled into using a different compiler to what it prefers, and I >> would >> >>>>>> expect things to crash and burn pretty early if you actually did. >> >>>>>> >> >>>>>> /Erik >> >>>>>> >> >>>>>>> I have tried to run make JOBS=1, but did not help, strangely I >> have >> >>>>>>> still seen in the log make[3] and make[4] logs which suggested >> that >> >>>>>>> there are more than one make jobs were running. Also tried >> .configure >> >>>>>>> --with-output-sync=recurse without success (same symptoms) >> >>>>>>> >> >>>>>>> Let me know your thoughts. >> >>>>>>> >> >>>>>>> Best regards, >> >>>>>>> >> >>>>>>> Peter >> >>>>>>> >> >>>>>>> Sent from Mail >> for >> >>>>>>> Windows 10 >> >>>>>>> >> >>>>>>> From: Magnus Ihse Bursie >> >>>>>>> Sent: Wednesday, October 4, 2017 1:04 AM >> >>>>>>> To: Peter Budai; >> >>>>>>> build-dev at openjdk.java.net> >>>>>>> >> >>>>>>> k.java.net> >> >>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >> >>>>>>> >> >>>>>>> Actually, it wasn't so much remaining trouble. :-) I fired up >> msys2 >> >>>>>>> and >> >>>>>>> checked out where I left off. It turned out that the remaining >> snag >> >>>>>>> was >> >>>>>>> that msys2 tries to convert command lines automatically, from >> "unix" >> >>>>>>> style paths to "windows" style paths. Unfortunately, it does not >> do >> >>>>>>> this >> >>>>>>> very well and it breaks all sorts of things. We already have a >> >>>>>>> FIXPATH >> >>>>>>> solution in place which deals with this, so basically all I had >> to do >> >>>>>>> was disable this (by setting MSYS2_ARG_CONV_EXCL to "*"). However, >> >>>>>>> this >> >>>>>>> broke our cygpath replacement hack (!) so I had to disable it >> there. >> >>>>>>> Sigh. Anyway, with those fixes it ran and worked well. (I also >> >>>>>>> discovered and fixed a bug related to how we set up the FIXPATH >> >>>>>>> variable >> >>>>>>> on msys, but it only triggers in certain circumstances). >> >>>>>>> >> >>>>>>> With this patch I now jdk9 seems to build fine on msys2. It should >> >>>>>>> apply >> >>>>>>> cleanly on jdk9/jdk9. Since it turned out to be so trivial, I'll >> try >> >>>>>>> to >> >>>>>>> get it in in jdk10. >> >>>>>>> >> >>>>>>> Here's the patch if you want to apply it yourself: >> >>>>>>> >> >>>>>>> diff -r a08cbfc0e4ec common/autoconf/basics_windows.m4 >> >>>>>>> --- a/common/autoconf/basics_windows.m4 Thu Aug 03 18:56:56 >> 2017 >> >>>>>>> +0000 >> >>>>>>> +++ b/common/autoconf/basics_windows.m4 Wed Oct 04 00:53:58 >> 2017 >> >>>>>>> +0200 >> >>>>>>> @@ -42,7 +42,7 @@ >> >>>>>>> windows_path=`$CYGPATH -m "$unix_path"` >> >>>>>>> $1="$windows_path" >> >>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then >> >>>>>>> - windows_path=`cmd //c echo $unix_path` >> >>>>>>> + windows_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $unix_path` >> >>>>>>> $1="$windows_path" >> >>>>>>> fi >> >>>>>>> ]) >> >>>>>>> @@ -136,6 +136,16 @@ >> >>>>>>> fi >> >>>>>>> ]) >> >>>>>>> >> >>>>>>> +AC_DEFUN([BASIC_MSYS_UPDATE_FIXPATH], >> >>>>>>> +[ >> >>>>>>> + # Take all collected prefixes and turn them into a >> >>>>>>> -m/c/foo@/c/bar at ... command line >> >>>>>>> + # @ was chosen as separator to minimize risk of other tools >> >>>>>>> messing >> >>>>>>> around with it >> >>>>>>> + all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >> >>>>>>> + | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >> >>>>>>> + fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >> >>>>>>> + FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >> >>>>>>> +]) >> >>>>>>> + >> >>>>>>> AC_DEFUN([BASIC_FIXUP_PATH_MSYS], >> >>>>>>> [ >> >>>>>>> path="[$]$1" >> >>>>>>> @@ -143,7 +153,7 @@ >> >>>>>>> new_path="$path" >> >>>>>>> if test "x$has_colon" = x; then >> >>>>>>> # Not in mixed or Windows style, start by that. >> >>>>>>> - new_path=`cmd //c echo $path` >> >>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $path` >> >>>>>>> fi >> >>>>>>> >> >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >> >>>>>>> @@ -155,6 +165,8 @@ >> >>>>>>> >> >>>>>>> # Save the first 10 bytes of this path to the storage, so >> >>>>>>> fixpath >> >>>>>>> can work. >> >>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >> >>>>>>> "${new_path:0:10}") >> >>>>>>> + # We might need to re-evaluate FIXPATH. >> >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >> >>>>>>> ]) >> >>>>>>> >> >>>>>>> AC_DEFUN([BASIC_FIXUP_EXECUTABLE_CYGWIN], >> >>>>>>> @@ -293,7 +305,7 @@ >> >>>>>>> # Do not save /bin paths to all_fixpath_prefixes! >> >>>>>>> else >> >>>>>>> # Not in mixed or Windows style, start by that. >> >>>>>>> - new_path=`cmd //c echo $new_path` >> >>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $new_path` >> >>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >> >>>>>>> # Output is in $new_path >> >>>>>>> BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(new_path) >> >>>>>>> @@ -302,6 +314,8 @@ >> >>>>>>> >> >>>>>>> # Save the first 10 bytes of this path to the storage, so >> >>>>>>> fixpath >> >>>>>>> can work. >> >>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >> >>>>>>> "${new_path:0:10}") >> >>>>>>> + # We might need to re-evaluate FIXPATH. >> >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >> >>>>>>> fi >> >>>>>>> ]) >> >>>>>>> >> >>>>>>> @@ -347,6 +361,10 @@ >> >>>>>>> WINDOWS_ENV_VENDOR='msys' >> >>>>>>> WINDOWS_ENV_VERSION="$MSYS_VERSION" >> >>>>>>> >> >>>>>>> + # Prohibit msys2 path conversion from trying to be >> >>>>>>> "intelligent", >> >>>>>>> and rely >> >>>>>>> + # on fixpath instead. >> >>>>>>> + export MSYS2_ARG_CONV_EXCL="*" >> >>>>>>> + >> >>>>>>> AC_MSG_CHECKING([msys root directory as unix-style path]) >> >>>>>>> # The cmd output ends with Windows line endings (CR/LF), >> >>>>>>> the grep >> >>>>>>> command will strip that away >> >>>>>>> MSYS_ROOT_PATH=`cd / ; cmd /c cd | $GREP ".*"` >> >>>>>>> @@ -391,10 +409,7 @@ >> >>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.msys; then >> >>>>>>> # Take all collected prefixes and turn them into a >> >>>>>>> -m/c/foo@/c/bar at ... command line >> >>>>>>> # @ was chosen as separator to minimize risk of other >> >>>>>>> tools >> >>>>>>> messing around with it >> >>>>>>> - all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@: >> >@}" >> >>>>>>> \ >> >>>>>>> - | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >> >>>>>>> - fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' >> >>>>>>> '@'` >> >>>>>>> - FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >> >>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >> >>>>>>> fi >> >>>>>>> FIXPATH_SRC_W="$FIXPATH_SRC" >> >>>>>>> FIXPATH_BIN_W="$FIXPATH_BIN" >> >>>>>>> diff -r a08cbfc0e4ec common/autoconf/build-aux/config.sub >> >>>>>>> --- a/common/autoconf/build-aux/config.sub Thu Aug 03 18:56:56 >> >>>>>>> 2017 +0000 >> >>>>>>> +++ b/common/autoconf/build-aux/config.sub Wed Oct 04 00:53:58 >> >>>>>>> 2017 +0200 >> >>>>>>> @@ -30,7 +30,7 @@ >> >>>>>>> DIR=`dirname $0` >> >>>>>>> >> >>>>>>> # First, filter out everything that doesn't begin with >> >>>>>>> "aarch64-" >> >>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >> >>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >> >>>>>>> . $DIR/autoconf-config.sub "$@" >> >>>>>>> # autoconf-config.sub exits, so we never reach here, but >> >>>>>>> just in >> >>>>>>> # case we do: >> >>>>>>> @@ -38,13 +38,17 @@ >> >>>>>>> fi >> >>>>>>> >> >>>>>>> while test $# -gt 0 ; do >> >>>>>>> - case $1 in >> >>>>>>> + case $1 in >> >>>>>>> -- ) # Stop option processing >> >>>>>>> shift; break ;; >> >>>>>>> aarch64-* ) >> >>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >> >>>>>>> sub_args="$sub_args $config" >> >>>>>>> shift; ;; >> >>>>>>> + *-msys ) >> >>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >> >>>>>>> + sub_args="$sub_args $config" >> >>>>>>> + shift; ;; >> >>>>>>> - ) # Use stdin as input. >> >>>>>>> sub_args="$sub_args $1" >> >>>>>>> shift; break ;; >> >>>>>>> diff -r a08cbfc0e4ec common/autoconf/spec.gmk.in >> >>>>>>> --- a/common/autoconf/spec.gmk.in Thu Aug 03 18:56:56 2017 >> +0000 >> >>>>>>> +++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 >> +0200 >> >>>>>>> @@ -120,6 +120,13 @@ >> >>>>>>> # On Windows, the Visual Studio toolchain needs the PATH >> to be >> >>>>>>> adjusted >> >>>>>>> # to include Visual Studio tools (this needs to be in >> >>>>>>> cygwin/msys >> >>>>>>> style). >> >>>>>>> export PATH:=@VS_PATH@ >> >>>>>>> + >> >>>>>>> +endif >> >>>>>>> + >> >>>>>>> +ifeq ($(OPENJDK_TARGET_OS_ENV), windows.msys) >> >>>>>>> + # On msys2, prohibit msys path conversion from trying to be >> >>>>>>> + # "intelligent", and rely on fixpath instead. >> >>>>>>> + export MSYS2_ARG_CONV_EXCL:=* >> >>>>>>> endif >> >>>>>>> >> >>>>>>> SYSROOT_CFLAGS := @SYSROOT_CFLAGS@ >> >>>>>>> >> >>>>>>> /Magnus >> >>>>>>> >> >>>>>>> On 2017-10-03 22:34, Magnus Ihse Bursie wrote: >> >>>>>>> >> >>>>>>>> I gave msys2 a shot some time ago, but it ended up too much >> trouble. >> >>>>>>>> I'll share some of my notes from that attempt, for what it's >> worth. >> >>>>>>>> >> >>>>>>>> To install package X/Y, run "pacman -S X/Y". Missing tools and >> >>>>>>>> packages where to find them: >> >>>>>>>> cmp: msys/diffutils >> >>>>>>>> tar: msys/tar >> >>>>>>>> make: msys/make >> >>>>>>>> unzip: msys/unzip >> >>>>>>>> zip: msys/zip >> >>>>>>>> >> >>>>>>>> config.sub reports msys as "x86_64-pc-mingw32" but msys2 as >> >>>>>>>> "x86_64-pc-msys". This patch adds postprocessing in "our" >> config.sub >> >>>>>>>> to report msys2 similar to msys. (Opinions, including my own :-) >> may >> >>>>>>>> vary if this really is the best way..) >> >>>>>>>> >> >>>>>>>> diff -r b88023f46daa common/autoconf/build-aux/config.sub >> >>>>>>>> --- a/common/autoconf/build-aux/config.sub Fri Jan 27 >> 10:15:41 >> >>>>>>>> 2017 +0100 >> >>>>>>>> +++ b/common/autoconf/build-aux/config.sub Fri Feb 03 >> 05:00:25 >> >>>>>>>> 2017 -0700 >> >>>>>>>> @@ -30,7 +30,7 @@ >> >>>>>>>> DIR=`dirname $0` >> >>>>>>>> >> >>>>>>>> # First, filter out everything that doesn't begin with >> >>>>>>>> "aarch64-" >> >>>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >> >>>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >> >>>>>>>> . $DIR/autoconf-config.sub "$@" >> >>>>>>>> # autoconf-config.sub exits, so we never reach here, but >> >>>>>>>> just in >> >>>>>>>> # case we do: >> >>>>>>>> @@ -45,6 +45,10 @@ >> >>>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >> >>>>>>>> sub_args="$sub_args $config" >> >>>>>>>> shift; ;; >> >>>>>>>> + *-msys ) >> >>>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >> >>>>>>>> + sub_args="$sub_args $config" >> >>>>>>>> + shift; ;; >> >>>>>>>> - ) # Use stdin as input. >> >>>>>>>> sub_args="$sub_args $1" >> >>>>>>>> shift; break ;; >> >>>>>>>> >> >>>>>>>> If I remember correctly, this got me past the configure stage at >> the >> >>>>>>>> time. >> >>>>>>>> >> >>>>>>>> I don't think it's very hard to get it to work on msys2, I just >> ran >> >>>>>>>> into one snag too many and didn't think msys2 would be used by >> >>>>>>>> anyone. >> >>>>>>>> >> >>>>>>>> /Magnus >> >>>>>>>> >> >>>>>>>> On 2017-10-03 17:20, Peter Budai wrote: >> >>>>>>>> >> >>>>>>>>> Hello, >> >>>>>>>>> >> >>>>>>>>> According to >> >>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/commo >> >>>>>>>>> n/doc/building.html >> >>>>>>>>> >> >>>>>>>>> ?msys2 and the new Windows Subsystem for Linux (WSL) would >> likely >> >>>>>>>>> be >> >>>>>>>>> possible to support in a future version but that would require a >> >>>>>>>>> community effort to implement? >> >>>>>>>>> >> >>>>>>>>> I?d like to help making the OpenJDK 9 build working on msys2. >> What >> >>>>>>>>> is >> >>>>>>>>> the best way to move forward? Is there a similar effort in >> >>>>>>>>> progress? >> >>>>>>>>> >> >>>>>>>>> Thank you and best regards, >> >>>>>>>>> >> >>>>>>>>> Peter >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>> >> >>> >> > >> > > From magnus.ihse.bursie at oracle.com Mon Nov 27 14:01:29 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 27 Nov 2017 15:01:29 +0100 Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: Message-ID: Just a quick reply (I haven't read the details yet, will do so and re-reply if I find anything more to add). It's important to differentiate two different aspects here. 1) Using msys2 instead of cygwin 2) Compiling using gcc on windows. 1 should be fairly trivial. We once supported msys, and it just recently bitrotted due to lack of testing. I don't see any good reasons not to revive this support. 2 has never been done before, and can probably be quite tricky. I'm not sure what to gain from it, but if someone is prepared to go through the effort of fixing this, I think it can be a quality boost to the code base -- right now we don't properly differentiate between "windows" and "microsoft toolchain", and this effort would help us clean up that mess. But this is likely a huge undertaking, the prelimininary results showed multiple tier1 failures, which indicates (I believe) subtle issues in the compiled hotspot code. /Magnus On 2017-11-27 14:36, Thomas St?fe wrote: > Hi Peter, > > sorry if I came over too harsh. I gave this some thoughts and now I think > getting the openjdk to build with gcc on Windows may be beneficial. Please > find more comments inline. > > On Mon, Nov 27, 2017 at 12:12 PM, Peter Budai > wrote: > >> MSYS2 or Cygwin should be similar from the technical point of view IMHO. >> I?m familiar with MSYS2, but not with Cygwin. >> >> >> > I would prefer cygwin, as this is the officially adopted tool chain, and > the work is already done and we need to maintain it anyway. I can see the > value in having a different compiler, but not in having a different tool > chain. Again, my personal opinions, others may think differently. > > A quick grep through our sources yields a number of hits on cygwin specific > code. Some are really cygwin specific (e.g. calls to cygpath.exe to > calculate the cygwin specific path) whereas others seem to just mean "any > posix like windows environment as opposed to native windows cmd.exe". If we > add msys2 to the list, would we not have to revise all these places? > > The big change as you called out is to make sure that gcc toolchain can >> build successfully also for a Windows platform and produce a properly >> working binaries. >> >> >> >> BTW I don?t belie there are big performance differences whether you are >> building with GCC or MSC >> >> >> > Maybe you are right on the performance front, but I personally would still > be careful using gcc as a compiler for production builds. On one hand I > have an established tool chain with a company behind it I can pay for > support if something goes wrong. On the other hand a quiet exotic solution > for this platform. > > >> Once again, please advise on what is the best way to move forward, or stop >> this effort. >> >> > It is not my place to advice you or to decide anything. People from the > build group would have to decide whether we want to add support for > msys2+gcc and whether we want to support it. > > ..Thomas > > >> Peter >> >> >> ------------------------------ >> *From:* Thomas St?fe >> *Sent:* Thursday, November 23, 2017 10:36:07 PM >> *To:* Lussier, Denis >> *Cc:* Jonathan Gibbons; build-dev at openjdk.java.net; Peter Budai >> >> *Subject:* Re: Building OpenJDK9 on MSYS2 >> >> >> >> On Thu, Nov 23, 2017 at 12:40 AM, Lussier, Denis >> wrote: >> >>> This is good stuff. Back in 2010 I got OpenJDK compiled and running on >>> the >>> Microsoft Toolchain. I never ran the jtreg tests, but, the binaries >>> worked for running basic Tomcat but definitely not for trying to run >>> Eclipse. >>> >>> These days I am a pretty big fan of MSYS2. In my personal experiences >>> with >>> building a PostgreSQL Windoze distribution, the MSYS2 binaries run a >>> little >>> faster than using the old MS Toolchain. >>> >>> https://www.openscg.com/2016/02/building-postgresql-on-windo >>> ws-for-performance/ >>> >>> >> Well, the linked article does claim the msys2 toolchain to be faster than >> the Visual Studio, but there are no information I can see which compiler >> and linker options were used. Without this information, the article is >> difficult to take seriously. >> >> While I really respect these efforts, I regret seeing the fragmentation in >> windows build environments. I rather have one well kept build environment >> than of multiple buggy ones - and we have not that many folks interested in >> the windows port in the first place (it always feels like second place to >> the Posix platforms to me). The official build environment of the openjdk >> windows port is Cygwin + Visual Studio. Even if we think the gcc toolchain >> would be an attractive alternative to VS - why not just use the cygwin gcc >> instead? That way we would at least share the same posix layer. >> >> Just my 5c. >> >> Kind Regards, Thomas >> >> >> >>> --Luss >>> >>> >>> On Wed, Nov 22, 2017 at 4:28 PM, Jonathan Gibbons < >>> jonathan.gibbons at oracle.com> wrote: >>> >>>> Peter, >>>> >>>> With over 120 :tier1 test failures, it would be worth understanding the >>>> test failures as part of moving forward. There should normally be no >>> :tier1 >>>> test failures. >>>> >>>> -- Jon >>>> >>>> >>>> >>>> >>>> On 11/22/2017 01:10 PM, Peter Budai wrote: >>>> >>>>> Let me give an update on the current status: >>>>> >>>>> * I have managed to build both the 64 and the 32-bit version. >>>>> * The 64-bit version seems reasonable: >>>>> >>>>> >>>>> >>>>> ============================== >>>>> >>>>> Test summary - w64-bit >>>>> >>>>> ============================== >>>>> >>>>> TEST TOTAL PASS FAIL >>>>> ERROR >>>>> >>>>> jtreg:jdk/test:tier1 1645 1610 34 >>> 1 >>>>>>> << >>>>>>> jtreg:langtools/test:tier1 3907 3819 79 >>>>>>> 9 << >>>>>>> >>>>>> jtreg:nashorn/test:tier1 0 0 >>> 0 >>>>> 0 >>>>> >>>>> jtreg:jaxp/test:tier1 0 0 0 >>>>> 0 >>>>> >>>>> ============================== >>>>> >>>>> * However the 32-bit version of hotspot contains a bunch of inline >>>>> assembly pieces which uses an MSC specific syntax, and my ASM >>> knowledge is >>>>> really limited. I have managed to get a many inline assembly codes >>> from the >>>>> Linux version, but there are few pieces where I was not able to find a >>> good >>>>> solution yet, so although the 32-bit version compiles, unfortunately >>> it is >>>>> not working >>>>> * I have installed VS Express 2013 and made sure that the >>>>> ?traditional? Microsoft toolchain is still working with the changes >>>>> * My OCA has been processed >>>>> >>>>> I have a changeset which cleanly applies to JDK9 v181, but I recall you >>>>> have mentioned earlier that you would like to consider this to JDK10 >>>>> >>>>> So what is the best way to open a PR for review? This page: >>>>> http://openjdk.java.net/contribute/ says I should send the changeset >>> as >>>>> attachment, but earlier somebody mentioned here that attachments are >>>>> removed from the developer mailing lists. >>>>> >>>>> Best regards, >>>>> >>>>> Peter >>>>> >>>>> From: Erik Joelsson >>>>> Sent: Thursday, November 2, 2017 1:07 AM >>>>> To: Peter Budai; Magnus Ihse >>>>> Bursie >>>>> Cc: build-dev at openjdk.java.net >>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>> >>>>> I would say a few hours is way too long for tier1, but it of course >>>>> depends on the hardware used. We typically run it on windows in less >>>>> than 30 minutes with concurrency set to 6. Not sure what concurrency >>> you >>>>> used by default. >>>>> >>>>> /Erik >>>>> >>>>> >>>>> On 2017-10-27 04:33, Peter Budai wrote: >>>>> >>>>>> Hi Magnus, after a little poking I managed to install and use jtreg, >>>>>> thanks for the guidance. >>>>>> >>>>>> Make run-test-tier1 resulted a pretty OK result for a first try, at >>>>>> least for run-test-jdk: >>>>>> Test results: passed: 1,610; failed: 34; error: 1 >>>>>> It took a few hors to run ? is that normal? >>>>>> >>>>>> I?ll review the patchset, and then share that with you. >>>>>> >>>>>> P. >>>>>> >>>>>> From: Magnus Ihse Bursie >>>>>> Sent: Thursday, October 26, 2017 11:00 AM >>>>>> To: Peter Budai >>>>>> Cc: build-dev at openjdk.java.net >>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>> >>>>>> >>>>>> On 2017-10-26 00:01, Peter Budai wrote: >>>>>> OK, I have found what was missing, it was actually my fault with a >>>>>> missing exception handler. >>>>>> >>>>>> So finally OpenJDK build has finished on Windows using gcc toolchain >>>>>> running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it looks >>>>>> promising: >>>>>> ./build/windows-x86_64-normal-server-fastdebug/hotspot/varia >>>>>> nt-server/libjvm/gtest/gtestLauncher.exe >>> --jdk=/home/peterbud/jdk9/buil >>>>>> d/windows-x86_64-normal-server-fastdebug/jdk >>>>>> ?. >>>>>> ?. >>>>>> ?. >>>>>> >>>>>> [----------] Global test environment tear-down >>>>>> [==========] 346 tests from 54 test cases ran. (3859 ms total) >>>>>> [ PASSED ] 346 tests. >>>>>> I'm impressed! :-) >>>>>> >>>>>> Would you care to share your current patchset, just to still my >>>>>> curiosity? :-) >>>>>> >>>>>> >>>>>> >>>>>> What is the best way to test the current build more thoroughly? >>>>>> "make run-test-tier1". As Erik says, you'll need jtreg, and call >>>>>> "configure --with-jtreg=...". You can get it from the Adopt OpenJDK >>> group >>>>>> here: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccess >>>>>> fulBuild/artifact/ >>>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>> P. >>>>>> >>>>>> From: Bob Vandette >>>>>> Sent: Tuesday, October 24, 2017 8:10 PM >>>>>> To: Peter Budai >>>>>> Cc: David Holmes; Erik >>> Joelsson>>>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie>>>>> ie at oracle.com>; build-dev at openjdk.java.net>>>>> build-dev at openjdk.java.net> >>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>> >>>>>> Can you provide some details about your toolchain, processor and os >>> plus >>>>>> a dump of the native instructions around the SEGV. This might give us >>>>>> enough info to be able to figure out what?s going on. >>>>>> >>>>>> Bob. >>>>>> >>>>>> On Oct 24, 2017, at 1:21 PM, Peter Budai >> >>>>> peterbudai at hotmail.com>> wrote: >>>>>> >>>>>> I get that error running in the debugger but also running >>>>>> without/outside of the debugger as well. >>>>>> >>>>>> I saw the comment in the code about generating SEGV in function >>>>>> generate_get_cpu_info(), however the debugger can execute that, and >>> the >>>>>> SEGV I experience is coming later in the >>> VM_Version::get_processor_features() >>>>>> function >>>>>> >>>>>> Peter >>>>>> >>>>>> From: Bob Vandette >>>>>> Sent: Tuesday, October 24, 2017 6:28 PM >>>>>> To: Peter Budai >>>>>> Cc: David Holmes; Erik >>> Joelsson>>>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie>>>>> ie at oracle.com>; build-dev at openjdk.java.net>>>>> build-dev at openjdk.java.net> >>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>> >>>>>> Was this a SEGV while you were running the debugger? >>>>>> >>>>>> There is an intentional SEGV generated. This is used to determine if >>> we >>>>>> can use some of newer >>>>>> CPU features. Try to allow the SEGV to continue to see if you run >>>>>> normally. >>>>>> >>>>>> Bob. >>>>>> >>>>>> >>>>>> On Oct 24, 2017, at 11:37 AM, Peter Budai >> >>>>>> :peterbudai at hotmail.com>> wrote: >>>>>>> >>>>>>> It seems that the compile is progressing well, I have 49 >>>>>>> executables/tools and 38 compiled shared libraries already in the JDK >>>>>>> folder. >>>>>>> >>>>>>> I have tried to run the product with the simplest ?java -version? >>>>>>> command, however I get a SIGSEGV at get_cpu_info_stub() in >>>>>>> vm_version_x86.cpp, VM_Version::get_processor_features() >>>>>>> >>>>>>> get_cpu_info_stub(&_cpuid_info); >>>>>>> >>>>>>> Thread 5 received signal SIGSEGV, Segmentation fault. >>>>>>> 0x000000002d9a072f in ?? () >>>>>>> >>>>>>> I can debug using gdb, but unfortunately this is pure ASM, and my >>>>>>> knowledge on this is close to 0. >>>>>>> >>>>>>> Any idea help or pointer how could I tackle this? >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> From: David Holmes >>>>>>> Sent: Sunday, October 15, 2017 10:37 PM >>>>>>> To: Peter Budai; Erik >>> Joelsson>>>>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie>> magnus.ihse.burs >>>>>>> ie at oracle.com> >>>>>>> Cc: build-dev at openjdk.java.net>>>>>>> >>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>> >>>>>>> On 16/10/2017 12:41 AM, Peter Budai wrote: >>>>>>> >>>>>>>> A quick status update: >>>>>>>> >>>>>>>> * Hotspot successfully compiled without warnings >>>>>>>> * I?d like to run the unit tests, but as I see ?make check? >>> does >>>>>>>> not work, and gtestlauncher expects a command line parameter jdk. >>> Tried to >>>>>>>> look up some documentation on this, but have not found. So the >>> question is: >>>>>>>> how can I run unit tests for hotspot? Do I need also JDK compiled >>> for that? >>>>>>>> Or the bootJDK is good enough? Any help would be appreciated. >>>>>>>> >>>>>>> Hotspot has to be tested as part of a full JDK - you can't load the >>> JVM >>>>>>> without having the "J" part :) >>>>>>> >>>>>>> You should be able to drop your built dll into an existing JDK 9 >>> windows >>>>>>> JDK and test it that way. >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> * Also I?m making progress on compiling jdk, but there are some >>>>>>>> very interesting solutions on windows linking which makes a bit more >>>>>>>> difficult to compile with gcc: LIBS_windows contains sometimes >>> simple >>>>>>>> library names (which I believe is correct) and other times library >>> names >>>>>>>> with full path (which I believe is not the best solution). I?m >>> trying to >>>>>>>> rework those places and use simple library names and passing search >>> path >>>>>>>> for libraries -L (for gcc toolchain) and /LIBPATH: (for >>>>>>>> Microsoft toolchain). Also I was surprised by a few manual function >>> name >>>>>>>> exports? >>>>>>>> * jdk code base contains apparently more MSVC specific part, >>>>>>>> many places casts/lack of casts are generating errors, static >>> attributes >>>>>>>> were missing etc. a bit tedious work. >>>>>>>> >>>>>>>> P. >>>>>>>> >>>>>>>> From: Erik Joelsson >>>>>>>> Sent: Wednesday, October 11, 2017 4:16 PM >>>>>>>> To: Magnus Ihse Bursie; Peter >>>>>>>> Budai >>>>>>>> Cc: build-dev at openjdk.java.net>>>>>>>> >>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: >>>>>>>> >>>>>>>> For gcc, we let the compiler generate the .d file. For the Microsoft >>>>>>>> tool chain, we use a clever sed script to extract and create it >>> ourself. >>>>>>>> I think that logic is checking for "Windows", not "Microsoft". That >>>>>>>> might be your cause of trouble. >>>>>>>> >>>>>>>> Look in NativeCompilation.gmk. >>>>>>>> >>>>>>>> That was my initial thought as well, but we do correctly check for >>>>>>>> microsoft. Also it's not the .d files that are the problem. As >>> Peter just >>>>>>>> wrote, they look fine. It's the .d.target files which we create >>> using the >>>>>>>> same technique on all platforms. What we don't account for is the >>> compiler >>>>>>>> putting Windows mixed paths in the .d files. >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> 11 okt. 2017 kl. 14:43 skrev Peter Budai >>>>>>> >: >>>>>>>> Hi Erik, >>>>>>>> >>>>>>>> The .d file looks like this: >>>>>>>> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: \ >>>>>>>> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp >>> \ >>>>>>>> I have checked .d.targets file, and looks like it has the first line >>>>>>>> has not been deleted, and the file names below are also wrong: >>>>>>>> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-serve >>>>>>>> r-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj : : >>>>>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp : >>>>>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : >>>>>>>> >>>>>>>> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by >>>>>>>> the ?C:/? >>>>>>>> -e 's/^[^:]*: *//' >>>>>>>> >>>>>>>> Yes, that does indeed look like the problem. I suppose the regexp is >>>>>>>> unnecessarily strict. It should be ok to rewrite it as something >>> like this: >>>>>>>> -e 's/^.*: *//' >>>>>>>> >>>>>>>> Basically just make sure it ends with : and any number of spaces. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> Sent from Mail for >>>>>>>> Windows 10 >>>>>>>> >>>>>>>> From: Erik Joelsson >>>>>>>> Sent: Wednesday, October 11, 2017 12:16 PM >>>>>>>> To: Peter Budai; Magnus Ihse >>>>>>>> Bursie; >>>>>>>> build-dev at openjdk.java.net>>> >>>>>>> build-dev at openjdk.java.net> >>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>> >>>>>>>> >>>>>>>> Hello Peter, >>>>>>>> >>>>>>>> On 2017-10-11 00:18, Peter Budai wrote: >>>>>>>> Thanks Magnus & Erik >>>>>>>> >>>>>>>> First thanks for your support and kind words! >>>>>>>> >>>>>>>> Magnus, I have checked .bash_profile, .bashrc but they seem to be >>>>>>>> empty (everything is commented out). You can check with a default >>> MSYS2 >>>>>>>> install, I have not changed these files at all. If you find thee >>> something >>>>>>>> specific I can give a try here as well. >>>>>>>> >>>>>>>> Let me give also a quick status update, where am I with building >>>>>>>> hotspot: >>>>>>>> ? I guess its still the beginning, but I have managed to >>> compile >>>>>>>> jvm.dll with almost 700 object file: with debug info the dll is >>> around 700 >>>>>>>> MB ? >>>>>>>> ? I made only surgical, minimal changes to the source, and so >>>>>>>> far it looks reasonable. I have encountered 3 scenarios where >>> changes were >>>>>>>> necessary: >>>>>>>> o When in makefiles conditionals were using assuming that if >>>>>>>> target_os is windows then it is visual studio compiler/linker. >>> Obviously >>>>>>>> these conditionals had to be reviewed in a few places and if >>> necessary were >>>>>>>> changes to check the toolchain=Microsoft >>>>>>>> These are not surprising and should be pretty straight forward to >>> fix >>>>>>>> and it seems you know what to do. >>>>>>>> >>>>>>>> >>>>>>>> ? >>>>>>>> o I got a few warnings as gcc 7.2 uncovered some code problems in >>>>>>>> windows specific codes, where before that MSVC I guess did not say >>> a word? >>>>>>>> To get around this you can configure with >>> --disable-warnings-as-errors >>>>>>>> until you get things working properly. This is commonly needed when >>> using >>>>>>>> compiler versions that we normally don't use. >>>>>>>> >>>>>>>> >>>>>>>> ? >>>>>>>> o And I had like 6-7 places where the code was using MSVC specific >>>>>>>> __try ? __except structures which gcc does not know. Do you have a >>>>>>>> suggestion how to approach them? I can do ugly #ifdefs (I would >>> avoid that) >>>>>>>> but I have also seen some solutions to replace them with a code >>> which gcc >>>>>>>> can compile (http://www.programmingunlimit >>> ed.net/siteexec/content.cgi? >>>>>>>> page=mingw-seh ) ? but before doing that though I would ask first >>>>>>>> you on the purpose of those >>>>>>>> This kind of question is probably best to bring to the hotspot >>> mailing >>>>>>>> list. >>>>>>>> ? What bothers me is that I was not able to do incremental >>>>>>>> builds: when an error occurs, and build stops, then after making >>> change in >>>>>>>> the CPP source the build cannot continue, I always got an error >>> message: >>>>>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse. >>> d.targets:1: >>>>>>>> *** missing target pattern. Stop. >>>>>>>> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 >>>>>>>> >>>>>>>> If I do a ?make clean? and restart the build then it nicely >>> compiles. >>>>>>>> Question 1: Is there a way to resume such builds without ?make >>> clean?? >>>>>>>> Well, incremental builds is supposed to work well. We have several >>>>>>>> extra tricks in there to handle cases where normal make builds >>> would fail. >>>>>>>> The *.d.targets files is one such trick and it seems to backfire >>> for you. >>>>>>>> The contents of that file should be something like: >>>>>>>> >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : >>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : >>>>>>>> >>>>>>>> Basically an empty rule for each dependency for the corresponding >>>>>>>> object file. Declaring these rules makes it possible to delete >>> source files >>>>>>>> without having to build clean. It seems your file is not generated >>>>>>>> correctly so please have a look inside it. The file is in >>>>>>>> make/common/NativeCompilation.gmk, look for >>>>>>>> DEPENDENCY_TARGET_SED_PATTERN. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Question 2: What would be the best way to submit/share the patches >>> for >>>>>>>> your thorough review? >>>>>>>> >>>>>>>> Well, first of all, have you signed the OCA? >>>>>>>> >>>>>>>> As for publishing patches and reviews, there is a bit of chicken and >>>>>>>> egg problem. Once you become an "author" in any of the OpenJDK >>> projects, >>>>>>>> you get a user name and should be able to publish reviews on >>>>>>>> cr.openjdk.java.net>>>>>>> penjdk.java.net>>>>>>> k.java.net/%3e%3chttp:/cr.openjdk.java.net%3chttp:/cr. >>>>>>>> openjdk.java.net/>>>. Before that, if the patch is small, it can be >>>>>>>> posted inline in an email to the list. If it's large, you will need >>> a >>>>>>>> current OpenJDK user to host it for you. At least that's how I >>> understand >>>>>>>> it. Hopefully someone who knows the process better can chime in >>> here. >>>>>>>> I should also let you know that getting this into JDK 9 is most >>> likely >>>>>>>> not going to happen. AFAIK we are only doing security updates for >>> 9. It >>>>>>>> would have to go into the currently active release. I should also >>> warn you >>>>>>>> that new ports generally need a certain amount of backing to be >>> accepted. >>>>>>>> It may be that this would have to live in a porting side project. >>> Hopefully >>>>>>>> someone who knows this better can chime in here as well. >>>>>>>> >>>>>>>> /Erik >>>>>>>> >>>>>>>> >>>>>>>> P. >>>>>>>> >>>>>>>> Sent from Mail for >>>>>>>> Windows 10 >>>>>>>> >>>>>>>> From: Magnus Ihse Bursie >>>>>>>> Sent: Tuesday, October 10, 2017 10:04 AM >>>>>>>> To: Peter Budai; Erik >>> Joelsson>>>>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net>>>>>>> build-dev at openjdk.java.net> >>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>> >>>>>>>> On 2017-10-07 10:14, Peter Budai wrote: >>>>>>>> The configure of OpenJDK overwrites the SHELL. Actually it is using >>>>>>>> bash, but for the arguments it was using ?-e -o pipefail?. I have >>> figured >>>>>>>> that for MSYS2 bash what is needed as bash arguments is ?-e -l -c -o >>>>>>>> pipefail? >>>>>>>> >>>>>>>> That looks like solving this problem, and now the real issues are >>>>>>>> surfacing. >>>>>>>> >>>>>>>> FWIW, "-l" makes bash behave like a login shell. Most likely you are >>>>>>>> changing bash's behavior in one of your login scripts, and that >>> change is >>>>>>>> what's really needed. >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> From: Peter Budai >>>>>>>> Sent: Friday, October 6, 2017 6:43 PM >>>>>>>> To: Magnus Ihse Bursie; Erik >>>>>>>> Joelsson; >>> build-dev at openjdk.java.net >>>>>>>> >> .java.net> >>>>>>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>>>>>> >>>>>>>> Magnus, >>>>>>>> >>>>>>>> I have followed your suggestion and removed the fixpath prefixes >>> from >>>>>>>> gcc related compile tools, and left only the fixpath prefix _only_ >>> for the >>>>>>>> Boot JDK related tools in place. >>>>>>>> >>>>>>>> 1) As I follow the process, all java and javac related compile >>>>>>>> steps are running properly >>>>>>>> 2) When the process reaches gcc related steps I got the error >>>>>>>> message at the same place as before (no fixpath). If I execute that >>> command >>>>>>>> from the bash prompt, it creates the output: >>>>>>>> >>>>>>>> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >>>>>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >>>>>>>> /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/j >>>>>>>> dk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegist >>> ry.java.template >>>>>>>> 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | >>>>>>>> /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e >>> 's/@@START_HERE@@/\/\/ >>>>>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e >>> 's/^#.*//' >>>>>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption >>>>>>>> Registry.java >>>>>>>> >>>>>>>> As I have mentioned the parameters are replaced by the bash >>>>>>>> automatically >>>>>>>> 3) Then build continues, then little later stops at a super >>>>>>>> simple command: >>>>>>>> >>>>>>>> mv /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp >>>>>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java >>>>>>>> Needless to say, the ByteBuffer.java.tmp file DOES >>> exist. >>>>>>>> And running the above command from the bash works, and build >>> continues. >>>>>>>> 4) A few similar cases (stops) with DirectByteBuffer and >>>>>>>> DirectByteBufferR >>>>>>>> >>>>>>>> >>>>>>>> Currently I try to explore how that might relate to the MSYS2 bash >>> and >>>>>>>> make, somehow it behaves differently >>>>>>>> >>>>>>>> If you have any other suggestion, let me know. >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> From: Peter Budai >>>>>>>> Sent: Thursday, October 5, 2017 3:52 PM >>>>>>>> To: Magnus Ihse Bursie; Erik >>>>>>>> Joelsson; >>> build-dev at openjdk.java.net >>>>>>>> >> .java.net> >>>>>>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>>>>>> >>>>>>>> Hi Magnus, >>>>>>>> >>>>>>>> So first of all, here is the current patch, which I was not able to >>>>>>>> attach: https://pastebin.com/pwT4Ynxc >>>>>>>> >>>>>>>> That's surprising, since gcc is prefixed with fixpath, which it >>> should >>>>>>>>>> not. >>>>>>>>>> >>>>>>>>> Actually you DO need fixpath IMHO. >>>>>>>> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), >>>>>>>> which is a fully functional Windows executable, which expects >>> Windows >>>>>>>> formatted path arguments. >>>>>>>> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see >>>>>>>> that patch), none of the command line arguments are converted from >>> the >>>>>>>> unix path to Windows, but fixpath does that conversion. There is a >>> wiki >>>>>>>> describing more details on this: >>>>>>>> https://github.com/msys2/msys2/wiki/Porting#user-content- >>>>>>>> filesystem-namespaces >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> I have a hard time believing this is a race condition. On the other >>>>>>>>>> hand, this stuff is weird, we're misusing the C preprocessor to >>> process >>>>>>>>>> defines in java code, so I'm not surprised it breaks down. >>>>>>>>>> I don't know why it succeeded when run on the command line, >>> though. >>>>>>>>> When I execute that command from the bash command line there is no >>>>>>>> EXPORT MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic >>>>>>>> conversion of the arguments. Maybe it has something to do how >>> fixpath does >>>>>>>> CreateProcess? >>>>>>>> >>>>>>>> Does that help? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> Sent from Mail for >>>>>>>> Windows 10 >>>>>>>> >>>>>>>> From: Magnus Ihse Bursie >>>>>>>> Sent: Thursday, October 5, 2017 12:13 PM >>>>>>>> To: Peter Budai; Erik >>> Joelsson>>>>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net>>>>>>> build-dev at openjdk.java.net> >>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>> >>>>>>>> >>>>>>>> On 2017-10-05 11:59, Peter Budai wrote: >>>>>>>> Hi Magnus and Erik, >>>>>>>> >>>>>>>> I really appreciate your quick feedback. I assumed that it won?t be >>>>>>>> easy, but I just don?t feel I should give up now - maybe later >>> when I see >>>>>>>> the real scale of work. So bear with me for a time being. >>>>>>>> >>>>>>>> Attached is a patch which already includes Magnus? changes, plus a >>> few >>>>>>>> which I have added: >>>>>>>> ? basically enabling gcc for windows, >>>>>>>> ? and modifying a logic for compiling fixpath (before that it >>>>>>>> was using hard-coded MS VSC compile flags) >>>>>>>> >>>>>>>> Actually, you must make sure fixpath is *not* used for the >>> toolchain, >>>>>>>> since gcc uses unix style paths. >>>>>>>> (However, other tools such as java will still need it.) >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> So here is what I have as the result of configure: >>>>>>>> ==================================================== >>>>>>>> The existing configuration has been successfully updated in >>>>>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>> ver-release >>>>>>>> using configure arguments '--disable-freetype-bundling >>>>>>>> --disable-javac-server'. >>>>>>>> >>>>>>>> Configuration summary: >>>>>>>> * Debug level: release >>>>>>>> * HS debug level: product >>>>>>>> * JDK variant: normal >>>>>>>> * JVM variants: server >>>>>>>> * OpenJDK target: OS: windows, CPU architecture: x86, address >>> length: >>>>>>>> 64 >>>>>>>> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) >>>>>>>> >>>>>>>> Tools summary: >>>>>>>> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) >>>>>>>> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime >>>>>>>> Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server >>> VM (build >>>>>>>> 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) >>>>>>>> * Toolchain: gcc (GNU Compiler Collection) >>>>>>>> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) >>>>>>>> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) >>>>>>>> >>>>>>>> Build performance summary: >>>>>>>> * Cores to use: 4 >>>>>>>> * Memory limit: 16216 MB >>>>>>>> >>>>>>>> Its clear says that the toolchain is gcc 7.2 (BTW there is no Visual >>>>>>>> Studio on this machine) >>>>>>>> >>>>>>>> Now for the details of the config log, you can see here: >>>>>>>> https://pastebin.com/MN2ZYcHH >>>>>>>> >>>>>>>> And about the build process and the error I get: >>>>>>>> >>>>>>>> $ make JOBS=1 >>>>>>>> Building target 'default (exploded-image)' in configuration >>>>>>>> 'windows-x86_64-normal-server-release' >>>>>>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >>>>>>>> Compiling 17 properties into resource bundles for jdk.compiler >>>>>>>> Parsing 1 properties into enum-like class for jdk.compiler >>>>>>>> Compiling 19 properties into resource bundles for jdk.javadoc >>>>>>>> Compiling 12 properties into resource bundles for jdk.jdeps >>>>>>>> Compiling 7 properties into resource bundles for jdk.jshell >>>>>>>> Compiling 117 files for BUILD_INTERIM_java.compiler >>>>>>>> Compiling 396 files for BUILD_INTERIM_jdk.compiler >>>>>>>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps >>>>>>>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc >>>>>>>> Note: Some input files use or override a deprecated API. >>>>>>>> Note: Recompile with -Xlint:deprecation for details. >>>>>>>> Compiling 159 files for BUILD_TOOLS_JDK >>>>>>>> Note: Some input files use unchecked or unsafe operations. >>>>>>>> Note: Recompile with -Xlint:unchecked for details. >>>>>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b >>>>>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav >>>>>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>>>>>>> make[3]: *** Deleting file '/C/msys64/home/peterbud/jdk9/ >>>>>>>> build/windows-x86_64-normal-server-release/support/gensrc/ja >>>>>>>> va.base/sun/nio/ch/SocketOptionRegistry.java' >>>>>>>> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 >>>>>>>> >>>>>>>> ERROR: Build failed for target 'default (exploded-image)' in >>>>>>>> configuration 'windows-x86_64-normal-server-release' (exit code 2) >>>>>>>> >>>>>>>> No indication of failed target found. >>>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>>> Hint: See common/doc/building.html#troubleshooting for assistance. >>>>>>>> >>>>>>>> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 >>>>>>>> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 >>>>>>>> >>>>>>>> If I run here >>>>>>>> make JOBS=1 LOG=debug >>>>>>>> The failing line seems to be this: >>>>>>>> >>>>>>>> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >>>>>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >>>>>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>> ver-release/configure-support/bin/fixpath.exe >>>>>>>> -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x >>> c >>>>>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>>>>> /sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep >>> -v >>>>>>>> '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk >>>>>>>> '/@@START_HERE@@/,0' | /usr/bin/sed -e 's/@@START_HERE@@/\/\/ >>>>>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e >>> 's/^#.*//' >>>>>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption >>>>>>>> Registry.java >>>>>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b >>>>>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav >>>>>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>>>>>>> >>>>>>>> Now the interesting is: if I copy this line above to the bash >>> prompt, >>>>>>>> it runs without problem, and the file support/gensrc/java.base/sun/n >>>>>>>> io/ch/SocketOptionRegistry.java >>>>>>>> That's surprising, since gcc is prefixed with fixpath, which it >>> should >>>>>>>> not. >>>>>>>> >>>>>>>> I have a hard time believing this is a race condition. On the other >>>>>>>> hand, this stuff is weird, we're misusing the C preprocessor to >>> process >>>>>>>> defines in java code, so I'm not suprised it breaks down. I don't >>> know why >>>>>>>> it succeeded when run on the command line, though. My suggestion is >>> to just >>>>>>>> do some quick and dirty hack around this: take the file you manage >>> to >>>>>>>> generate and just copy it in during the build instead. If you can >>> get round >>>>>>>> this, you might start seeing some *real* problems. :-) >>>>>>>> >>>>>>>> Also, my suggestion is that you try running "make hotspot" to cut to >>>>>>>> the chase. Compiling hotspot will likely be the hardest thing. Or >>> even >>>>>>>> "make -k hotspot" to get an assessment of the amount of work ahead >>> of you. >>>>>>>> /Magnus >>>>>>>> Is produced. >>>>>>>> >>>>>>>> Then I can again issue >>>>>>>> make JOBS=1 LOG=debug >>>>>>>> >>>>>>>> And the compile process is being continued, until a similar error >>> pops >>>>>>>> up with a different generated file. I have an assumption that this >>> happens >>>>>>>> because make is still running parallel jobs, despite JOBS=1 but I?m >>> not >>>>>>>> sure. >>>>>>>> >>>>>>>> How could I best tackle this? >>>>>>>> >>>>>>>> Thank you and best regards, >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> Sent from Mail for >>>>>>>> Windows 10 >>>>>>>> >>>>>>>> From: Magnus Ihse Bursie >>>>>>>> Sent: Thursday, October 5, 2017 11:33 AM >>>>>>>> To: Erik Joelsson; Peter >>>>>>>> Budai; build-dev at openjdk.java.net >>> >>>>>>> lto:build-dev at openjdk.java.net> >>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>> >>>>>>>> On 2017-10-05 10:10, Erik Joelsson wrote: >>>>>>>> >>>>>>>>> Hello Peter, >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2017-10-04 21:15, Peter Budai wrote: >>>>>>>>> >>>>>>>>>> Hi Magnus, >>>>>>>>>> >>>>>>>>>> Thanks for the quick reply I?ll check these patches with msys2. >>>>>>>>>> >>>>>>>>>> Let me specify with more details what I?d like to achieve: I?d >>> like >>>>>>>>>> to build OpenJDK9 with MSYS2 MINGW64 environment using gcc >>> toolchain. >>>>>>>>>> (I?m not sure how familiar are you with MSYS2, but there are 3 >>>>>>>>>> different environments: MSYS2, MINGW32 and MINGW64). In theory >>>>>>>>>> MINGW64 with gcc is the closes you can get on Windows platform as >>> a >>>>>>>>>> gcc unix like build environment, which produces still a native >>> 64-bit >>>>>>>>>> executable on Windows. >>>>>>>>>> >>>>>>>>>> I?m not very familiar with OpenJDK yet, so therefore I?d like to >>> hear >>>>>>>>>> your opinion: how realistic is that? >>>>>>>>>> >>>>>>>>> Sorry to disappoint, but I would say that requires major work. >>> There >>>>>>>>> is a strong historic assumption that windows builds are done using >>>>>>>>> Visual Studio. We have abstracted away some of it in configure (see >>>>>>>>> TOOLCHAIN_TYPE), but it's very far from enough to change compiler >>>>>>>>> environment for a Windows build. The native sources are also bound >>> to >>>>>>>>> make a lot of such assumptions. I would expect the changes needed >>> to >>>>>>>>> be in the thousands of lines of code. >>>>>>>>> >>>>>>>> I agree that it requires hard work (even if "thousands" might be an >>>>>>>> overestimation I think, but "hundreds" is not enough, so it's the >>> right >>>>>>>> magnitude). On the other hand, it would be really good if we did >>> sort >>>>>>>> things out, so that we had proper conditions based on OS vs >>>>>>>> compiler/toolchain. >>>>>>>> >>>>>>>> If you really want to start, the first thing is to patch >>> toolchain.m4 >>>>>>>> to >>>>>>>> VALID_TOOLCHAINS_windows="microsoft gcc" >>>>>>>> and then call configure using "bash configure >>>>>>>> --with-toolchain-type=gcc". >>>>>>>> >>>>>>>> As Erik, I doubt you will come very far before things starts >>> tumbling >>>>>>>> down. >>>>>>>> >>>>>>>> When we say supporting the build in msys2 instead of cygwin, we just >>>>>>>>> mean using msys2 as the unix emulating layer for our tools like >>>>>>>>> make/bash/grep/sed etc. >>>>>>>>> >>>>>>>>> One think I have done successfully is running the build in WSL >>>>>>>>> (Windows Subsystem for Linux), but that isn't all that helpful as >>> WSL >>>>>>>>> for practical purposes is more or less like running Linux in a VM, >>> so >>>>>>>>> the build sees a Linux system and builds a Linux binary. >>>>>>>>> >>>>>>>>>> As a side note: with MINGW64 I have managed to run configure phase >>>>>>>>>> successfully for OpenJDK. The compile process has also started and >>>>>>>>>> went for a while, but interestingly I run into some kind of race >>>>>>>>>> conditions as make stopped with an error. Using LOG=debug I have >>> fond >>>>>>>>>> the failing line and then copying the failed command and pasting >>> it >>>>>>>>>> to the bash prompt it successfully generated the output target, >>> and >>>>>>>>>> then the build process run further when a similar situation >>> happened. >>>>>>>>>> Also pasting the failed command run in the bash without any >>> problem, >>>>>>>>>> and build continued? until the next. >>>>>>>>>> >>>>>>>>> Without seeing the errors I can't say much. I very much doubt that >>> you >>>>>>>>> are running with gcc as the compiler though. Configure isn't easily >>>>>>>>> fooled into using a different compiler to what it prefers, and I >>> would >>>>>>>>> expect things to crash and burn pretty early if you actually did. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>>> I have tried to run make JOBS=1, but did not help, strangely I >>> have >>>>>>>>>> still seen in the log make[3] and make[4] logs which suggested >>> that >>>>>>>>>> there are more than one make jobs were running. Also tried >>> .configure >>>>>>>>>> --with-output-sync=recurse without success (same symptoms) >>>>>>>>>> >>>>>>>>>> Let me know your thoughts. >>>>>>>>>> >>>>>>>>>> Best regards, >>>>>>>>>> >>>>>>>>>> Peter >>>>>>>>>> >>>>>>>>>> Sent from Mail >>> for >>>>>>>>>> Windows 10 >>>>>>>>>> >>>>>>>>>> From: Magnus Ihse Bursie >>>>>>>>>> Sent: Wednesday, October 4, 2017 1:04 AM >>>>>>>>>> To: Peter Budai; >>>>>>>>>> build-dev at openjdk.java.net>>>>>>>>>> >>>>>>>>> k.java.net> >>>>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>>>> >>>>>>>>>> Actually, it wasn't so much remaining trouble. :-) I fired up >>> msys2 >>>>>>>>>> and >>>>>>>>>> checked out where I left off. It turned out that the remaining >>> snag >>>>>>>>>> was >>>>>>>>>> that msys2 tries to convert command lines automatically, from >>> "unix" >>>>>>>>>> style paths to "windows" style paths. Unfortunately, it does not >>> do >>>>>>>>>> this >>>>>>>>>> very well and it breaks all sorts of things. We already have a >>>>>>>>>> FIXPATH >>>>>>>>>> solution in place which deals with this, so basically all I had >>> to do >>>>>>>>>> was disable this (by setting MSYS2_ARG_CONV_EXCL to "*"). However, >>>>>>>>>> this >>>>>>>>>> broke our cygpath replacement hack (!) so I had to disable it >>> there. >>>>>>>>>> Sigh. Anyway, with those fixes it ran and worked well. (I also >>>>>>>>>> discovered and fixed a bug related to how we set up the FIXPATH >>>>>>>>>> variable >>>>>>>>>> on msys, but it only triggers in certain circumstances). >>>>>>>>>> >>>>>>>>>> With this patch I now jdk9 seems to build fine on msys2. It should >>>>>>>>>> apply >>>>>>>>>> cleanly on jdk9/jdk9. Since it turned out to be so trivial, I'll >>> try >>>>>>>>>> to >>>>>>>>>> get it in in jdk10. >>>>>>>>>> >>>>>>>>>> Here's the patch if you want to apply it yourself: >>>>>>>>>> >>>>>>>>>> diff -r a08cbfc0e4ec common/autoconf/basics_windows.m4 >>>>>>>>>> --- a/common/autoconf/basics_windows.m4 Thu Aug 03 18:56:56 >>> 2017 >>>>>>>>>> +0000 >>>>>>>>>> +++ b/common/autoconf/basics_windows.m4 Wed Oct 04 00:53:58 >>> 2017 >>>>>>>>>> +0200 >>>>>>>>>> @@ -42,7 +42,7 @@ >>>>>>>>>> windows_path=`$CYGPATH -m "$unix_path"` >>>>>>>>>> $1="$windows_path" >>>>>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = "xwindows.msys"; then >>>>>>>>>> - windows_path=`cmd //c echo $unix_path` >>>>>>>>>> + windows_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $unix_path` >>>>>>>>>> $1="$windows_path" >>>>>>>>>> fi >>>>>>>>>> ]) >>>>>>>>>> @@ -136,6 +136,16 @@ >>>>>>>>>> fi >>>>>>>>>> ]) >>>>>>>>>> >>>>>>>>>> +AC_DEFUN([BASIC_MSYS_UPDATE_FIXPATH], >>>>>>>>>> +[ >>>>>>>>>> + # Take all collected prefixes and turn them into a >>>>>>>>>> -m/c/foo@/c/bar at ... command line >>>>>>>>>> + # @ was chosen as separator to minimize risk of other tools >>>>>>>>>> messing >>>>>>>>>> around with it >>>>>>>>>> + all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@:>@}" \ >>>>>>>>>> + | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>>>>>>> + fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' '@'` >>>>>>>>>> + FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>>>>>>> +]) >>>>>>>>>> + >>>>>>>>>> AC_DEFUN([BASIC_FIXUP_PATH_MSYS], >>>>>>>>>> [ >>>>>>>>>> path="[$]$1" >>>>>>>>>> @@ -143,7 +153,7 @@ >>>>>>>>>> new_path="$path" >>>>>>>>>> if test "x$has_colon" = x; then >>>>>>>>>> # Not in mixed or Windows style, start by that. >>>>>>>>>> - new_path=`cmd //c echo $path` >>>>>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $path` >>>>>>>>>> fi >>>>>>>>>> >>>>>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>>>>>>> @@ -155,6 +165,8 @@ >>>>>>>>>> >>>>>>>>>> # Save the first 10 bytes of this path to the storage, so >>>>>>>>>> fixpath >>>>>>>>>> can work. >>>>>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>>>>>>> "${new_path:0:10}") >>>>>>>>>> + # We might need to re-evaluate FIXPATH. >>>>>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>>>>>> ]) >>>>>>>>>> >>>>>>>>>> AC_DEFUN([BASIC_FIXUP_EXECUTABLE_CYGWIN], >>>>>>>>>> @@ -293,7 +305,7 @@ >>>>>>>>>> # Do not save /bin paths to all_fixpath_prefixes! >>>>>>>>>> else >>>>>>>>>> # Not in mixed or Windows style, start by that. >>>>>>>>>> - new_path=`cmd //c echo $new_path` >>>>>>>>>> + new_path=`MSYS2_ARG_CONV_EXCL= cmd //c echo $new_path` >>>>>>>>>> BASIC_MAKE_WINDOWS_SPACE_SAFE_MSYS([$new_path]) >>>>>>>>>> # Output is in $new_path >>>>>>>>>> BASIC_WINDOWS_REWRITE_AS_UNIX_PATH(new_path) >>>>>>>>>> @@ -302,6 +314,8 @@ >>>>>>>>>> >>>>>>>>>> # Save the first 10 bytes of this path to the storage, so >>>>>>>>>> fixpath >>>>>>>>>> can work. >>>>>>>>>> all_fixpath_prefixes=("${all_fixpath_prefixes@<:@@@:>@}" >>>>>>>>>> "${new_path:0:10}") >>>>>>>>>> + # We might need to re-evaluate FIXPATH. >>>>>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>>>>>> fi >>>>>>>>>> ]) >>>>>>>>>> >>>>>>>>>> @@ -347,6 +361,10 @@ >>>>>>>>>> WINDOWS_ENV_VENDOR='msys' >>>>>>>>>> WINDOWS_ENV_VERSION="$MSYS_VERSION" >>>>>>>>>> >>>>>>>>>> + # Prohibit msys2 path conversion from trying to be >>>>>>>>>> "intelligent", >>>>>>>>>> and rely >>>>>>>>>> + # on fixpath instead. >>>>>>>>>> + export MSYS2_ARG_CONV_EXCL="*" >>>>>>>>>> + >>>>>>>>>> AC_MSG_CHECKING([msys root directory as unix-style path]) >>>>>>>>>> # The cmd output ends with Windows line endings (CR/LF), >>>>>>>>>> the grep >>>>>>>>>> command will strip that away >>>>>>>>>> MSYS_ROOT_PATH=`cd / ; cmd /c cd | $GREP ".*"` >>>>>>>>>> @@ -391,10 +409,7 @@ >>>>>>>>>> elif test "x$OPENJDK_BUILD_OS_ENV" = xwindows.msys; then >>>>>>>>>> # Take all collected prefixes and turn them into a >>>>>>>>>> -m/c/foo@/c/bar at ... command line >>>>>>>>>> # @ was chosen as separator to minimize risk of other >>>>>>>>>> tools >>>>>>>>>> messing around with it >>>>>>>>>> - all_unique_prefixes=`echo "${all_fixpath_prefixes@<:@@@: >>>> @}" >>>>>>>>>> \ >>>>>>>>>> - | tr ' ' '\n' | $GREP '^/./' | $SORT | $UNIQ` >>>>>>>>>> - fixpath_argument_list=`echo $all_unique_prefixes | tr ' ' >>>>>>>>>> '@'` >>>>>>>>>> - FIXPATH="$FIXPATH_BIN -m$fixpath_argument_list" >>>>>>>>>> + BASIC_MSYS_UPDATE_FIXPATH >>>>>>>>>> fi >>>>>>>>>> FIXPATH_SRC_W="$FIXPATH_SRC" >>>>>>>>>> FIXPATH_BIN_W="$FIXPATH_BIN" >>>>>>>>>> diff -r a08cbfc0e4ec common/autoconf/build-aux/config.sub >>>>>>>>>> --- a/common/autoconf/build-aux/config.sub Thu Aug 03 18:56:56 >>>>>>>>>> 2017 +0000 >>>>>>>>>> +++ b/common/autoconf/build-aux/config.sub Wed Oct 04 00:53:58 >>>>>>>>>> 2017 +0200 >>>>>>>>>> @@ -30,7 +30,7 @@ >>>>>>>>>> DIR=`dirname $0` >>>>>>>>>> >>>>>>>>>> # First, filter out everything that doesn't begin with >>>>>>>>>> "aarch64-" >>>>>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>>>>>> . $DIR/autoconf-config.sub "$@" >>>>>>>>>> # autoconf-config.sub exits, so we never reach here, but >>>>>>>>>> just in >>>>>>>>>> # case we do: >>>>>>>>>> @@ -38,13 +38,17 @@ >>>>>>>>>> fi >>>>>>>>>> >>>>>>>>>> while test $# -gt 0 ; do >>>>>>>>>> - case $1 in >>>>>>>>>> + case $1 in >>>>>>>>>> -- ) # Stop option processing >>>>>>>>>> shift; break ;; >>>>>>>>>> aarch64-* ) >>>>>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>>>>>> sub_args="$sub_args $config" >>>>>>>>>> shift; ;; >>>>>>>>>> + *-msys ) >>>>>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>>>>>> + sub_args="$sub_args $config" >>>>>>>>>> + shift; ;; >>>>>>>>>> - ) # Use stdin as input. >>>>>>>>>> sub_args="$sub_args $1" >>>>>>>>>> shift; break ;; >>>>>>>>>> diff -r a08cbfc0e4ec common/autoconf/spec.gmk.in >>>>>>>>>> --- a/common/autoconf/spec.gmk.in Thu Aug 03 18:56:56 2017 >>> +0000 >>>>>>>>>> +++ b/common/autoconf/spec.gmk.in Wed Oct 04 00:53:58 2017 >>> +0200 >>>>>>>>>> @@ -120,6 +120,13 @@ >>>>>>>>>> # On Windows, the Visual Studio toolchain needs the PATH >>> to be >>>>>>>>>> adjusted >>>>>>>>>> # to include Visual Studio tools (this needs to be in >>>>>>>>>> cygwin/msys >>>>>>>>>> style). >>>>>>>>>> export PATH:=@VS_PATH@ >>>>>>>>>> + >>>>>>>>>> +endif >>>>>>>>>> + >>>>>>>>>> +ifeq ($(OPENJDK_TARGET_OS_ENV), windows.msys) >>>>>>>>>> + # On msys2, prohibit msys path conversion from trying to be >>>>>>>>>> + # "intelligent", and rely on fixpath instead. >>>>>>>>>> + export MSYS2_ARG_CONV_EXCL:=* >>>>>>>>>> endif >>>>>>>>>> >>>>>>>>>> SYSROOT_CFLAGS := @SYSROOT_CFLAGS@ >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>>> On 2017-10-03 22:34, Magnus Ihse Bursie wrote: >>>>>>>>>> >>>>>>>>>>> I gave msys2 a shot some time ago, but it ended up too much >>> trouble. >>>>>>>>>>> I'll share some of my notes from that attempt, for what it's >>> worth. >>>>>>>>>>> To install package X/Y, run "pacman -S X/Y". Missing tools and >>>>>>>>>>> packages where to find them: >>>>>>>>>>> cmp: msys/diffutils >>>>>>>>>>> tar: msys/tar >>>>>>>>>>> make: msys/make >>>>>>>>>>> unzip: msys/unzip >>>>>>>>>>> zip: msys/zip >>>>>>>>>>> >>>>>>>>>>> config.sub reports msys as "x86_64-pc-mingw32" but msys2 as >>>>>>>>>>> "x86_64-pc-msys". This patch adds postprocessing in "our" >>> config.sub >>>>>>>>>>> to report msys2 similar to msys. (Opinions, including my own :-) >>> may >>>>>>>>>>> vary if this really is the best way..) >>>>>>>>>>> >>>>>>>>>>> diff -r b88023f46daa common/autoconf/build-aux/config.sub >>>>>>>>>>> --- a/common/autoconf/build-aux/config.sub Fri Jan 27 >>> 10:15:41 >>>>>>>>>>> 2017 +0100 >>>>>>>>>>> +++ b/common/autoconf/build-aux/config.sub Fri Feb 03 >>> 05:00:25 >>>>>>>>>>> 2017 -0700 >>>>>>>>>>> @@ -30,7 +30,7 @@ >>>>>>>>>>> DIR=`dirname $0` >>>>>>>>>>> >>>>>>>>>>> # First, filter out everything that doesn't begin with >>>>>>>>>>> "aarch64-" >>>>>>>>>>> -if ! echo $* | grep '^aarch64-' >/dev/null ; then >>>>>>>>>>> +if ! echo $* | grep -e '^aarch64-' -e 'msys' >/dev/null ; then >>>>>>>>>>> . $DIR/autoconf-config.sub "$@" >>>>>>>>>>> # autoconf-config.sub exits, so we never reach here, but >>>>>>>>>>> just in >>>>>>>>>>> # case we do: >>>>>>>>>>> @@ -45,6 +45,10 @@ >>>>>>>>>>> config=`echo $1 | sed 's/^aarch64-/arm-/'` >>>>>>>>>>> sub_args="$sub_args $config" >>>>>>>>>>> shift; ;; >>>>>>>>>>> + *-msys ) >>>>>>>>>>> + config=`echo $1 | sed 's/msys/mingw32/'` >>>>>>>>>>> + sub_args="$sub_args $config" >>>>>>>>>>> + shift; ;; >>>>>>>>>>> - ) # Use stdin as input. >>>>>>>>>>> sub_args="$sub_args $1" >>>>>>>>>>> shift; break ;; >>>>>>>>>>> >>>>>>>>>>> If I remember correctly, this got me past the configure stage at >>> the >>>>>>>>>>> time. >>>>>>>>>>> >>>>>>>>>>> I don't think it's very hard to get it to work on msys2, I just >>> ran >>>>>>>>>>> into one snag too many and didn't think msys2 would be used by >>>>>>>>>>> anyone. >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>>> On 2017-10-03 17:20, Peter Budai wrote: >>>>>>>>>>> >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> According to >>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/jdk9/file/a08cbfc0e4ec/commo >>>>>>>>>>>> n/doc/building.html >>>>>>>>>>>> >>>>>>>>>>>> ?msys2 and the new Windows Subsystem for Linux (WSL) would >>> likely >>>>>>>>>>>> be >>>>>>>>>>>> possible to support in a future version but that would require a >>>>>>>>>>>> community effort to implement? >>>>>>>>>>>> >>>>>>>>>>>> I?d like to help making the OpenJDK 9 build working on msys2. >>> What >>>>>>>>>>>> is >>>>>>>>>>>> the best way to move forward? Is there a similar effort in >>>>>>>>>>>> progress? >>>>>>>>>>>> >>>>>>>>>>>> Thank you and best regards, >>>>>>>>>>>> >>>>>>>>>>>> Peter >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>> >> From thomas.stuefe at gmail.com Mon Nov 27 14:17:17 2017 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Mon, 27 Nov 2017 15:17:17 +0100 Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: Message-ID: On Mon, Nov 27, 2017 at 3:01 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > Just a quick reply (I haven't read the details yet, will do so and > re-reply if I find anything more to add). > > It's important to differentiate two different aspects here. > > 1) Using msys2 instead of cygwin > 2) Compiling using gcc on windows. > > 1 should be fairly trivial. We once supported msys, and it just recently > bitrotted due to lack of testing. I don't see any good reasons not to > revive this support. > > 2 has never been done before, and can probably be quite tricky. I'm not > sure what to gain from it, but if someone is prepared to go through the > effort of fixing this, I think it can be a quality boost to the code base > -- right now we don't properly differentiate between "windows" and > "microsoft toolchain", and this effort would help us clean up that mess. > > Also the question of who is supposed to maintain it in the long run should be answered. We are usually quite strict in adding new platforms - I remember the recent BSD port discussions, which I believe ended in 1) needs a long term maintainer, preferably a company or foundation 2) must pass TCK *before* being added to the mainline. The BSD people did not meet the restrictions, so they are still in their port branch. Which, btw, would be a solution for msys2+gcc port too: work in their own branch until the conditions are met to migrate to the base line? > But this is likely a huge undertaking, the prelimininary results showed > multiple tier1 failures, which indicates (I believe) subtle issues in the > compiled hotspot code. > > I agree this looks huge. > /Magnus > ..Thomas > > On 2017-11-27 14:36, Thomas St?fe wrote: > >> Hi Peter, >> >> sorry if I came over too harsh. I gave this some thoughts and now I think >> getting the openjdk to build with gcc on Windows may be beneficial. Please >> find more comments inline. >> >> On Mon, Nov 27, 2017 at 12:12 PM, Peter Budai >> wrote: >> >> MSYS2 or Cygwin should be similar from the technical point of view IMHO. >>> I?m familiar with MSYS2, but not with Cygwin. >>> >>> >>> >>> I would prefer cygwin, as this is the officially adopted tool chain, and >> the work is already done and we need to maintain it anyway. I can see the >> value in having a different compiler, but not in having a different tool >> chain. Again, my personal opinions, others may think differently. >> >> A quick grep through our sources yields a number of hits on cygwin >> specific >> code. Some are really cygwin specific (e.g. calls to cygpath.exe to >> calculate the cygwin specific path) whereas others seem to just mean "any >> posix like windows environment as opposed to native windows cmd.exe". If >> we >> add msys2 to the list, would we not have to revise all these places? >> >> The big change as you called out is to make sure that gcc toolchain can >> >>> build successfully also for a Windows platform and produce a properly >>> working binaries. >>> >>> >>> >>> BTW I don?t belie there are big performance differences whether you are >>> building with GCC or MSC >>> >>> >>> >>> Maybe you are right on the performance front, but I personally would >> still >> be careful using gcc as a compiler for production builds. On one hand I >> have an established tool chain with a company behind it I can pay for >> support if something goes wrong. On the other hand a quiet exotic solution >> for this platform. >> >> >> Once again, please advise on what is the best way to move forward, or stop >>> this effort. >>> >>> >>> It is not my place to advice you or to decide anything. People from the >> build group would have to decide whether we want to add support for >> msys2+gcc and whether we want to support it. >> >> ..Thomas >> >> >> Peter >>> >>> >>> ------------------------------ >>> *From:* Thomas St?fe >>> *Sent:* Thursday, November 23, 2017 10:36:07 PM >>> *To:* Lussier, Denis >>> *Cc:* Jonathan Gibbons; build-dev at openjdk.java.net; Peter Budai >>> >>> *Subject:* Re: Building OpenJDK9 on MSYS2 >>> >>> >>> >>> On Thu, Nov 23, 2017 at 12:40 AM, Lussier, Denis >>> wrote: >>> >>> This is good stuff. Back in 2010 I got OpenJDK compiled and running on >>>> the >>>> Microsoft Toolchain. I never ran the jtreg tests, but, the binaries >>>> worked for running basic Tomcat but definitely not for trying to run >>>> Eclipse. >>>> >>>> These days I am a pretty big fan of MSYS2. In my personal experiences >>>> with >>>> building a PostgreSQL Windoze distribution, the MSYS2 binaries run a >>>> little >>>> faster than using the old MS Toolchain. >>>> >>>> https://www.openscg.com/2016/02/building-postgresql-on-windo >>>> ws-for-performance/ >>>> >>>> >>>> Well, the linked article does claim the msys2 toolchain to be faster >>> than >>> the Visual Studio, but there are no information I can see which compiler >>> and linker options were used. Without this information, the article is >>> difficult to take seriously. >>> >>> While I really respect these efforts, I regret seeing the fragmentation >>> in >>> windows build environments. I rather have one well kept build environment >>> than of multiple buggy ones - and we have not that many folks interested >>> in >>> the windows port in the first place (it always feels like second place to >>> the Posix platforms to me). The official build environment of the openjdk >>> windows port is Cygwin + Visual Studio. Even if we think the gcc >>> toolchain >>> would be an attractive alternative to VS - why not just use the cygwin >>> gcc >>> instead? That way we would at least share the same posix layer. >>> >>> Just my 5c. >>> >>> Kind Regards, Thomas >>> >>> >>> >>> --Luss >>>> >>>> >>>> On Wed, Nov 22, 2017 at 4:28 PM, Jonathan Gibbons < >>>> jonathan.gibbons at oracle.com> wrote: >>>> >>>> Peter, >>>>> >>>>> With over 120 :tier1 test failures, it would be worth understanding the >>>>> test failures as part of moving forward. There should normally be no >>>>> >>>> :tier1 >>>> >>>>> test failures. >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> >>>>> >>>>> On 11/22/2017 01:10 PM, Peter Budai wrote: >>>>> >>>>> Let me give an update on the current status: >>>>>> >>>>>> * I have managed to build both the 64 and the 32-bit version. >>>>>> * The 64-bit version seems reasonable: >>>>>> >>>>>> >>>>>> >>>>>> ============================== >>>>>> >>>>>> Test summary - w64-bit >>>>>> >>>>>> ============================== >>>>>> >>>>>> TEST TOTAL PASS >>>>>> FAIL >>>>>> ERROR >>>>>> >>>>>> jtreg:jdk/test:tier1 1645 1610 34 >>>>>> >>>>> 1 >>>> >>>>> << >>>>>>>> jtreg:langtools/test:tier1 3907 3819 79 >>>>>>>> 9 << >>>>>>>> >>>>>>>> jtreg:nashorn/test:tier1 0 0 >>>>>>> >>>>>> 0 >>>> >>>>> 0 >>>>>> >>>>>> jtreg:jaxp/test:tier1 0 0 >>>>>> 0 >>>>>> 0 >>>>>> >>>>>> ============================== >>>>>> >>>>>> * However the 32-bit version of hotspot contains a bunch of >>>>>> inline >>>>>> assembly pieces which uses an MSC specific syntax, and my ASM >>>>>> >>>>> knowledge is >>>> >>>>> really limited. I have managed to get a many inline assembly codes >>>>>> >>>>> from the >>>> >>>>> Linux version, but there are few pieces where I was not able to find a >>>>>> >>>>> good >>>> >>>>> solution yet, so although the 32-bit version compiles, unfortunately >>>>>> >>>>> it is >>>> >>>>> not working >>>>>> * I have installed VS Express 2013 and made sure that the >>>>>> ?traditional? Microsoft toolchain is still working with the changes >>>>>> * My OCA has been processed >>>>>> >>>>>> I have a changeset which cleanly applies to JDK9 v181, but I recall >>>>>> you >>>>>> have mentioned earlier that you would like to consider this to JDK10 >>>>>> >>>>>> So what is the best way to open a PR for review? This page: >>>>>> http://openjdk.java.net/contribute/ says I should send the changeset >>>>>> >>>>> as >>>> >>>>> attachment, but earlier somebody mentioned here that attachments are >>>>>> removed from the developer mailing lists. >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Peter >>>>>> >>>>>> From: Erik Joelsson >>>>>> Sent: Thursday, November 2, 2017 1:07 AM >>>>>> To: Peter Budai; Magnus Ihse >>>>>> Bursie >>>>>> Cc: build-dev at openjdk.java.net >>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>> >>>>>> I would say a few hours is way too long for tier1, but it of course >>>>>> depends on the hardware used. We typically run it on windows in less >>>>>> than 30 minutes with concurrency set to 6. Not sure what concurrency >>>>>> >>>>> you >>>> >>>>> used by default. >>>>>> >>>>>> /Erik >>>>>> >>>>>> >>>>>> On 2017-10-27 04:33, Peter Budai wrote: >>>>>> >>>>>> Hi Magnus, after a little poking I managed to install and use jtreg, >>>>>>> thanks for the guidance. >>>>>>> >>>>>>> Make run-test-tier1 resulted a pretty OK result for a first try, at >>>>>>> least for run-test-jdk: >>>>>>> Test results: passed: 1,610; failed: 34; error: 1 >>>>>>> It took a few hors to run ? is that normal? >>>>>>> >>>>>>> I?ll review the patchset, and then share that with you. >>>>>>> >>>>>>> P. >>>>>>> >>>>>>> From: Magnus Ihse Bursie >>>>>>> Sent: Thursday, October 26, 2017 11:00 AM >>>>>>> To: Peter Budai >>>>>>> Cc: build-dev at openjdk.java.net >>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>> >>>>>>> >>>>>>> On 2017-10-26 00:01, Peter Budai wrote: >>>>>>> OK, I have found what was missing, it was actually my fault with a >>>>>>> missing exception handler. >>>>>>> >>>>>>> So finally OpenJDK build has finished on Windows using gcc toolchain >>>>>>> running in MSYS2/MINGW64 shell. I ran hotspot unit tests, and it >>>>>>> looks >>>>>>> promising: >>>>>>> ./build/windows-x86_64-normal-server-fastdebug/hotspot/varia >>>>>>> nt-server/libjvm/gtest/gtestLauncher.exe >>>>>>> >>>>>> --jdk=/home/peterbud/jdk9/buil >>>> >>>>> d/windows-x86_64-normal-server-fastdebug/jdk >>>>>>> ?. >>>>>>> ?. >>>>>>> ?. >>>>>>> >>>>>>> [----------] Global test environment tear-down >>>>>>> [==========] 346 tests from 54 test cases ran. (3859 ms total) >>>>>>> [ PASSED ] 346 tests. >>>>>>> I'm impressed! :-) >>>>>>> >>>>>>> Would you care to share your current patchset, just to still my >>>>>>> curiosity? :-) >>>>>>> >>>>>>> >>>>>>> >>>>>>> What is the best way to test the current build more thoroughly? >>>>>>> "make run-test-tier1". As Erik says, you'll need jtreg, and call >>>>>>> "configure --with-jtreg=...". You can get it from the Adopt OpenJDK >>>>>>> >>>>>> group >>>> >>>>> here: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccess >>>>>>> fulBuild/artifact/ >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> P. >>>>>>> >>>>>>> From: Bob Vandette >>>>>>> Sent: Tuesday, October 24, 2017 8:10 PM >>>>>>> To: Peter Budai >>>>>>> Cc: David Holmes; Erik >>>>>>> >>>>>> Joelsson>>> >>>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie>>>>>> ie at oracle.com>; build-dev at openjdk.java.net>>>>>> build-dev at openjdk.java.net> >>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>> >>>>>>> Can you provide some details about your toolchain, processor and os >>>>>>> >>>>>> plus >>>> >>>>> a dump of the native instructions around the SEGV. This might give us >>>>>>> enough info to be able to figure out what?s going on. >>>>>>> >>>>>>> Bob. >>>>>>> >>>>>>> On Oct 24, 2017, at 1:21 PM, Peter Budai >>>>>> >>>>>> >>> >>>>> peterbudai at hotmail.com>> wrote: >>>>>>> >>>>>>> I get that error running in the debugger but also running >>>>>>> without/outside of the debugger as well. >>>>>>> >>>>>>> I saw the comment in the code about generating SEGV in function >>>>>>> generate_get_cpu_info(), however the debugger can execute that, and >>>>>>> >>>>>> the >>>> >>>>> SEGV I experience is coming later in the >>>>>>> >>>>>> VM_Version::get_processor_features() >>>> >>>>> function >>>>>>> >>>>>>> Peter >>>>>>> >>>>>>> From: Bob Vandette >>>>>>> Sent: Tuesday, October 24, 2017 6:28 PM >>>>>>> To: Peter Budai >>>>>>> Cc: David Holmes; Erik >>>>>>> >>>>>> Joelsson>>> >>>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie>>>>>> ie at oracle.com>; build-dev at openjdk.java.net>>>>>> build-dev at openjdk.java.net> >>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>> >>>>>>> Was this a SEGV while you were running the debugger? >>>>>>> >>>>>>> There is an intentional SEGV generated. This is used to determine if >>>>>>> >>>>>> we >>>> >>>>> can use some of newer >>>>>>> CPU features. Try to allow the SEGV to continue to see if you run >>>>>>> normally. >>>>>>> >>>>>>> Bob. >>>>>>> >>>>>>> >>>>>>> On Oct 24, 2017, at 11:37 AM, Peter Budai >>>>>> >>>>>> >>> >>>>> :peterbudai at hotmail.com>> wrote: >>>>>>>> >>>>>>>> It seems that the compile is progressing well, I have 49 >>>>>>>> executables/tools and 38 compiled shared libraries already in the >>>>>>>> JDK >>>>>>>> folder. >>>>>>>> >>>>>>>> I have tried to run the product with the simplest ?java -version? >>>>>>>> command, however I get a SIGSEGV at get_cpu_info_stub() in >>>>>>>> vm_version_x86.cpp, VM_Version::get_processor_features() >>>>>>>> >>>>>>>> get_cpu_info_stub(&_cpuid_info); >>>>>>>> >>>>>>>> Thread 5 received signal SIGSEGV, Segmentation fault. >>>>>>>> 0x000000002d9a072f in ?? () >>>>>>>> >>>>>>>> I can debug using gdb, but unfortunately this is pure ASM, and my >>>>>>>> knowledge on this is close to 0. >>>>>>>> >>>>>>>> Any idea help or pointer how could I tackle this? >>>>>>>> >>>>>>>> Peter >>>>>>>> >>>>>>>> From: David Holmes >>>>>>>> Sent: Sunday, October 15, 2017 10:37 PM >>>>>>>> To: Peter Budai; Erik >>>>>>>> >>>>>>> Joelsson>>> >>>>> erik.joelsson at oracle.com>; Magnus Ihse Bursie>>>>>>> >>>>>>> magnus.ihse.burs >>>> >>>>> ie at oracle.com> >>>>>>>> Cc: build-dev at openjdk.java.net>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>> >>>>>>>> On 16/10/2017 12:41 AM, Peter Budai wrote: >>>>>>>> >>>>>>>> A quick status update: >>>>>>>>> >>>>>>>>> * Hotspot successfully compiled without warnings >>>>>>>>> * I?d like to run the unit tests, but as I see ?make check? >>>>>>>>> >>>>>>>> does >>>> >>>>> not work, and gtestlauncher expects a command line parameter jdk. >>>>>>>>> >>>>>>>> Tried to >>>> >>>>> look up some documentation on this, but have not found. So the >>>>>>>>> >>>>>>>> question is: >>>> >>>>> how can I run unit tests for hotspot? Do I need also JDK compiled >>>>>>>>> >>>>>>>> for that? >>>> >>>>> Or the bootJDK is good enough? Any help would be appreciated. >>>>>>>>> >>>>>>>>> Hotspot has to be tested as part of a full JDK - you can't load the >>>>>>>> >>>>>>> JVM >>>> >>>>> without having the "J" part :) >>>>>>>> >>>>>>>> You should be able to drop your built dll into an existing JDK 9 >>>>>>>> >>>>>>> windows >>>> >>>>> JDK and test it that way. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> * Also I?m making progress on compiling jdk, but there are >>>>>>>> some >>>>>>>> >>>>>>>>> very interesting solutions on windows linking which makes a bit >>>>>>>>> more >>>>>>>>> difficult to compile with gcc: LIBS_windows contains sometimes >>>>>>>>> >>>>>>>> simple >>>> >>>>> library names (which I believe is correct) and other times library >>>>>>>>> >>>>>>>> names >>>> >>>>> with full path (which I believe is not the best solution). I?m >>>>>>>>> >>>>>>>> trying to >>>> >>>>> rework those places and use simple library names and passing search >>>>>>>>> >>>>>>>> path >>>> >>>>> for libraries -L (for gcc toolchain) and /LIBPATH: (for >>>>>>>>> Microsoft toolchain). Also I was surprised by a few manual function >>>>>>>>> >>>>>>>> name >>>> >>>>> exports? >>>>>>>>> * jdk code base contains apparently more MSVC specific part, >>>>>>>>> many places casts/lack of casts are generating errors, static >>>>>>>>> >>>>>>>> attributes >>>> >>>>> were missing etc. a bit tedious work. >>>>>>>>> >>>>>>>>> P. >>>>>>>>> >>>>>>>>> From: Erik Joelsson >>>>>>>>> Sent: Wednesday, October 11, 2017 4:16 PM >>>>>>>>> To: Magnus Ihse Bursie; >>>>>>>>> Peter >>>>>>>>> Budai >>>>>>>>> Cc: build-dev at openjdk.java.net>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> On 2017-10-11 15:48, Magnus Ihse Bursie wrote: >>>>>>>>> >>>>>>>>> For gcc, we let the compiler generate the .d file. For the >>>>>>>>> Microsoft >>>>>>>>> tool chain, we use a clever sed script to extract and create it >>>>>>>>> >>>>>>>> ourself. >>>> >>>>> I think that logic is checking for "Windows", not "Microsoft". That >>>>>>>>> might be your cause of trouble. >>>>>>>>> >>>>>>>>> Look in NativeCompilation.gmk. >>>>>>>>> >>>>>>>>> That was my initial thought as well, but we do correctly check for >>>>>>>>> microsoft. Also it's not the .d files that are the problem. As >>>>>>>>> >>>>>>>> Peter just >>>> >>>>> wrote, they look fine. It's the .d.target files which we create >>>>>>>>> >>>>>>>> using the >>>> >>>>> same technique on all platforms. What we don't account for is the >>>>>>>>> >>>>>>>> compiler >>>> >>>>> putting Windows mixed paths in the .d files. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> 11 okt. 2017 kl. 14:43 skrev Peter Budai >>>>>>>> >: >>>>>>>>> Hi Erik, >>>>>>>>> >>>>>>>>> The .d file looks like this: >>>>>>>>> C:/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj: \ >>>>>>>>> C:/msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlpa >>>>>>>>> rse.cpp >>>>>>>>> >>>>>>>> \ >>>> >>>>> I have checked .d.targets file, and looks like it has the first line >>>>>>>>> has not been deleted, and the file names below are also wrong: >>>>>>>>> /msys64/home/peterbud/jdk9/build/windows-x86_64-normal-serve >>>>>>>>> r-release/hotspot/variant-server/tools/adlc/objs/adlparse.obj : : >>>>>>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlparse.cpp >>>>>>>>> : >>>>>>>>> /msys64/home/peterbud/jdk9/hotspot/src/share/vm/adlc/adlc.hpp : >>>>>>>>> >>>>>>>>> I guess this part in the DEPENDENCY_TARGET_SED_PATTERN is fooled by >>>>>>>>> the ?C:/? >>>>>>>>> -e 's/^[^:]*: *//' >>>>>>>>> >>>>>>>>> Yes, that does indeed look like the problem. I suppose the regexp >>>>>>>>> is >>>>>>>>> unnecessarily strict. It should be ok to rewrite it as something >>>>>>>>> >>>>>>>> like this: >>>> >>>>> -e 's/^.*: *//' >>>>>>>>> >>>>>>>>> Basically just make sure it ends with : and any number of spaces. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> Sent from Mail for >>>>>>>>> Windows 10 >>>>>>>>> >>>>>>>>> From: Erik Joelsson >>>>>>>>> Sent: Wednesday, October 11, 2017 12:16 PM >>>>>>>>> To: Peter Budai; Magnus Ihse >>>>>>>>> Bursie; >>>>>>>>> build-dev at openjdk.java.net>>>>>>>> >>>>>>>> >>>> >>>>>> build-dev at openjdk.java.net> >>>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>>> >>>>>>>>> >>>>>>>>> Hello Peter, >>>>>>>>> >>>>>>>>> On 2017-10-11 00:18, Peter Budai wrote: >>>>>>>>> Thanks Magnus & Erik >>>>>>>>> >>>>>>>>> First thanks for your support and kind words! >>>>>>>>> >>>>>>>>> Magnus, I have checked .bash_profile, .bashrc but they seem to be >>>>>>>>> empty (everything is commented out). You can check with a default >>>>>>>>> >>>>>>>> MSYS2 >>>> >>>>> install, I have not changed these files at all. If you find thee >>>>>>>>> >>>>>>>> something >>>> >>>>> specific I can give a try here as well. >>>>>>>>> >>>>>>>>> Let me give also a quick status update, where am I with building >>>>>>>>> hotspot: >>>>>>>>> ? I guess its still the beginning, but I have managed to >>>>>>>>> >>>>>>>> compile >>>> >>>>> jvm.dll with almost 700 object file: with debug info the dll is >>>>>>>>> >>>>>>>> around 700 >>>> >>>>> MB ? >>>>>>>>> ? I made only surgical, minimal changes to the source, and so >>>>>>>>> far it looks reasonable. I have encountered 3 scenarios where >>>>>>>>> >>>>>>>> changes were >>>> >>>>> necessary: >>>>>>>>> o When in makefiles conditionals were using assuming that if >>>>>>>>> target_os is windows then it is visual studio compiler/linker. >>>>>>>>> >>>>>>>> Obviously >>>> >>>>> these conditionals had to be reviewed in a few places and if >>>>>>>>> >>>>>>>> necessary were >>>> >>>>> changes to check the toolchain=Microsoft >>>>>>>>> These are not surprising and should be pretty straight forward to >>>>>>>>> >>>>>>>> fix >>>> >>>>> and it seems you know what to do. >>>>>>>>> >>>>>>>>> >>>>>>>>> ? >>>>>>>>> o I got a few warnings as gcc 7.2 uncovered some code problems in >>>>>>>>> windows specific codes, where before that MSVC I guess did not say >>>>>>>>> >>>>>>>> a word? >>>> >>>>> To get around this you can configure with >>>>>>>>> >>>>>>>> --disable-warnings-as-errors >>>> >>>>> until you get things working properly. This is commonly needed when >>>>>>>>> >>>>>>>> using >>>> >>>>> compiler versions that we normally don't use. >>>>>>>>> >>>>>>>>> >>>>>>>>> ? >>>>>>>>> o And I had like 6-7 places where the code was using MSVC >>>>>>>>> specific >>>>>>>>> __try ? __except structures which gcc does not know. Do you have a >>>>>>>>> suggestion how to approach them? I can do ugly #ifdefs (I would >>>>>>>>> >>>>>>>> avoid that) >>>> >>>>> but I have also seen some solutions to replace them with a code >>>>>>>>> >>>>>>>> which gcc >>>> >>>>> can compile (http://www.programmingunlimit >>>>>>>>> >>>>>>>> ed.net/siteexec/content.cgi? >>>> >>>>> page=mingw-seh ) ? but before doing that though I would ask first >>>>>>>>> you on the purpose of those >>>>>>>>> This kind of question is probably best to bring to the hotspot >>>>>>>>> >>>>>>>> mailing >>>> >>>>> list. >>>>>>>>> ? What bothers me is that I was not able to do incremental >>>>>>>>> builds: when an error occurs, and build stops, then after making >>>>>>>>> >>>>>>>> change in >>>> >>>>> the CPP source the build cannot continue, I always got an error >>>>>>>>> >>>>>>>> message: >>>> >>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>>> ver-release/hotspot/variant-server/tools/adlc/objs/adlparse. >>>>>>>>> >>>>>>>> d.targets:1: >>>> >>>>> *** missing target pattern. Stop. >>>>>>>>> make[2]: *** [make/Main.gmk:256: hotspot-server-gensrc] Error 2 >>>>>>>>> >>>>>>>>> If I do a ?make clean? and restart the build then it nicely >>>>>>>>> >>>>>>>> compiles. >>>> >>>>> Question 1: Is there a way to resume such builds without ?make >>>>>>>>> >>>>>>>> clean?? >>>> >>>>> Well, incremental builds is supposed to work well. We have several >>>>>>>>> extra tricks in there to handle cases where normal make builds >>>>>>>>> >>>>>>>> would fail. >>>> >>>>> The *.d.targets files is one such trick and it seems to backfire >>>>>>>>> >>>>>>>> for you. >>>> >>>>> The contents of that file should be something like: >>>>>>>>> >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.cpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlc.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/opcodes.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/classes.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/arena.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/opto/adlcVMDeps.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/filebuff.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/dict2.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/forms.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formsopt.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/formssel.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/archDesc.hpp : >>>>>>>>> /localhome/hg/jdk9-dev/hotspot/src/share/vm/adlc/adlparse.hpp : >>>>>>>>> >>>>>>>>> Basically an empty rule for each dependency for the corresponding >>>>>>>>> object file. Declaring these rules makes it possible to delete >>>>>>>>> >>>>>>>> source files >>>> >>>>> without having to build clean. It seems your file is not generated >>>>>>>>> correctly so please have a look inside it. The file is in >>>>>>>>> make/common/NativeCompilation.gmk, look for >>>>>>>>> DEPENDENCY_TARGET_SED_PATTERN. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Question 2: What would be the best way to submit/share the patches >>>>>>>>> >>>>>>>> for >>>> >>>>> your thorough review? >>>>>>>>> >>>>>>>>> Well, first of all, have you signed the OCA? >>>>>>>>> >>>>>>>>> As for publishing patches and reviews, there is a bit of chicken >>>>>>>>> and >>>>>>>>> egg problem. Once you become an "author" in any of the OpenJDK >>>>>>>>> >>>>>>>> projects, >>>> >>>>> you get a user name and should be able to publish reviews on >>>>>>>>> cr.openjdk.java.net>>>>>>>> penjdk.java.net>>>>>>>> k.java.net/%3e%3chttp:/cr.openjdk.java.net%3chttp:/cr. >>>>>>>>> openjdk.java.net/>>>. Before that, if the patch is small, it can >>>>>>>>> be >>>>>>>>> posted inline in an email to the list. If it's large, you will need >>>>>>>>> >>>>>>>> a >>>> >>>>> current OpenJDK user to host it for you. At least that's how I >>>>>>>>> >>>>>>>> understand >>>> >>>>> it. Hopefully someone who knows the process better can chime in >>>>>>>>> >>>>>>>> here. >>>> >>>>> I should also let you know that getting this into JDK 9 is most >>>>>>>>> >>>>>>>> likely >>>> >>>>> not going to happen. AFAIK we are only doing security updates for >>>>>>>>> >>>>>>>> 9. It >>>> >>>>> would have to go into the currently active release. I should also >>>>>>>>> >>>>>>>> warn you >>>> >>>>> that new ports generally need a certain amount of backing to be >>>>>>>>> >>>>>>>> accepted. >>>> >>>>> It may be that this would have to live in a porting side project. >>>>>>>>> >>>>>>>> Hopefully >>>> >>>>> someone who knows this better can chime in here as well. >>>>>>>>> >>>>>>>>> /Erik >>>>>>>>> >>>>>>>>> >>>>>>>>> P. >>>>>>>>> >>>>>>>>> Sent from Mail for >>>>>>>>> Windows 10 >>>>>>>>> >>>>>>>>> From: Magnus Ihse Bursie >>>>>>>>> Sent: Tuesday, October 10, 2017 10:04 AM >>>>>>>>> To: Peter Budai; Erik >>>>>>>>> >>>>>>>> Joelsson>>> >>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net>>>>>>>> build-dev at openjdk.java.net> >>>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>>> >>>>>>>>> On 2017-10-07 10:14, Peter Budai wrote: >>>>>>>>> The configure of OpenJDK overwrites the SHELL. Actually it is using >>>>>>>>> bash, but for the arguments it was using ?-e -o pipefail?. I have >>>>>>>>> >>>>>>>> figured >>>> >>>>> that for MSYS2 bash what is needed as bash arguments is ?-e -l -c -o >>>>>>>>> pipefail? >>>>>>>>> >>>>>>>>> That looks like solving this problem, and now the real issues are >>>>>>>>> surfacing. >>>>>>>>> >>>>>>>>> FWIW, "-l" makes bash behave like a login shell. Most likely you >>>>>>>>> are >>>>>>>>> changing bash's behavior in one of your login scripts, and that >>>>>>>>> >>>>>>>> change is >>>> >>>>> what's really needed. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> From: Peter Budai >>>>>>>>> Sent: Friday, October 6, 2017 6:43 PM >>>>>>>>> To: Magnus Ihse Bursie; Erik >>>>>>>>> Joelsson; >>>>>>>>> >>>>>>>> build-dev at openjdk.java.net >>>> >>>>> >>>>>>>> >>>>>>>> .java.net> >>>> >>>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>>>>>>> >>>>>>>>> Magnus, >>>>>>>>> >>>>>>>>> I have followed your suggestion and removed the fixpath prefixes >>>>>>>>> >>>>>>>> from >>>> >>>>> gcc related compile tools, and left only the fixpath prefix _only_ >>>>>>>>> >>>>>>>> for the >>>> >>>>> Boot JDK related tools in place. >>>>>>>>> >>>>>>>>> 1) As I follow the process, all java and javac related >>>>>>>>> compile >>>>>>>>> steps are running properly >>>>>>>>> 2) When the process reaches gcc related steps I got the error >>>>>>>>> message at the same place as before (no fixpath). If I execute that >>>>>>>>> >>>>>>>> command >>>> >>>>> from the bash prompt, it creates the output: >>>>>>>>> >>>>>>>>> $ ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >>>>>>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>>>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >>>>>>>>> /C/msys64/mingw64/bin/gcc -E -x c /C/msys64/home/peterbud/jdk9/j >>>>>>>>> dk/src/java.base/share/classes/sun/nio/ch/SocketOptionRegist >>>>>>>>> >>>>>>>> ry.java.template >>>> >>>>> 2> >(/usr/bin/grep -v '^SocketOptionRegistry.java.template$' >&2) | >>>>>>>>> /usr/bin/gawk '/@@START_HERE@@/,0' | /usr/bin/sed -e >>>>>>>>> >>>>>>>> 's/@@START_HERE@@/\/\/ >>>> >>>>> AUTOMATICALLY GENERATED FILE - DO NOT EDIT/' -e 's/PREFIX_//' -e >>>>>>>>> >>>>>>>> 's/^#.*//' >>>> >>>>> ) > /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>>> ver-release/support/gensrc/java.base/sun/nio/ch/SocketOption >>>>>>>>> Registry.java >>>>>>>>> >>>>>>>>> As I have mentioned the parameters are replaced by the bash >>>>>>>>> automatically >>>>>>>>> 3) Then build continues, then little later stops at a super >>>>>>>>> simple command: >>>>>>>>> >>>>>>>>> mv /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java.tmp >>>>>>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>>> ver-release/support/gensrc/java.base/java/nio/ByteBuffer.java >>>>>>>>> Needless to say, the ByteBuffer.java.tmp file DOES >>>>>>>>> >>>>>>>> exist. >>>> >>>>> And running the above command from the bash works, and build >>>>>>>>> >>>>>>>> continues. >>>> >>>>> 4) A few similar cases (stops) with DirectByteBuffer and >>>>>>>>> DirectByteBufferR >>>>>>>>> >>>>>>>>> >>>>>>>>> Currently I try to explore how that might relate to the MSYS2 bash >>>>>>>>> >>>>>>>> and >>>> >>>>> make, somehow it behaves differently >>>>>>>>> >>>>>>>>> If you have any other suggestion, let me know. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> From: Peter Budai >>>>>>>>> Sent: Thursday, October 5, 2017 3:52 PM >>>>>>>>> To: Magnus Ihse Bursie; Erik >>>>>>>>> Joelsson; >>>>>>>>> >>>>>>>> build-dev at openjdk.java.net >>>> >>>>> >>>>>>>> >>>>>>>> .java.net> >>>> >>>>> Subject: RE: Building OpenJDK9 on MSYS2 >>>>>>>>> >>>>>>>>> Hi Magnus, >>>>>>>>> >>>>>>>>> So first of all, here is the current patch, which I was not able to >>>>>>>>> attach: https://pastebin.com/pwT4Ynxc >>>>>>>>> >>>>>>>>> That's surprising, since gcc is prefixed with fixpath, which it >>>>>>>>> >>>>>>>> should >>>> >>>>> not. >>>>>>>>>>> >>>>>>>>>>> Actually you DO need fixpath IMHO. >>>>>>>>>> >>>>>>>>> This is a mingw64 version of the gcc (/C/msys64/mingw64/bin/gcc), >>>>>>>>> which is a fully functional Windows executable, which expects >>>>>>>>> >>>>>>>> Windows >>>> >>>>> formatted path arguments. >>>>>>>>> As the updated build process uses EXPORT MSYS2_ARG_CONV_EXCL=* (see >>>>>>>>> that patch), none of the command line arguments are converted from >>>>>>>>> >>>>>>>> the >>>> >>>>> unix path to Windows, but fixpath does that conversion. There is a >>>>>>>>> >>>>>>>> wiki >>>> >>>>> describing more details on this: >>>>>>>>> https://github.com/msys2/msys2/wiki/Porting#user-content- >>>>>>>>> filesystem-namespaces >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> I have a hard time believing this is a race condition. On the other >>>>>>>>> >>>>>>>>>> hand, this stuff is weird, we're misusing the C preprocessor to >>>>>>>>>>> >>>>>>>>>> process >>>> >>>>> defines in java code, so I'm not surprised it breaks down. >>>>>>>>>>> I don't know why it succeeded when run on the command line, >>>>>>>>>>> >>>>>>>>>> though. >>>> >>>>> When I execute that command from the bash command line there is no >>>>>>>>>> >>>>>>>>> EXPORT MSYS2_ARG_CONV_EXCL, but the bash itself does the automatic >>>>>>>>> conversion of the arguments. Maybe it has something to do how >>>>>>>>> >>>>>>>> fixpath does >>>> >>>>> CreateProcess? >>>>>>>>> >>>>>>>>> Does that help? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Peter >>>>>>>>> >>>>>>>>> Sent from Mail for >>>>>>>>> Windows 10 >>>>>>>>> >>>>>>>>> From: Magnus Ihse Bursie >>>>>>>>> Sent: Thursday, October 5, 2017 12:13 PM >>>>>>>>> To: Peter Budai; Erik >>>>>>>>> >>>>>>>> Joelsson>>> >>>>> erik.joelsson at oracle.com>; build-dev at openjdk.java.net>>>>>>>> build-dev at openjdk.java.net> >>>>>>>>> Subject: Re: Building OpenJDK9 on MSYS2 >>>>>>>>> >>>>>>>>> >>>>>>>>> On 2017-10-05 11:59, Peter Budai wrote: >>>>>>>>> Hi Magnus and Erik, >>>>>>>>> >>>>>>>>> I really appreciate your quick feedback. I assumed that it won?t be >>>>>>>>> easy, but I just don?t feel I should give up now - maybe later >>>>>>>>> >>>>>>>> when I see >>>> >>>>> the real scale of work. So bear with me for a time being. >>>>>>>>> >>>>>>>>> Attached is a patch which already includes Magnus? changes, plus a >>>>>>>>> >>>>>>>> few >>>> >>>>> which I have added: >>>>>>>>> ? basically enabling gcc for windows, >>>>>>>>> ? and modifying a logic for compiling fixpath (before that it >>>>>>>>> was using hard-coded MS VSC compile flags) >>>>>>>>> >>>>>>>>> Actually, you must make sure fixpath is *not* used for the >>>>>>>>> >>>>>>>> toolchain, >>>> >>>>> since gcc uses unix style paths. >>>>>>>>> (However, other tools such as java will still need it.) >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> So here is what I have as the result of configure: >>>>>>>>> ==================================================== >>>>>>>>> The existing configuration has been successfully updated in >>>>>>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>>> ver-release >>>>>>>>> using configure arguments '--disable-freetype-bundling >>>>>>>>> --disable-javac-server'. >>>>>>>>> >>>>>>>>> Configuration summary: >>>>>>>>> * Debug level: release >>>>>>>>> * HS debug level: product >>>>>>>>> * JDK variant: normal >>>>>>>>> * JVM variants: server >>>>>>>>> * OpenJDK target: OS: windows, CPU architecture: x86, address >>>>>>>>> >>>>>>>> length: >>>> >>>>> 64 >>>>>>>>> * Version string: 9-internal+0-adhoc.peterbud.jdk9 (9-internal) >>>>>>>>> >>>>>>>>> Tools summary: >>>>>>>>> * Environment: msys version 2.9.0(0.318/5/3) (root at /C/msys64) >>>>>>>>> * Boot JDK: java version "1.8.0_144" Java(TM) SE Runtime >>>>>>>>> Environment (build 1.8.0_144-b01) Java HotSpot(TM) 64-Bit Server >>>>>>>>> >>>>>>>> VM (build >>>> >>>>> 25.144-b01, mixed mode) (at /c/progra~1/java/jdk18~1.0_1) >>>>>>>>> * Toolchain: gcc (GNU Compiler Collection) >>>>>>>>> * C Compiler: Version 7.2.0 (at /C/msys64/mingw64/bin/gcc) >>>>>>>>> * C++ Compiler: Version 7.2.0 (at /c/msys64/mingw64/bin/g++) >>>>>>>>> >>>>>>>>> Build performance summary: >>>>>>>>> * Cores to use: 4 >>>>>>>>> * Memory limit: 16216 MB >>>>>>>>> >>>>>>>>> Its clear says that the toolchain is gcc 7.2 (BTW there is no >>>>>>>>> Visual >>>>>>>>> Studio on this machine) >>>>>>>>> >>>>>>>>> Now for the details of the config log, you can see here: >>>>>>>>> https://pastebin.com/MN2ZYcHH >>>>>>>>> >>>>>>>>> And about the build process and the error I get: >>>>>>>>> >>>>>>>>> $ make JOBS=1 >>>>>>>>> Building target 'default (exploded-image)' in configuration >>>>>>>>> 'windows-x86_64-normal-server-release' >>>>>>>>> Compiling 8 files for BUILD_TOOLS_LANGTOOLS >>>>>>>>> Compiling 17 properties into resource bundles for jdk.compiler >>>>>>>>> Parsing 1 properties into enum-like class for jdk.compiler >>>>>>>>> Compiling 19 properties into resource bundles for jdk.javadoc >>>>>>>>> Compiling 12 properties into resource bundles for jdk.jdeps >>>>>>>>> Compiling 7 properties into resource bundles for jdk.jshell >>>>>>>>> Compiling 117 files for BUILD_INTERIM_java.compiler >>>>>>>>> Compiling 396 files for BUILD_INTERIM_jdk.compiler >>>>>>>>> Compiling 61 files for BUILD_INTERIM_jdk.jdeps >>>>>>>>> Compiling 457 files for BUILD_INTERIM_jdk.javadoc >>>>>>>>> Note: Some input files use or override a deprecated API. >>>>>>>>> Note: Recompile with -Xlint:deprecation for details. >>>>>>>>> Compiling 159 files for BUILD_TOOLS_JDK >>>>>>>>> Note: Some input files use unchecked or unsafe operations. >>>>>>>>> Note: Recompile with -Xlint:unchecked for details. >>>>>>>>> make[3]: *** [GensrcMisc.gmk:78: /C/msys64/home/peterbud/jdk9/b >>>>>>>>> uild/windows-x86_64-normal-server-release/support/gensrc/jav >>>>>>>>> a.base/sun/nio/ch/SocketOptionRegistry.java] Error 1 >>>>>>>>> make[3]: *** Deleting file '/C/msys64/home/peterbud/jdk9/ >>>>>>>>> build/windows-x86_64-normal-server-release/support/gensrc/ja >>>>>>>>> va.base/sun/nio/ch/SocketOptionRegistry.java' >>>>>>>>> make[2]: *** [make/Main.gmk:115: java.base-gensrc-jdk] Error 2 >>>>>>>>> >>>>>>>>> ERROR: Build failed for target 'default (exploded-image)' in >>>>>>>>> configuration 'windows-x86_64-normal-server-release' (exit code 2) >>>>>>>>> >>>>>>>>> No indication of failed target found. >>>>>>>>> Hint: Try searching the build log for '] Error'. >>>>>>>>> Hint: See common/doc/building.html#troubleshooting for assistance. >>>>>>>>> >>>>>>>>> make[1]: *** [/home/peterbud/jdk9/make/Init.gmk:296: main] Error 2 >>>>>>>>> make: *** [/home/peterbud/jdk9/make/Init.gmk:185: default] Error 2 >>>>>>>>> >>>>>>>>> If I run here >>>>>>>>> make JOBS=1 LOG=debug >>>>>>>>> The failing line seems to be this: >>>>>>>>> >>>>>>>>> ( /usr/bin/gawk '/@@END_COPYRIGHT@@/{exit}1' >>>>>>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>>>>>> /sun/nio/ch/SocketOptionRegistry.java.template && >>>>>>>>> /C/msys64/home/peterbud/jdk9/build/windows-x86_64-normal-ser >>>>>>>>> ver-release/configure-support/bin/fixpath.exe >>>>>>>>> -m/C/msys64/@/c/msys64/@/c/progra~ /C/msys64/mingw64/bin/gcc -E -x >>>>>>>>> >>>>>>>> c >>>> >>>>> /C/msys64/home/peterbud/jdk9/jdk/src/java.base/share/classes >>>>>>>>> /sun/nio/ch/SocketOptionRegistry.java.template 2> >(/usr/bin/grep >>>>>>>>> >>>>>>>> -v >>>> >>>>> '^SocketOptionRegistry.java.template$' >&2) | /usr/bin/gawk >>>>>>>> >>>>>>>> From dalibor.topic at oracle.com Mon Nov 27 14:51:53 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 27 Nov 2017 15:51:53 +0100 Subject: Building OpenJDK9 on MSYS2 In-Reply-To: References: Message-ID: On 27.11.2017 15:17, Thomas St?fe wrote: > Also the question of who is supposed to maintain it in the long run should > be answered. We are usually quite strict in adding new platforms - I > remember the recent BSD port discussions, which I believe ended in 1) needs > a long term maintainer, preferably a company or foundation To be more specific, adding a new platform (such as cygwin-newlib-gcc) would need to be accompanied by a JEP, and someone (an individual, or a few, or a lot of them) signing up to do the work on the JEP, i.e. the JEP would need to be 'funded'. Whether those individuals are also members of a single legal entity or not does not matter much in theory. In practice, of course, legal entities might able to muster more resources in the pursuit of their goals than a single individual. >2) must pass TCK > *before* being added to the mainline. The BSD people did not meet the > restrictions, so they are still in their port branch. Which, btw, would be > a solution for msys2+gcc port too: work in their own branch until the > conditions are met to migrate to the base line? I'd suggest that work on something adding a new platform such as cygwin-newlib-gcc would usually be better off in its own Project, as that allows the Project's contributors to bootstrap a port and the assiciated roles (Committer, Reviewer, etc) without having to 'earn merit' as mainline committers first. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From erik.joelsson at oracle.com Mon Nov 27 16:40:32 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 08:40:32 -0800 Subject: RFR: JDK-8177957 run-test summary lines look bad/misleading with long test names In-Reply-To: <47bd3693-1dd8-2a18-60c5-1368669913f0@oracle.com> References: <47bd3693-1dd8-2a18-60c5-1368669913f0@oracle.com> Message-ID: <2c0e6655-1a06-1a45-e374-a6768ffd5899@oracle.com> Looks good. /Erik On 2017-11-24 01:28, Magnus Ihse Bursie wrote: > When running individual tests using run-test, the summary section gets > hard to read. For instance: (imagine having a fixed-with font :)) > ???TEST TOTAL PASS FAIL ERROR > ???jtreg:hotspot/test/gc/stress/gcbasher/TestGCBasherWithG1.java 1 1 0 0 > > What makes this exact example even worse is that it aligns so bad so > that the "1" belonging to the TOTAL column, ends up aligned with the > FAIL label, so it looks as if the test failed. > > If the test name is too long to fit before the number columns, we > should add a line break, so the numbers still align on the right > columns, but on the line after. > > This bug also fixes some remaining issues from JDK-8191820: > * jtreg test descriptors are now normalized to TOPDIR (or CUSTOM_ROOT, > if present). (Without this fix, almost all test names were too long.) > * Do not disallow running named test groups for jtreg tests out-of-tree. > * And a simplification in the matching for paths (we didn't need to > treat absolute paths differently). > > Bug: https://bugs.openjdk.java.net/browse/JDK-8177957 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8177957-linebreak-long-test-names/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Nov 27 16:41:38 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 08:41:38 -0800 Subject: RFR: JDK-8179554 make run-test does not respect ProblemList.txt In-Reply-To: References: Message-ID: Looks good. /Erik On 2017-11-24 02:14, Magnus Ihse Bursie wrote: > When running tests with `make run-test`, tests from > jdk/test/ProblemList.txt and/or hotspot/test/ProblemList.txt aren't > excluded. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179554 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8179554-run-test-should-respect-problem-list/webrev.01 > > /Magnus From erik.joelsson at oracle.com Mon Nov 27 16:42:33 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 08:42:33 -0800 Subject: RFR: JDK-8179555 make run-test should always use a fresh, clean JTwork directory In-Reply-To: References: Message-ID: <56aae7ef-426b-056c-037a-2b7075f2808b@oracle.com> Looks good. /Erik On 2017-11-24 02:23, Magnus Ihse Bursie wrote: > When running jtreg tests, make run-test should always run with a > fresh, clean JTwork directory in order to avoid issues with code not > being recompiled. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8179555 > Patch inline: > diff --git a/make/RunTests.gmk b/make/RunTests.gmk > --- a/make/RunTests.gmk > +++ b/make/RunTests.gmk > @@ -407,7 +407,10 @@ > ???? $1_JTREG_BASIC_OPTIONS += -cpa:$$(JIB_JAR) > ?? endif > > -? run-test-$1: > +? clean-workdir-$1: > +?????? $$(RM) -r $$($1_TEST_SUPPORT_DIR) > + > +? run-test-$1: clean-workdir-$1 > ??????? $$(call LogWarn) > ??????? $$(call LogWarn, Running test '$$($1_TEST)') > ??????? $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR)) > > /Magnus > From erik.joelsson at oracle.com Mon Nov 27 16:46:27 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 08:46:27 -0800 Subject: RFR: JDK-8189099 JTReg now supports 256 jobs In-Reply-To: <8916640d-f219-3b22-04d0-b6e9f36485c4@oracle.com> References: <8916640d-f219-3b22-04d0-b6e9f36485c4@oracle.com> Message-ID: <74a27f5a-fd7f-320f-37bf-1d8484a38c08@oracle.com> Looks good. /Erik On 2017-11-24 02:22, Magnus Ihse Bursie wrote: > From the bug report: > "According to research by Jonathan Gibbons , JTReg now supports 256 > jobs, in contrast to the older limit of 50 jobs. This limit is > enforced in the make files, and it should be updated to reflect the > new limit (or the check removed entirely)." > > I choose to remove the check. If you send in more than JOBS=256, then > JTReg will complain. If that limit is ever increased, it should only > be done so in JTReg, not also in the makefiles. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189099 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8189099-remove-jtreg-job-limit-of-50/webrev.01 > > /Magnus > From erik.joelsson at oracle.com Mon Nov 27 16:54:58 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 08:54:58 -0800 Subject: RFR: JDK-8191856 "make clean-test" does not work properly In-Reply-To: <9725cfb4-eba3-f8f3-9b7e-a35c7176b6dd@oracle.com> References: <9725cfb4-eba3-f8f3-9b7e-a35c7176b6dd@oracle.com> Message-ID: Looks good. /Erik On 2017-11-24 02:45, Magnus Ihse Bursie wrote: > With the new layout of make run-test, the test-results and > test-support directories are not removed by "make clean-test", and not > even "make clean". > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191856 > Patch inline: > diff --git a/make/Main.gmk b/make/Main.gmk > --- a/make/Main.gmk > +++ b/make/Main.gmk > @@ -1049,7 +1049,7 @@ > ?# file. > > ?CLEAN_DIRS += hotspot jdk bootcycle-build test buildtools support \ > -??? images make-support test-make bundles buildjdk > +??? images make-support test-make bundles buildjdk test-results > test-support > ?CLEAN_DIR_TARGETS := $(addprefix clean-, $(CLEAN_DIRS)) > ?CLEAN_SUPPORT_DIRS += demos > ?CLEAN_SUPPORT_DIR_TARGETS := $(addprefix clean-, $(CLEAN_SUPPORT_DIRS)) > @@ -1094,6 +1094,8 @@ > ?# while classes and touch files end up in jdk. > ?clean-support: clean-jdk > > +clean-test: clean-test-results clean-test-support > + > ?# Remove everything, including configure configuration. If the output > ?# directory was created by configure and now becomes empty, remove it > as well. > ?dist-clean: clean > > /Magnus From tim.bell at oracle.com Mon Nov 27 17:17:15 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 27 Nov 2017 09:17:15 -0800 Subject: RFR: JDK-8179554 make run-test does not respect ProblemList.txt In-Reply-To: References: Message-ID: <5A1C489B.6090203@oracle.com> Magnus: Looks good to me as well. Tim On 11/27/17 08:41, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2017-11-24 02:14, Magnus Ihse Bursie wrote: >> When running tests with `make run-test`, tests from >> jdk/test/ProblemList.txt and/or hotspot/test/ProblemList.txt aren't >> excluded. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8179554 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8179554-run-test-should-respect-problem-list/webrev.01 >> >> >> /Magnus > From tim.bell at oracle.com Mon Nov 27 17:19:18 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 27 Nov 2017 09:19:18 -0800 Subject: RFR: JDK-8179555 make run-test should always use a fresh, clean JTwork directory In-Reply-To: <56aae7ef-426b-056c-037a-2b7075f2808b@oracle.com> References: <56aae7ef-426b-056c-037a-2b7075f2808b@oracle.com> Message-ID: <5A1C4916.4000608@oracle.com> Magnus: > "...always run with a fresh, clean JTwork directory..." I couldn't agree more. Looks good to me as well. Tim On 11/27/17 08:42, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2017-11-24 02:23, Magnus Ihse Bursie wrote: >> When running jtreg tests, make run-test should always run with a >> fresh, clean JTwork directory in order to avoid issues with code not >> being recompiled. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8179555 >> Patch inline: >> diff --git a/make/RunTests.gmk b/make/RunTests.gmk >> --- a/make/RunTests.gmk >> +++ b/make/RunTests.gmk >> @@ -407,7 +407,10 @@ >> $1_JTREG_BASIC_OPTIONS += -cpa:$$(JIB_JAR) >> endif >> >> - run-test-$1: >> + clean-workdir-$1: >> + $$(RM) -r $$($1_TEST_SUPPORT_DIR) >> + >> + run-test-$1: clean-workdir-$1 >> $$(call LogWarn) >> $$(call LogWarn, Running test '$$($1_TEST)') >> $$(call MakeDir, $$($1_TEST_RESULTS_DIR) $$($1_TEST_SUPPORT_DIR)) >> >> /Magnus >> > From magnus.ihse.bursie at oracle.com Mon Nov 27 18:41:53 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 27 Nov 2017 19:41:53 +0100 Subject: RFR: JDK-8191923 Save run-test summary to file Message-ID: We should save the run-test summary to a file. Bug: https://bugs.openjdk.java.net/browse/JDK-8191923 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01 /Magnus From tim.bell at oracle.com Mon Nov 27 17:56:59 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 27 Nov 2017 09:56:59 -0800 Subject: RFR: JDK-8191923 Save run-test summary to file In-Reply-To: References: Message-ID: <5A1C51EB.8070901@oracle.com> Magnus: > We should save the run-test summary to a file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191923 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01 Looks good. /Tim From erik.joelsson at oracle.com Mon Nov 27 19:02:12 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 11:02:12 -0800 Subject: RFR: JDK-8191923 Save run-test summary to file In-Reply-To: References: Message-ID: Looks good. /Erik On 2017-11-27 10:41, Magnus Ihse Bursie wrote: > We should save the run-test summary to a file. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191923 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01 > > /Magnus From maurizio.cimadamore at oracle.com Mon Nov 27 19:14:27 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Mon, 27 Nov 2017 19:14:27 +0000 Subject: on jdk.internal.vm.ci Message-ID: Hi, the IntelliJ support for JDK relies on make to give the set of source roots used for any given modules. I have noticed that the set of source roots associated with 'jdk.internal.vm.ci' is incorrect, as it points to src/jdk.internal.vm.ci/share/classes while in reality it should point to a subset of directories contained in such a folder (depending on the architecture). This breaks the IntelliJ project configuration if jdk.internal.vm.ci is selected - which is causing issues for some, see [1]. [1] - http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-November/000590.html Maurizio From magnus.ihse.bursie at oracle.com Mon Nov 27 19:59:01 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 27 Nov 2017 20:59:01 +0100 Subject: RFR: JDK-8191923 Save run-test summary to file In-Reply-To: References: Message-ID: <97037e83-614b-564f-b31c-ca84b90bb54a@oracle.com> On 2017-11-27 20:02, Erik Joelsson wrote: > Looks good. Only it didn't. :-) I managed to drop one (very important) line when juggling this patch between my sandbox and the repo. Updated WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02 /Magnus > > /Erik > > > On 2017-11-27 10:41, Magnus Ihse Bursie wrote: >> We should save the run-test summary to a file. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191923 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01 >> >> /Magnus > From tim.bell at oracle.com Mon Nov 27 19:04:23 2017 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 27 Nov 2017 11:04:23 -0800 Subject: RFR: JDK-8191923 Save run-test summary to file In-Reply-To: <97037e83-614b-564f-b31c-ca84b90bb54a@oracle.com> References: <97037e83-614b-564f-b31c-ca84b90bb54a@oracle.com> Message-ID: <5A1C61B7.90900@oracle.com> Magnus: > On 2017-11-27 20:02, Erik Joelsson wrote: >> Looks good. > Only it didn't. :-) > > I managed to drop one (very important) line when juggling this patch > between my sandbox and the repo. > > Updated WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02 Yes, indeed. That would do it. Looks good. Tim > /Magnus > >> >> /Erik >> >> >> On 2017-11-27 10:41, Magnus Ihse Bursie wrote: >>> We should save the run-test summary to a file. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191923 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01 >>> >>> >>> /Magnus >> > From magnus.ihse.bursie at oracle.com Mon Nov 27 21:39:46 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 27 Nov 2017 22:39:46 +0100 Subject: RFR: JDK-8191933 Use failure handler in run-test Message-ID: The jtreg failure handler needs to be used when running tests using the run-test framework. Bug: https://bugs.openjdk.java.net/browse/JDK-8191933 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191933-use-failure-handler-in-run-test/webrev.01 /Magnus From erik.joelsson at oracle.com Mon Nov 27 21:52:24 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 13:52:24 -0800 Subject: RFR: JDK-8191923 Save run-test summary to file In-Reply-To: <97037e83-614b-564f-b31c-ca84b90bb54a@oracle.com> References: <97037e83-614b-564f-b31c-ca84b90bb54a@oracle.com> Message-ID: <500c6770-a3ec-9cfe-e585-d92811ead678@oracle.com> You need a definition of the variable? Couldn't the user just be required to define it when running tests? Looks good. /Erik On 2017-11-27 11:59, Magnus Ihse Bursie wrote: > On 2017-11-27 20:02, Erik Joelsson wrote: >> Looks good. > Only it didn't. :-) > > I managed to drop one (very important) line when juggling this patch > between my sandbox and the repo. > > Updated WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02 > > /Magnus > >> >> /Erik >> >> >> On 2017-11-27 10:41, Magnus Ihse Bursie wrote: >>> We should save the run-test summary to a file. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191923 >>> WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01 >>> >>> /Magnus >> > From magnus.ihse.bursie at oracle.com Mon Nov 27 22:19:19 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 27 Nov 2017 23:19:19 +0100 Subject: RFR: JDK-8191923 Save run-test summary to file In-Reply-To: <500c6770-a3ec-9cfe-e585-d92811ead678@oracle.com> References: <97037e83-614b-564f-b31c-ca84b90bb54a@oracle.com> <500c6770-a3ec-9cfe-e585-d92811ead678@oracle.com> Message-ID: On 2017-11-27 22:52, Erik Joelsson wrote: > You need a definition of the variable? Couldn't the user just be > required to define it when running tests? I'm not sure what you mean. The intention is to not only print the output, but to also store it in the test-results directory. I don't think the test result directory should be specifically user overridable. If it should be (why?), there's more places to update. /Magnus > > Looks good. > > /Erik > > > On 2017-11-27 11:59, Magnus Ihse Bursie wrote: >> On 2017-11-27 20:02, Erik Joelsson wrote: >>> Looks good. >> Only it didn't. :-) >> >> I managed to drop one (very important) line when juggling this patch >> between my sandbox and the repo. >> >> Updated WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02 >> >> /Magnus >> >>> >>> /Erik >>> >>> >>> On 2017-11-27 10:41, Magnus Ihse Bursie wrote: >>>> We should save the run-test summary to a file. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191923 >>>> WebRev: >>>> http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01 >>>> >>>> /Magnus >>> >> > From erik.joelsson at oracle.com Mon Nov 27 22:20:58 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 14:20:58 -0800 Subject: RFR: JDK-8191923 Save run-test summary to file In-Reply-To: References: <97037e83-614b-564f-b31c-ca84b90bb54a@oracle.com> <500c6770-a3ec-9cfe-e585-d92811ead678@oracle.com> Message-ID: On 2017-11-27 14:19, Magnus Ihse Bursie wrote: > On 2017-11-27 22:52, Erik Joelsson wrote: >> You need a definition of the variable? Couldn't the user just be >> required to define it when running tests? Sorry, I meant this as a joke but forgot to add the smiley. :) /Erik > I'm not sure what you mean. The intention is to not only print the > output, but to also store it in the test-results directory. I don't > think the test result directory should be specifically user > overridable. If it should be (why?), there's more places to update. > > /Magnus >> >> Looks good. >> >> /Erik >> >> >> On 2017-11-27 11:59, Magnus Ihse Bursie wrote: >>> On 2017-11-27 20:02, Erik Joelsson wrote: >>>> Looks good. >>> Only it didn't. :-) >>> >>> I managed to drop one (very important) line when juggling this patch >>> between my sandbox and the repo. >>> >>> Updated WebRev: >>> http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.02 >>> >>> /Magnus >>> >>>> >>>> /Erik >>>> >>>> >>>> On 2017-11-27 10:41, Magnus Ihse Bursie wrote: >>>>> We should save the run-test summary to a file. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191923 >>>>> WebRev: >>>>> http://cr.openjdk.java.net/~ihse/JDK-8191923-save-run-test-summary-to-file/webrev.01 >>>>> >>>>> /Magnus >>>> >>> >> > From magnus.ihse.bursie at oracle.com Mon Nov 27 23:11:13 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 28 Nov 2017 00:11:13 +0100 Subject: RFR: JDK-8177956 Add TEST_VM_OPTS as convenience for run-test arguments Message-ID: <674c5289-5b8c-d1c3-30ac-107f79d6f4e2@oracle.com> From the bug report: A common scenario is adding vm arguments when running tests. While this can be accomplished by JTREG="VM_OPTIONS=-Xfoo", this is a lot to type for a common case. In the future, when gtest accepts vm arguments as well, a separate, similar but yet different GTEST="VM_OPTIONS=-Xfoo" would be needed. A new "global" TEST_VM_OPTS=X should behave as if VM_OPTIONS=X were present on all applicable test framework option control variables. My solution also adds a new "global" TEST_OPTS, where TEST_VM_OPTS=-Xfoo behaves identical to TEST_OPTS="VM_OPTIONS=-Xfoo", but which also allows other global settings. It also adds support for VM_OPTIONS to gtest, and it improves error resilience in gtest result parsing. Bug: https://bugs.openjdk.java.net/browse/JDK-8177956 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8177956-add-TEST_OPTS/webrev.01 /Magnus From erik.joelsson at oracle.com Mon Nov 27 23:44:54 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 27 Nov 2017 15:44:54 -0800 Subject: RFR: JDK-8177956 Add TEST_VM_OPTS as convenience for run-test arguments In-Reply-To: <674c5289-5b8c-d1c3-30ac-107f79d6f4e2@oracle.com> References: <674c5289-5b8c-d1c3-30ac-107f79d6f4e2@oracle.com> Message-ID: Looks good. /Erik On 2017-11-27 15:11, Magnus Ihse Bursie wrote: > From the bug report: > > A common scenario is adding vm arguments when running tests. While > this can be accomplished by JTREG="VM_OPTIONS=-Xfoo", this is a lot to > type for a common case. In the future, when gtest accepts vm arguments > as well, a separate, similar but yet different > GTEST="VM_OPTIONS=-Xfoo" would be needed. > > A new "global" TEST_VM_OPTS=X should behave as if VM_OPTIONS=X were > present on all applicable test framework option control variables. > > My solution also adds a new "global" TEST_OPTS, where > TEST_VM_OPTS=-Xfoo behaves identical to TEST_OPTS="VM_OPTIONS=-Xfoo", > but which also allows other global settings. It also adds support for > VM_OPTIONS to gtest, and it improves error resilience in gtest result > parsing. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8177956 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8177956-add-TEST_OPTS/webrev.01 > > /Magnus > From mandy.chung at oracle.com Tue Nov 28 01:50:04 2017 From: mandy.chung at oracle.com (mandy chung) Date: Mon, 27 Nov 2017 17:50:04 -0800 Subject: Review Request: JDK-8191942: Replace jdeps use of jdk.internal.util.jar.VersionedStream with new public API Message-ID: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com> This is a follow-up on JDK-8189611 that defines a new public API to return a stream of versioned entries and to return the real name of a JAR entry.? JDK-8189611 leaves jdeps untouched because jdeps is compiled with the boot JDK. This patch includes: (1) changes the build not to build jdk.jdeps interim module but include com.sun.tools.classfile classes in the CreateSymbol buildtool (2) replace the use of internal API with the public APIs defined by JDK-8191942 (3) remove jdk.internal.util.jar.VersonedStream class Webrev: http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8191942/webrev.00/ Thanks Mandy From Sergey.Bylokhov at oracle.com Tue Nov 28 02:27:54 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 27 Nov 2017 18:27:54 -0800 Subject: [10] Review Request: 8189656 The Windows L&F should be moved out from the shared folder Message-ID: Hello. Please review the fix for jdk10. This is the second attempt to move windows L&F from non-windows platforms. The first attempt JDK-6461834[1] was reverted because of JDK-8184813[2]. The root cause of those issue was fixed in JDK-8075255[3], and now we can move it again. Bug: https://bugs.openjdk.java.net/browse/JDK-8189656 Webrev can be found at: http://cr.openjdk.java.net/~serb/8189656/webrev.02 The fix contains a few parts: - The code related to win l&f was moved from the "share" to the "windows" folder - The platform-specific export was moved from module-info.java to module-info.java.extra - A number of tests which use windows L&F were marked as windows-specific - The stub "ThemeReader.java" which was used to build win w&f on unix was removed. [1] https://bugs.openjdk.java.net/browse/JDK-6461834 [2] https://bugs.openjdk.java.net/browse/JDK-8184813 [3] https://bugs.openjdk.java.net/browse/JDK-8075255 -- Best regards, Sergey. From david.holmes at oracle.com Tue Nov 28 06:35:27 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 28 Nov 2017 16:35:27 +1000 Subject: problem building client variant in 9.0.1+11 In-Reply-To: References: Message-ID: <54a69350-56dc-4c18-1d15-34a38255c976@oracle.com> Hi Mete, A 64-bit client build, stand-alone, is not supported. There could be more issues than just getting the build to not fail. David On 23/11/2017 11:32 PM, Mete Balci wrote: > Hi, > > I am trying to build the client variant, but it fails with the output > below. Is this a known issue or is there any specific configure option I > should use ? > > Thanks, > > Mete > > Compiling 4 files for BUILD_JIGSAW_TOOLS > Error: missing `server' JVM at > `/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/lib/server/libjvm.so'. > Please install or use the JRE or JDK that contains these missing components. > ExplodedImageOptimize.gmk:40: recipe for target > '/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done' > failed > make[3]: *** > [/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done] > Error 4 > make/Main.gmk:356: recipe for target 'exploded-image-optimize' failed > make[2]: *** [exploded-image-optimize] Error 1 > From prasanta.sadhukhan at oracle.com Tue Nov 28 09:51:42 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Tue, 28 Nov 2017 15:21:42 +0530 Subject: [10] Review Request: 8189656 The Windows L&F should be moved out from the shared folder In-Reply-To: References: Message-ID: looks good to me. Dont we need to add this bugid to the tests? Regards Prasanta On 11/28/2017 7:57 AM, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk10. This is the second attempt to move > windows L&F from non-windows platforms. The first attempt > JDK-6461834[1] was reverted because of JDK-8184813[2]. > The root cause of those issue was fixed in JDK-8075255[3], and now we > can move it again. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189656 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8189656/webrev.02 > > The fix contains a few parts: > ?- The code related to win l&f was moved from the "share" to the > "windows" folder > ?- The platform-specific export was moved from module-info.java to > module-info.java.extra > ?- A number of tests which use windows L&F were marked as > windows-specific > ?- The stub "ThemeReader.java" which was used to build win w&f on unix > was removed. > > [1] https://bugs.openjdk.java.net/browse/JDK-6461834 > [2] https://bugs.openjdk.java.net/browse/JDK-8184813 > [3] https://bugs.openjdk.java.net/browse/JDK-8075255 > From maurizio.cimadamore at oracle.com Tue Nov 28 11:16:32 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 28 Nov 2017 11:16:32 +0000 Subject: on jdk.internal.vm.ci In-Reply-To: References: Message-ID: <54e79340-8117-0d96-cfff-f3fdff08642b@oracle.com> Some more specifics - these lines in the makefiles (CompileJavaModules.gmk) are used to workaround the layout oddities: ifeq ($(MODULE), jdk.internal.vm.ci) ? ## WORKAROUND jdk.internal.vm.ci source structure issue ? JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \ ????? $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ ????????? $(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src))) ? MODULESOURCEPATH := $(call PathList, $(JVMCI_MODULESOURCEPATH)) endif ifeq ($(MODULE), jdk.internal.vm.compiler) ? ## WORKAROUND jdk.internal.vm.compiler source structure issue ? VM_COMPILER_MODULESOURCEPATH := $(MODULESOURCEPATH) \ ????? $(subst /$(MODULE)/,/*/, $(filter-out %processor/src %test/src %jtt/src %bench/src %microbenchmarks/src, \ ????????? $(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src))) ? MODULESOURCEPATH := $(call PathList, $(VM_COMPILER_MODULESOURCEPATH)) endif ifeq ($(MODULE), jdk.aot) ? ## WORKAROUND jdk.aot source structure issue ? AOT_MODULESOURCEPATH := $(MODULESOURCEPATH) \ ????? $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ ????????? $(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src))) ? MODULESOURCEPATH := $(call PathList, $(AOT_MODULESOURCEPATH)) endif Now, I'm fine with this module having a non-standard layout, but I think it would be great if the build could paper over those differences and yield a set of make variables that looks like that of any other module. More importantly, the sources above are not returned by a call to FindModuleSrcDirs, (e.g. MODULE_SRC_DIRS is not set correctly for these) and I think they should. Maurizio On 27/11/17 19:14, Maurizio Cimadamore wrote: > Hi, > the IntelliJ support for JDK relies on make to give the set of source > roots used for any given modules. I have noticed that the set of > source roots associated with 'jdk.internal.vm.ci' is incorrect, as it > points to > > src/jdk.internal.vm.ci/share/classes > > while in reality it should point to a subset of directories contained > in such a folder (depending on the architecture). > > This breaks the IntelliJ project configuration if jdk.internal.vm.ci > is selected - which is causing issues for some, see [1]. > > [1] - > http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-November/000590.html > > Maurizio > From rahul.v.raghavan at oracle.com Tue Nov 28 12:04:01 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Tue, 28 Nov 2017 17:34:01 +0530 Subject: RFR: 8187676: Disable harmless uninitialized warnings for two files In-Reply-To: <1a8dd6cc-8cf2-bb0e-af09-ea53324c85e3@oracle.com> References: <2031be3e-2623-dde1-fff2-2d6cd6e41de9@oracle.com> <7512e87d-4e28-27a1-5e10-5cdfa794cdf4@oracle.com> <4f5b0427-54bf-2b85-0a94-bb41049d2676@oracle.com> <1a8dd6cc-8cf2-bb0e-af09-ea53324c85e3@oracle.com> Message-ID: <7cd41397-6f67-5bca-f08d-d85d73bcd631@oracle.com> Hi, Further to below email thread - https://bugs.openjdk.java.net/browse/JDK-8187676 https://bugs.openjdk.java.net/browse/JDK-8160404 Please note 8187676 task was blocked by related 8160404. But as mentioned in latest jbs comments of 8160404, found the build warning with gcc7 persists with latest 8160404-patch. More work to be done for complete, correct fix of 8160404. But for now will request to defer 8160404 task to jdk11. Since 8160404 is taking more time, as Erik suggested earlier, can we please go ahead, get approval and disable the gcc warnings for now as part of 8187676 fix - http://cr.openjdk.java.net/~ehelin/8187676/00/ and re-enable later as part of 8160404 patch. Understood that now only the problems highlighted by JDK-8187676/8160404 is stopping hotspot from compiling with more recent versions of GCC. Also as Erik mentioned earlier, disabling these uninitialized warnings seems to be harmless. Thanks, Rahul On Thursday 21 September 2017 02:32 PM, Erik Helin wrote: > Ok, lets wait for Rahul's patches. Rahul, when you post your patches, CC > me and I can check if gcc 7.1.1 still complains :) > > Thanks, > Erik > > On 09/19/2017 06:25 PM, Vladimir Kozlov wrote: >> I would prefer to have general solution Rahul is working on because >> code is general - not only x86 is affected. >> >> Thanks, >> Vladimir >> >> On 9/19/17 7:59 AM, Rahul Raghavan wrote: >>> Hi Erik, >>> >>> Please note that this 8187676 seems to be related to 8160404. >>> ??? https://bugs.openjdk.java.net/browse/JDK-8160404 >>> ??? (RelocationHolder constructors have bugs) >>> >>> As per the latest notes comments added for 8160404-jbs, I will submit >>> webrev/RFR soon and will request help confirm similar issues with >>> latest gcc7 gets solved. >>> >>> Thanks, >>> Rahul >>> >>> On Tuesday 19 September 2017 07:07 PM, Erik Helin wrote: >>>> Hi all, >>>> >>>> with gcc 7.1.1 from Fedora 26 on x86-64 there are warnings about the >>>> potential usage of maybe uninitialized memory in >>>> src/hotspot/cpu/x86/assembler_x86.cpp and in >>>> src/hotspot/cpu/x86/interp_masm_x86.cpp. >>>> >>>> The problems arises from the class RelocationHolder in >>>> src/hotspot/share/code/relocInfo.hpp which has the private fields: >>>> ?? enum { _relocbuf_size = 5 }; >>>> ?? void* _relocbuf[ _relocbuf_size ]; >>>> >>>> and the default constructor for RelocationHolder does not initialize >>>> the elements of _relocbuf. I _think_ this is an optimization, >>>> RelocationHolder is used *a lot* and setting the elements of >>>> RelocationHolder::_relocbuf to NULL (or some other value) in the >>>> default constructor might result in a performance penalty. Have a >>>> look in >>>> build/linux-x86_64-normal-server-fastdebug/hotspot/variant-server/gensrc/adfiles >>>> and you will see that RelocationHolder is used all over the place :) >>>> >>>> AFAICS all users of RelocationHolder::_relocbuf take care to not use >>>> uninitialized memory, which means that this warning is wrong, so I >>>> suggest we disable the warning -Wmaybe-uninitialized for >>>> src/hotspot/cpu/x86/assembler_x86.cpp. >>>> >>>> The problem continues because the class Address in >>>> src/hotspot/cpu/x86/assembler_x86.hpp has a private field, >>>> `RelocationHolder _rspec;` and the default constructor for Address >>>> does not initialize _rspec._relocbuf (most likely for performance >>>> reasons). The class Address also has a default copy constructor, >>>> which will copy all the elements of _rspec._relocbuf, which will >>>> result in a read of uninitialized memory. However, this is a benign >>>> usage of uninitialized memory, since we take no action based on the >>>> content of the uninitialized memory (it is just copied byte for byte). >>>> >>>> So, in this case too, I suggest we disable the warning >>>> -Wuninitialized for src/hotspot/cpu/x86/assembler_x86.hpp. >>>> >>>> What do you think? >>>> >>>> Patch: >>>> http://cr.openjdk.java.net/~ehelin/8187676/00/ >>>> >>>> --- old/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >>>> 15:11:45.036108983 +0200 >>>> +++ new/make/hotspot/lib/JvmOverrideFiles.gmk??? 2017-09-19 >>>> 15:11:44.692107277 +0200 >>>> @@ -32,6 +32,8 @@ >>>> ? ifeq ($(TOOLCHAIN_TYPE), gcc) >>>> ??? BUILD_LIBJVM_vmStructs.cpp_CXXFLAGS := >>>> -fno-var-tracking-assignments -O0 >>>> ??? BUILD_LIBJVM_jvmciCompilerToVM.cpp_CXXFLAGS := >>>> -fno-var-tracking-assignments >>>> +? BUILD_LIBJVM_assembler_x86.cpp_CXXFLAGS := -Wno-maybe-uninitialized >>>> +? BUILD_LIBJVM_interp_masm_x86.cpp_CXXFLAGS := -Wno-uninitialized >>>> ? endif >>>> >>>> ? ifeq ($(OPENJDK_TARGET_OS), linux) >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8187676 >>>> >>>> Testing: >>>> - Compiles with: >>>> ?? - gcc 7.1.1 and glibc 2.25 on Fedora 26 >>>> ?? - gcc 4.9.2 and glibc 2.12 on OEL 6.4 >>>> - JPRT >>>> >>>> Thanks, >>>> Erik From Alan.Bateman at oracle.com Tue Nov 28 14:17:18 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 28 Nov 2017 14:17:18 +0000 Subject: Review Request: JDK-8191942: Replace jdeps use of jdk.internal.util.jar.VersionedStream with new public API In-Reply-To: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com> References: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com> Message-ID: <569d6f16-0d7c-f289-39b4-431666a50090@oracle.com> On 28/11/2017 01:50, mandy chung wrote: > This is a follow-up on JDK-8189611 that defines a new public API to > return a stream of versioned entries and to return the real name of a > JAR entry.? JDK-8189611 leaves jdeps untouched because jdeps is > compiled with the boot JDK. > > This patch includes: > (1) changes the build not to build jdk.jdeps interim module but > include com.sun.tools.classfile classes in the CreateSymbol buildtool > (2) replace the use of internal API with the public APIs defined by > JDK-8191942 > (3) remove jdk.internal.util.jar.VersonedStream class > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8191942/webrev.00/ Looks good. -Alan From tim.bell at oracle.com Tue Nov 28 15:38:30 2017 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 28 Nov 2017 07:38:30 -0800 Subject: RFR: JDK-8177956 Add TEST_VM_OPTS as convenience for run-test arguments In-Reply-To: References: <674c5289-5b8c-d1c3-30ac-107f79d6f4e2@oracle.com> Message-ID: <5A1D82F6.4040800@oracle.com> Magnus: Looks good to me as well. /Tim On 11/27/17 15:44, Erik Joelsson wrote: > Looks good. > > /Erik > > > On 2017-11-27 15:11, Magnus Ihse Bursie wrote: >> From the bug report: >> >> A common scenario is adding vm arguments when running tests. While >> this can be accomplished by JTREG="VM_OPTIONS=-Xfoo", this is a lot to >> type for a common case. In the future, when gtest accepts vm arguments >> as well, a separate, similar but yet different >> GTEST="VM_OPTIONS=-Xfoo" would be needed. >> >> A new "global" TEST_VM_OPTS=X should behave as if VM_OPTIONS=X were >> present on all applicable test framework option control variables. >> >> My solution also adds a new "global" TEST_OPTS, where >> TEST_VM_OPTS=-Xfoo behaves identical to TEST_OPTS="VM_OPTIONS=-Xfoo", >> but which also allows other global settings. It also adds support for >> VM_OPTIONS to gtest, and it improves error resilience in gtest result >> parsing. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8177956 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8177956-add-TEST_OPTS/webrev.01 >> >> /Magnus >> > From erik.joelsson at oracle.com Tue Nov 28 17:24:44 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 Nov 2017 09:24:44 -0800 Subject: Review Request: JDK-8191942: Replace jdeps use of jdk.internal.util.jar.VersionedStream with new public API In-Reply-To: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com> References: <5a63eef2-3272-1b38-63f6-70cfe30a7cfb@oracle.com> Message-ID: Build change looks good. /Erik On 2017-11-27 17:50, mandy chung wrote: > This is a follow-up on JDK-8189611 that defines a new public API to > return a stream of versioned entries and to return the real name of a > JAR entry.? JDK-8189611 leaves jdeps untouched because jdeps is > compiled with the boot JDK. > > This patch includes: > (1) changes the build not to build jdk.jdeps interim module but > include com.sun.tools.classfile classes in the CreateSymbol buildtool > (2) replace the use of internal API with the public APIs defined by > JDK-8191942 > (3) remove jdk.internal.util.jar.VersonedStream class > > Webrev: > http://cr.openjdk.java.net/~mchung/jdk10/webrevs/8191942/webrev.00/ > > Thanks > Mandy From erik.joelsson at oracle.com Tue Nov 28 17:28:57 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 Nov 2017 09:28:57 -0800 Subject: [10] Review Request: 8189656 The Windows L&F should be moved out from the shared folder In-Reply-To: References: Message-ID: <171f8e59-8f7d-2ae4-a726-06e706297db3@oracle.com> From a build point of view, this looks great. /Erik On 2017-11-27 18:27, Sergey Bylokhov wrote: > Hello. > Please review the fix for jdk10. This is the second attempt to move > windows L&F from non-windows platforms. The first attempt > JDK-6461834[1] was reverted because of JDK-8184813[2]. > The root cause of those issue was fixed in JDK-8075255[3], and now we > can move it again. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8189656 > Webrev can be found at: > http://cr.openjdk.java.net/~serb/8189656/webrev.02 > > The fix contains a few parts: > ?- The code related to win l&f was moved from the "share" to the > "windows" folder > ?- The platform-specific export was moved from module-info.java to > module-info.java.extra > ?- A number of tests which use windows L&F were marked as > windows-specific > ?- The stub "ThemeReader.java" which was used to build win w&f on unix > was removed. > > [1] https://bugs.openjdk.java.net/browse/JDK-6461834 > [2] https://bugs.openjdk.java.net/browse/JDK-8184813 > [3] https://bugs.openjdk.java.net/browse/JDK-8075255 > From erik.joelsson at oracle.com Tue Nov 28 17:30:32 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 28 Nov 2017 09:30:32 -0800 Subject: on jdk.internal.vm.ci In-Reply-To: <54e79340-8117-0d96-cfff-f3fdff08642b@oracle.com> References: <54e79340-8117-0d96-cfff-f3fdff08642b@oracle.com> Message-ID: These modules are certainly an annoyance in the build. Please file a bug with this concern. /Erik On 2017-11-28 03:16, Maurizio Cimadamore wrote: > Some more specifics - these lines in the makefiles > (CompileJavaModules.gmk) are used to workaround the layout oddities: > > ifeq ($(MODULE), jdk.internal.vm.ci) > ? ## WORKAROUND jdk.internal.vm.ci source structure issue > ? JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \ > ????? $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ > ????????? $(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src))) > ? MODULESOURCEPATH := $(call PathList, $(JVMCI_MODULESOURCEPATH)) > endif > > ifeq ($(MODULE), jdk.internal.vm.compiler) > ? ## WORKAROUND jdk.internal.vm.compiler source structure issue > ? VM_COMPILER_MODULESOURCEPATH := $(MODULESOURCEPATH) \ > ????? $(subst /$(MODULE)/,/*/, $(filter-out %processor/src %test/src > %jtt/src %bench/src %microbenchmarks/src, \ > ????????? $(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src))) > ? MODULESOURCEPATH := $(call PathList, $(VM_COMPILER_MODULESOURCEPATH)) > endif > > ifeq ($(MODULE), jdk.aot) > ? ## WORKAROUND jdk.aot source structure issue > ? AOT_MODULESOURCEPATH := $(MODULESOURCEPATH) \ > ????? $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ > ????????? $(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src))) > ? MODULESOURCEPATH := $(call PathList, $(AOT_MODULESOURCEPATH)) > endif > > > Now, I'm fine with this module having a non-standard layout, but I > think it would be great if the build could paper over those > differences and yield a set of make variables that looks like that of > any other module. More importantly, the sources above are not returned > by a call to FindModuleSrcDirs, (e.g. MODULE_SRC_DIRS is not set > correctly for these) and I think they should. > > Maurizio > > > > On 27/11/17 19:14, Maurizio Cimadamore wrote: >> Hi, >> the IntelliJ support for JDK relies on make to give the set of source >> roots used for any given modules. I have noticed that the set of >> source roots associated with 'jdk.internal.vm.ci' is incorrect, as it >> points to >> >> src/jdk.internal.vm.ci/share/classes >> >> while in reality it should point to a subset of directories contained >> in such a folder (depending on the architecture). >> >> This breaks the IntelliJ project configuration if jdk.internal.vm.ci >> is selected - which is causing issues for some, see [1]. >> >> [1] - >> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-November/000590.html >> >> Maurizio >> > From philip.race at oracle.com Tue Nov 28 21:38:44 2017 From: philip.race at oracle.com (Phil Race) Date: Tue, 28 Nov 2017 13:38:44 -0800 Subject: [10] Review Request: 8189656 The Windows L&F should be moved out from the shared folder In-Reply-To: <171f8e59-8f7d-2ae4-a726-06e706297db3@oracle.com> References: <171f8e59-8f7d-2ae4-a726-06e706297db3@oracle.com> Message-ID: <582f2df2-6d44-c092-86e3-81ffdd949965@oracle.com> I see this opens was moved to platform-specific code ... 115 opens com.sun.java.swing.plaf.windows to 116 jdk.jconsole; So jdk.jconsole definitely accesses this only on Windows ? -phil. On 11/28/2017 09:28 AM, Erik Joelsson wrote: > From a build point of view, this looks great. > > /Erik > > > On 2017-11-27 18:27, Sergey Bylokhov wrote: >> Hello. >> Please review the fix for jdk10. This is the second attempt to move >> windows L&F from non-windows platforms. The first attempt >> JDK-6461834[1] was reverted because of JDK-8184813[2]. >> The root cause of those issue was fixed in JDK-8075255[3], and now we >> can move it again. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8189656 >> Webrev can be found at: >> http://cr.openjdk.java.net/~serb/8189656/webrev.02 >> >> The fix contains a few parts: >> - The code related to win l&f was moved from the "share" to the >> "windows" folder >> - The platform-specific export was moved from module-info.java to >> module-info.java.extra >> - A number of tests which use windows L&F were marked as >> windows-specific >> - The stub "ThemeReader.java" which was used to build win w&f on >> unix was removed. >> >> [1] https://bugs.openjdk.java.net/browse/JDK-6461834 >> [2] https://bugs.openjdk.java.net/browse/JDK-8184813 >> [3] https://bugs.openjdk.java.net/browse/JDK-8075255 >> > From martinrb at google.com Tue Nov 28 22:03:01 2017 From: martinrb at google.com (Martin Buchholz) Date: Tue, 28 Nov 2017 14:03:01 -0800 Subject: RFR: JDK-8191933 Use failure handler in run-test In-Reply-To: References: Message-ID: Every jtreg run would like to have the most helpful failure handling possible. Should some/all of this be pushed into jtreg itself instead of the makefiles? On Mon, Nov 27, 2017 at 1:39 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > The jtreg failure handler needs to be used when running tests using the > run-test framework. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191933 > WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191933-use-failure-han > dler-in-run-test/webrev.01 > > /Magnus > > From Sergey.Bylokhov at oracle.com Tue Nov 28 22:11:38 2017 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 28 Nov 2017 14:11:38 -0800 Subject: [10] Review Request: 8189656 The Windows L&F should be moved out from the shared folder In-Reply-To: <582f2df2-6d44-c092-86e3-81ffdd949965@oracle.com> References: <171f8e59-8f7d-2ae4-a726-06e706297db3@oracle.com> <582f2df2-6d44-c092-86e3-81ffdd949965@oracle.com> Message-ID: On 28/11/2017 13:38, Phil Race wrote: > I see this opens was moved to platform-specific code ... 115 opens > com.sun.java.swing.plaf.windows to > 116 jdk.jconsole; > > So jdk.jconsole definitely accesses this only on Windows ? Its is accessed under the windows check: http://hg.openjdk.java.net/jdk/client/file/ecaa3569ec3d/src/jdk.jconsole/share/classes/sun/tools/jconsole/MaximizableInternalFrame.java#l223 String lafName = UIManager.getLookAndFeel().getClass().getName(); IS_WIN = lafName.equals("com.sun.java.swing.plaf.windows.WindowsLookAndFeel"); > > -phil. > > On 11/28/2017 09:28 AM, Erik Joelsson wrote: >> From a build point of view, this looks great. >> >> /Erik >> >> >> On 2017-11-27 18:27, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk10. This is the second attempt to move >>> windows L&F from non-windows platforms. The first attempt >>> JDK-6461834[1] was reverted because of JDK-8184813[2]. >>> The root cause of those issue was fixed in JDK-8075255[3], and now we >>> can move it again. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189656 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8189656/webrev.02 >>> >>> The fix contains a few parts: >>> ?- The code related to win l&f was moved from the "share" to the >>> "windows" folder >>> ?- The platform-specific export was moved from module-info.java to >>> module-info.java.extra >>> ?- A number of tests which use windows L&F were marked as >>> windows-specific >>> ?- The stub "ThemeReader.java" which was used to build win w&f on >>> unix was removed. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-6461834 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8184813 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8075255 >>> >> > -- Best regards, Sergey. From mandy.chung at oracle.com Tue Nov 28 22:33:36 2017 From: mandy.chung at oracle.com (mandy chung) Date: Tue, 28 Nov 2017 14:33:36 -0800 Subject: [10] Review Request: 8189656 The Windows L&F should be moved out from the shared folder In-Reply-To: <582f2df2-6d44-c092-86e3-81ffdd949965@oracle.com> References: <171f8e59-8f7d-2ae4-a726-06e706297db3@oracle.com> <582f2df2-6d44-c092-86e3-81ffdd949965@oracle.com> Message-ID: jconsole checks if it uses windows LAF ( com.sun.java.swing.plaf.windows.WindowsLookAndFeel class.? And also reflectively access the fields in com.sun.java.swing.plaf.windows.TMSchema$Part to workaround some issue. Mandy On 11/28/17 1:38 PM, Phil Race wrote: > I see this opens was moved to platform-specific code ... 115 opens > com.sun.java.swing.plaf.windows to > 116 jdk.jconsole; > > So jdk.jconsole definitely accesses this only on Windows ? > > -phil. > > On 11/28/2017 09:28 AM, Erik Joelsson wrote: >> From a build point of view, this looks great. >> >> /Erik >> >> >> On 2017-11-27 18:27, Sergey Bylokhov wrote: >>> Hello. >>> Please review the fix for jdk10. This is the second attempt to move >>> windows L&F from non-windows platforms. The first attempt >>> JDK-6461834[1] was reverted because of JDK-8184813[2]. >>> The root cause of those issue was fixed in JDK-8075255[3], and now >>> we can move it again. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8189656 >>> Webrev can be found at: >>> http://cr.openjdk.java.net/~serb/8189656/webrev.02 >>> >>> The fix contains a few parts: >>> ?- The code related to win l&f was moved from the "share" to the >>> "windows" folder >>> ?- The platform-specific export was moved from module-info.java to >>> module-info.java.extra >>> ?- A number of tests which use windows L&F were marked as >>> windows-specific >>> ?- The stub "ThemeReader.java" which was used to build win w&f on >>> unix was removed. >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-6461834 >>> [2] https://bugs.openjdk.java.net/browse/JDK-8184813 >>> [3] https://bugs.openjdk.java.net/browse/JDK-8075255 >>> >> > From david.holmes at oracle.com Wed Nov 29 07:22:54 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 17:22:54 +1000 Subject: RFR: 8191768 - Introduce a concurrency factor to be able to scale up or down jtreg concurrency when running Hotspot tests In-Reply-To: <4116B07E-105C-4C7C-96DD-22D077F35283@oracle.com> References: <4116B07E-105C-4C7C-96DD-22D077F35283@oracle.com> Message-ID: <8106c7f8-5790-0cf5-7fe6-af23aa860ef3@oracle.com> Catching up after mini-vacation ... On 23/11/2017 2:47 AM, Christian Tornqvist wrote: > Please review this small change that allows a user to scale up or down the concurrency for running Hotspot jtreg tests using CONCURRENCY_FACTOR. > > Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8191768/webrev.00/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8191768 So setting CONCURRENCY_FACTOR = 0 will ensure no concurrent tests will run? Are we guaranteed that the higher-level testing framework will only run one jtreg test job per system at a time? Thanks, David > Thanks, > Christian > From mete.balci at antelabs.com Wed Nov 29 10:46:58 2017 From: mete.balci at antelabs.com (Mete Balci) Date: Wed, 29 Nov 2017 11:46:58 +0100 Subject: problem building client variant in 9.0.1+11 In-Reply-To: <54a69350-56dc-4c18-1d15-34a38255c976@oracle.com> References: <54a69350-56dc-4c18-1d15-34a38255c976@oracle.com> Message-ID: Hi David, Thanks, I understand. I wanted to see how a c1 only JVM behaves / reports the default values of the flags, I am not going to run any app on this. Is there a plan or discussion to remove it like shark in the (near) future or is it still used/supported for non-x86 and/or 32-bit architectures ? Mete On Tue, Nov 28, 2017 at 7:35 AM, David Holmes wrote: > Hi Mete, > > A 64-bit client build, stand-alone, is not supported. There could be more > issues than just getting the build to not fail. > > David > > On 23/11/2017 11:32 PM, Mete Balci wrote: > >> Hi, >> >> I am trying to build the client variant, but it fails with the output >> below. Is this a known issue or is there any specific configure option I >> should use ? >> >> Thanks, >> >> Mete >> >> Compiling 4 files for BUILD_JIGSAW_TOOLS >> Error: missing `server' JVM at >> `/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release >> /jdk/lib/server/libjvm.so'. >> Please install or use the JRE or JDK that contains these missing >> components. >> ExplodedImageOptimize.gmk:40: recipe for target >> '/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release >> /jdk/_packages_attribute.done' >> failed >> make[3]: *** >> [/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release >> /jdk/_packages_attribute.done] >> Error 4 >> make/Main.gmk:356: recipe for target 'exploded-image-optimize' failed >> make[2]: *** [exploded-image-optimize] Error 1 >> >> -- This message contains confidential and proprietary information of the sender, and is intended only for the person(s) to whom it is addressed. Any use, distribution, copying, disclosure or taking of any action in reliance upon it by any other person is strictly prohibited. If you have received this message in error, please notify the e-mail sender immediately, and delete the original message without making a copy. The sender accepts no liability if this email harms any systems or data of the recipient or if this email is accessed by anyone other than the person(s) to whom it is addressed. antelabs GmbH (CHE-153.180.355) is registered in Zug, Switzerland and its registered office address is Grafenauweg 10, 6301 Zug, Switzerland. From david.holmes at oracle.com Wed Nov 29 11:30:43 2017 From: david.holmes at oracle.com (David Holmes) Date: Wed, 29 Nov 2017 21:30:43 +1000 Subject: problem building client variant in 9.0.1+11 In-Reply-To: References: <54a69350-56dc-4c18-1d15-34a38255c976@oracle.com> Message-ID: <3254deb1-9df5-ef8e-fdd8-2c6ae77d6703@oracle.com> On 29/11/2017 8:46 PM, Mete Balci wrote: > Hi David, > > Thanks, I understand. I wanted to see how a c1 only JVM behaves / > reports the default values of the flags, I am not going to run any app > on this. Is there a plan or discussion to remove it like shark in the > (near) future or is it still used/supported for non-x86 and/or 32-bit > architectures ? It's still available for 32-bit architectures. David > Mete > > On Tue, Nov 28, 2017 at 7:35 AM, David Holmes > wrote: > > Hi Mete, > > A 64-bit client build, stand-alone, is not supported. There could be > more issues than just getting the build to not fail. > > David > > On 23/11/2017 11:32 PM, Mete Balci wrote: > > Hi, > > I am trying to build the client variant, but it fails with the > output > below. Is this a known issue or is there any specific configure > option I > should use ? > > Thanks, > > Mete > > Compiling 4 files for BUILD_JIGSAW_TOOLS > Error: missing `server' JVM at > `/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/lib/server/libjvm.so'. > Please install or use the JRE or JDK that contains these missing > components. > ExplodedImageOptimize.gmk:40: recipe for target > '/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done' > failed > make[3]: *** > [/home/ubuntu/jdk9u/build/linux-x86_64-normal-client-release/jdk/_packages_attribute.done] > Error 4 > make/Main.gmk:356: recipe for target 'exploded-image-optimize' > failed > make[2]: *** [exploded-image-optimize] Error 1 > > > > This message contains confidential and proprietary information of the > sender, and is intended only for the person(s) to whom it is addressed. > Any use, distribution, copying, disclosure or taking of any action in > reliance upon it by any other person is strictly prohibited. If you have > received this message in error, please notify the e-mail sender > immediately, and delete the original message without making a copy. The > sender?accepts no liability if this email harms any systems or data of > the recipient or if this email is accessed by anyone other than the > person(s) to whom it is addressed. > > antelabs GmbH (CHE-153.180.355) is registered in Zug, Switzerland and > its registered office address is Grafenauweg 10, 6301 Zug, Switzerland. From magnus.ihse.bursie at oracle.com Wed Nov 29 12:13:21 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 29 Nov 2017 13:13:21 +0100 Subject: RFR: JDK-8192067 Add fixpath to test image Message-ID: To be able to support the use case of running tests using the normal make files from prebuilt product and test images, we need to bundle the fixpath binary with the test image on Windows. Bug: https://bugs.openjdk.java.net/browse/JDK-8192067 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8192067-add-fixpath-to-test-image/webrev.01 /Magnus From maurizio.cimadamore at oracle.com Wed Nov 29 13:04:03 2017 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 29 Nov 2017 13:04:03 +0000 Subject: on jdk.internal.vm.ci In-Reply-To: References: <54e79340-8117-0d96-cfff-f3fdff08642b@oracle.com> Message-ID: Done https://bugs.openjdk.java.net/browse/JDK-8192158 Cheers Maurizio On 28/11/17 17:30, Erik Joelsson wrote: > These modules are certainly an annoyance in the build. Please file a > bug with this concern. > > /Erik > > > On 2017-11-28 03:16, Maurizio Cimadamore wrote: >> Some more specifics - these lines in the makefiles >> (CompileJavaModules.gmk) are used to workaround the layout oddities: >> >> ifeq ($(MODULE), jdk.internal.vm.ci) >> ? ## WORKAROUND jdk.internal.vm.ci source structure issue >> ? JVMCI_MODULESOURCEPATH := $(MODULESOURCEPATH) \ >> ????? $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ >> ????????? $(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src))) >> ? MODULESOURCEPATH := $(call PathList, $(JVMCI_MODULESOURCEPATH)) >> endif >> >> ifeq ($(MODULE), jdk.internal.vm.compiler) >> ? ## WORKAROUND jdk.internal.vm.compiler source structure issue >> ? VM_COMPILER_MODULESOURCEPATH := $(MODULESOURCEPATH) \ >> ????? $(subst /$(MODULE)/,/*/, $(filter-out %processor/src %test/src >> %jtt/src %bench/src %microbenchmarks/src, \ >> ????????? $(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src))) >> ? MODULESOURCEPATH := $(call PathList, $(VM_COMPILER_MODULESOURCEPATH)) >> endif >> >> ifeq ($(MODULE), jdk.aot) >> ? ## WORKAROUND jdk.aot source structure issue >> ? AOT_MODULESOURCEPATH := $(MODULESOURCEPATH) \ >> ????? $(subst /$(MODULE)/,/*/, $(filter-out %processor/src, \ >> ????????? $(wildcard $(TOPDIR)/src/$(MODULE)/share/classes/*/src))) >> ? MODULESOURCEPATH := $(call PathList, $(AOT_MODULESOURCEPATH)) >> endif >> >> >> Now, I'm fine with this module having a non-standard layout, but I >> think it would be great if the build could paper over those >> differences and yield a set of make variables that looks like that of >> any other module. More importantly, the sources above are not >> returned by a call to FindModuleSrcDirs, (e.g. MODULE_SRC_DIRS is not >> set correctly for these) and I think they should. >> >> Maurizio >> >> >> >> On 27/11/17 19:14, Maurizio Cimadamore wrote: >>> Hi, >>> the IntelliJ support for JDK relies on make to give the set of >>> source roots used for any given modules. I have noticed that the set >>> of source roots associated with 'jdk.internal.vm.ci' is incorrect, >>> as it points to >>> >>> src/jdk.internal.vm.ci/share/classes >>> >>> while in reality it should point to a subset of directories >>> contained in such a folder (depending on the architecture). >>> >>> This breaks the IntelliJ project configuration if jdk.internal.vm.ci >>> is selected - which is causing issues for some, see [1]. >>> >>> [1] - >>> http://mail.openjdk.java.net/pipermail/jdk10-dev/2017-November/000590.html >>> >>> Maurizio >>> >> > From tim.bell at oracle.com Wed Nov 29 15:54:03 2017 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 29 Nov 2017 07:54:03 -0800 Subject: RFR: JDK-8192067 Add fixpath to test image In-Reply-To: References: Message-ID: <5A1ED81B.2070804@oracle.com> Magnus: > To be able to support the use case of running tests using the normal > make files from prebuilt product and test images, we need to bundle the > fixpath binary with the test image on Windows. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192067 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8192067-add-fixpath-to-test-image/webrev.01 Looks good. Tim From erik.joelsson at oracle.com Wed Nov 29 17:47:31 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 Nov 2017 09:47:31 -0800 Subject: RFR: 8191768 - Introduce a concurrency factor to be able to scale up or down jtreg concurrency when running Hotspot tests In-Reply-To: <8106c7f8-5790-0cf5-7fe6-af23aa860ef3@oracle.com> References: <4116B07E-105C-4C7C-96DD-22D077F35283@oracle.com> <8106c7f8-5790-0cf5-7fe6-af23aa860ef3@oracle.com> Message-ID: <6a4e7cc2-74ae-9200-7ded-c120588420b7@oracle.com> On 2017-11-28 23:22, David Holmes wrote: > Catching up after mini-vacation ... > > On 23/11/2017 2:47 AM, Christian Tornqvist wrote: >> Please review this small change that allows a user to scale up or >> down the concurrency for running Hotspot jtreg tests using >> CONCURRENCY_FACTOR. >> >> Webrev: >> http://cr.openjdk.java.net/~ctornqvi/webrev/8191768/webrev.00/ >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191768 >> > > So setting CONCURRENCY_FACTOR = 0 will ensure no concurrent tests will > run? > > Are we guaranteed that the higher-level testing framework will only > run one jtreg test job per system at a time? AFAIK yes. We only run one agent per system, and each agent only runs one task at a time. (VMs on a physical host are usually over-allocated on CPUs though so we cannot guarantee available CPU resources to each VM) /Erik > > Thanks, > David > >> Thanks, >> Christian >> From erik.joelsson at oracle.com Wed Nov 29 17:51:04 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 Nov 2017 09:51:04 -0800 Subject: RFR: JDK-8192067 Add fixpath to test image In-Reply-To: References: Message-ID: <7b7aeafa-3923-de42-9c92-2275803eed7e@oracle.com> Looks good. (I would have done it with SetupCopyFiles, but this small rule declaration is OK too) /Erik On 2017-11-29 04:13, Magnus Ihse Bursie wrote: > To be able to support the use case of running tests using the normal > make files from prebuilt product and test images, we need to bundle > the fixpath binary with the test image on Windows. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192067 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8192067-add-fixpath-to-test-image/webrev.01 > > /Magnus From christian.tornqvist at oracle.com Wed Nov 29 18:24:36 2017 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 29 Nov 2017 13:24:36 -0500 Subject: RFR: 8191768 - Introduce a concurrency factor to be able to scale up or down jtreg concurrency when running Hotspot tests In-Reply-To: <8106c7f8-5790-0cf5-7fe6-af23aa860ef3@oracle.com> References: <4116B07E-105C-4C7C-96DD-22D077F35283@oracle.com> <8106c7f8-5790-0cf5-7fe6-af23aa860ef3@oracle.com> Message-ID: <4DA4D7A8-1DA6-4A92-A22F-64309697C20D@oracle.com> > On Nov 29, 2017, at 2:22 AM, David Holmes wrote: > > Catching up after mini-vacation ... > > On 23/11/2017 2:47 AM, Christian Tornqvist wrote: >> Please review this small change that allows a user to scale up or down the concurrency for running Hotspot jtreg tests using CONCURRENCY_FACTOR. >> Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8191768/webrev.00/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191768 > > So setting CONCURRENCY_FACTOR = 0 will ensure no concurrent tests will run? It would, but you should probably just set CONCURRENCY=1 instead > > Are we guaranteed that the higher-level testing framework will only run one jtreg test job per system at a time? > > Thanks, > David > >> Thanks, >> Christian From magnus.ihse.bursie at oracle.com Wed Nov 29 20:21:38 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 29 Nov 2017 21:21:38 +0100 Subject: RFR: JDK-8191933 Use failure handler in run-test In-Reply-To: References: Message-ID: On 2017-11-28 23:03, Martin Buchholz wrote: > Every jtreg run would like to have the most helpful failure handling > possible.? Should some/all of this be pushed into jtreg itself instead > of the makefiles? As I understand things, jtreg has a kind of plugin structure. This is a separate, specific plugin that leverages this functionality, and does some kind of JVM-specific analysis in case of failure. I don't think that would fit properly inside jtreg itself. /Magnus > > On Mon, Nov 27, 2017 at 1:39 PM, Magnus Ihse Bursie > > > wrote: > > The jtreg failure handler needs to be used when running tests > using the run-test framework. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191933 > > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191933-use-failure-handler-in-run-test/webrev.01 > > > /Magnus > > From magnus.ihse.bursie at oracle.com Wed Nov 29 20:22:57 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 29 Nov 2017 21:22:57 +0100 Subject: RFR: JDK-8192067 Add fixpath to test image In-Reply-To: <7b7aeafa-3923-de42-9c92-2275803eed7e@oracle.com> References: <7b7aeafa-3923-de42-9c92-2275803eed7e@oracle.com> Message-ID: <7193ea5c-da0f-4437-7e7b-c11dd4738189@oracle.com> On 2017-11-29 18:51, Erik Joelsson wrote: > Looks good. (I would have done it with SetupCopyFiles, but this small > rule declaration is OK too) Good point. I have to admit I didn't even think that far. If I ever need to touch the file again, I'll rewrite it using SetupCopyFiles. /Magnus > > /Erik > > > On 2017-11-29 04:13, Magnus Ihse Bursie wrote: >> To be able to support the use case of running tests using the normal >> make files from prebuilt product and test images, we need to bundle >> the fixpath binary with the test image on Windows. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8192067 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8192067-add-fixpath-to-test-image/webrev.01 >> >> /Magnus > From erik.joelsson at oracle.com Wed Nov 29 20:37:48 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 Nov 2017 12:37:48 -0800 Subject: RFR: JDK-8191933 Use failure handler in run-test In-Reply-To: References: Message-ID: <2ea6efc4-8e3f-e330-465d-bdebe503fb4a@oracle.com> Looks good. /Erik On 2017-11-27 13:39, Magnus Ihse Bursie wrote: > The jtreg failure handler needs to be used when running tests using > the run-test framework. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8191933 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8191933-use-failure-handler-in-run-test/webrev.01 > > /Magnus > From martinrb at google.com Wed Nov 29 21:08:31 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 29 Nov 2017 13:08:31 -0800 Subject: RFR: JDK-8191933 Use failure handler in run-test In-Reply-To: References: Message-ID: I took a quick peek at your failure handler. There's lots of necessarily non-portable stuff here, like invoking lsof, but I see much that is OS-dependent rather than VM-dependent, so I would still like to see some of it becoming (an optional) part of jtreg (which itself also comes with TimeoutHandlers). I've looked for TimeoutHandlers before, but only in the jtreg sources, not the openjdk sources. But my musing is not a comment on this CL; more a suggestion for jtreg-dev. On Wed, Nov 29, 2017 at 12:21 PM, Magnus Ihse Bursie < magnus.ihse.bursie at oracle.com> wrote: > > On 2017-11-28 23:03, Martin Buchholz wrote: > > Every jtreg run would like to have the most helpful failure handling > possible. Should some/all of this be pushed into jtreg itself instead of > the makefiles? > > As I understand things, jtreg has a kind of plugin structure. This is a > separate, specific plugin that leverages this functionality, and does some > kind of JVM-specific analysis in case of failure. I don't think that would > fit properly inside jtreg itself. > > /Magnus > > > On Mon, Nov 27, 2017 at 1:39 PM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> The jtreg failure handler needs to be used when running tests using the >> run-test framework. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191933 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191933-use-failure-han >> dler-in-run-test/webrev.01 >> >> /Magnus >> >> > > From jonathan.gibbons at oracle.com Wed Nov 29 21:08:29 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 29 Nov 2017 13:08:29 -0800 Subject: RFR: JDK-8191933 Use failure handler in run-test In-Reply-To: References: Message-ID: <5A1F21CD.1030803@oracle.com> One reason it is difficult to move some of this into jtreg itself is because some of these handlers use recent/new APIs. That makes writing and/or building jtreg that much harder. But I agree in general with the overall goal of moving stuff into jtreg when it is practical to do so. -- Jon On 11/28/2017 02:03 PM, Martin Buchholz wrote: > Every jtreg run would like to have the most helpful failure handling > possible. Should some/all of this be pushed into jtreg itself instead of > the makefiles? > > On Mon, Nov 27, 2017 at 1:39 PM, Magnus Ihse Bursie < > magnus.ihse.bursie at oracle.com> wrote: > >> The jtreg failure handler needs to be used when running tests using the >> run-test framework. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8191933 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191933-use-failure-han >> dler-in-run-test/webrev.01 >> >> /Magnus >> >> From erik.joelsson at oracle.com Wed Nov 29 22:48:37 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 29 Nov 2017 14:48:37 -0800 Subject: RFR: JDK-8139653: Freetype bundled on macosx, but not correctly linked Message-ID: <019e6d51-b4d9-114d-5f07-35f22ea96336@oracle.com> When building macosx openjdk and enabling bundling of freetype (which is usually not the default), the makefiles will copy the library in, but libfontmanager will not be able to link to it at runtime. This is caused by a peculiarity on macosx where a library that is being linked to specifies the rpath to use in any library that links to it. At Oracle we currently link to the libfreetype in x11 from Quartz, which is located in /opt/X11/lib/libfreetype.6.dylib, so the libfontmanager we build will only look in that location at runtime. This patch adds a new build step, using the install_name_tool which can rewrite this rpath to where you actually have a dependency on your system. In this case right next to libfontmanager in the same directory. I also changed the import logic that copies in libfreetype so that it doesn't a .6 at the end on macosx. This patch does not change the defaults for bundling of freetype, nor does it change how Oracle bundles freetype. That may come later. Bug: https://bugs.openjdk.java.net/browse/JDK-8139653 Webrev: http://cr.openjdk.java.net/~erikj/8139653/webrev.01/ /Erik From martinrb at google.com Wed Nov 29 23:03:46 2017 From: martinrb at google.com (Martin Buchholz) Date: Wed, 29 Nov 2017 15:03:46 -0800 Subject: RFR: JDK-8191933 Use failure handler in run-test In-Reply-To: <5A1F21CD.1030803@oracle.com> References: <5A1F21CD.1030803@oracle.com> Message-ID: jtreg is already hard to build. I see my own build script defining JDK17HOME JDK18HOME JDK19HOME. Optionally using features when a jdk is sufficiently up to date is annoyingly difficult, but that's what java programmers everywhere do, typically using reflection. On Wed, Nov 29, 2017 at 1:08 PM, Jonathan Gibbons < jonathan.gibbons at oracle.com> wrote: > One reason it is difficult to move some of this into jtreg itself is > because some > of these handlers use recent/new APIs. That makes writing and/or building > jtreg > that much harder. But I agree in general with the overall goal of moving > stuff > into jtreg when it is practical to do so. > > -- Jon > > > On 11/28/2017 02:03 PM, Martin Buchholz wrote: > >> Every jtreg run would like to have the most helpful failure handling >> possible. Should some/all of this be pushed into jtreg itself instead of >> the makefiles? >> >> On Mon, Nov 27, 2017 at 1:39 PM, Magnus Ihse Bursie < >> magnus.ihse.bursie at oracle.com> wrote: >> >> The jtreg failure handler needs to be used when running tests using the >>> run-test framework. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8191933 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8191933-use-failure-han >>> dler-in-run-test/webrev.01 >>> >>> /Magnus >>> >>> >>> > From magnus.ihse.bursie at oracle.com Thu Nov 30 14:09:38 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 30 Nov 2017 15:09:38 +0100 Subject: RFR: JDK-8192816 Let run-test save exit code Message-ID: <4dcc4736-a3f9-7b8d-9bc9-d6cb3d933ba4@oracle.com> To support all the use cases of the old test/Makefile way of running tests, we need to save the exit code from running tests. This patch also includes three other bug fixes: * Saving the test ID:s of the latest run in test-last-ids.txt, so we can programmatically discover which new tests were run. * Test roots were not normalized for jtreg tests given only by group (e.g. ":tier1") * Fix for solaris version of tr. The last one was actually quite interesting, and took a while to figure out. On well-behaving unix systems, tr -c '[a-z]' '_' would take the complement of a-z and replace it by underscore. But on solaris, -c [a-z] would evaluate to a (not clearly defined) massive string of all characters except a-z in the current locale. And then, if the second string ('_') is *shorter* than the first, the behavior of tr is *undefinied* (which, in practice, means that it doesn't do anything). Like, "wtf?!? how could this possibly work for anyone?". The workaround, after much hair-pulling, turned out to be a notation to repeat a single character ('[_*1000]'), hoping that the character set never exceeds 1000. *sigh* Bug: https://bugs.openjdk.java.net/browse/JDK-8192816 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8192816-let-run-test-save-exit-code/webrev.01 /Magnus From erik.joelsson at oracle.com Thu Nov 30 17:20:22 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 Nov 2017 09:20:22 -0800 Subject: RFR: JDK-8192816 Let run-test save exit code In-Reply-To: <4dcc4736-a3f9-7b8d-9bc9-d6cb3d933ba4@oracle.com> References: <4dcc4736-a3f9-7b8d-9bc9-d6cb3d933ba4@oracle.com> Message-ID: <7e77422e-b488-41fe-1bd7-aacb6a3bd9e0@oracle.com> Looks good. / On 2017-11-30 06:09, Magnus Ihse Bursie wrote: > To support all the use cases of the old test/Makefile way of running > tests, we need to save the exit code from running tests. > > This patch also includes three other bug fixes: > * Saving the test ID:s of the latest run in test-last-ids.txt, so we > can programmatically discover which new tests were run. > * Test roots were not normalized for jtreg tests given only by group > (e.g. ":tier1") > * Fix for solaris version of tr. > > The last one was actually quite interesting, and took a while to > figure out. On well-behaving unix systems, tr -c '[a-z]' '_' would > take the complement of a-z and replace it by underscore. But on > solaris, -c [a-z] would evaluate to a (not clearly defined) massive > string of all characters except a-z in the current locale. And then, > if the second string ('_') is *shorter* than the first, the behavior > of tr is *undefinied* (which, in practice, means that it doesn't do > anything). Like, "wtf?!? how could this possibly work for anyone?". > The workaround, after much hair-pulling, turned out to be a notation > to repeat a single character ('[_*1000]'), hoping that the character > set never exceeds 1000. *sigh* > > Bug: https://bugs.openjdk.java.net/browse/JDK-8192816 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8192816-let-run-test-save-exit-code/webrev.01 > > /Magnus > From vladimir.x.ivanov at oracle.com Thu Nov 30 18:35:44 2017 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Thu, 30 Nov 2017 21:35:44 +0300 Subject: How to disable JVM features? Message-ID: <5e134e87-aa8f-325a-4b79-900b1dae2afb@oracle.com> Hi, I'm curious is there a way to disable JVM features from the default list. Configure mentions --with-jvm-features [1], but it doesn't allow to remove features which are enabled by default (tried to override the list, but it didn't work). Thanks! Best regards, Vladimir Ivanov [1] --with-jvm-features additional JVM features to enable (separated by comma), use '--help' to show possible values [none] ... The following JVM features are available as arguments to --with-jvm-features. Which are valid to use depends on the target platform. compiler1 compiler2 zero minimal dtrace jvmti jvmci graal vm-structs jni-check services management all-gcs nmt cds static-build link-time-opt aot closed-src commercial-features trace From tim.bell at oracle.com Thu Nov 30 19:12:40 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 30 Nov 2017 11:12:40 -0800 Subject: RFR: JDK-8139653: Freetype bundled on macosx, but not correctly linked In-Reply-To: <019e6d51-b4d9-114d-5f07-35f22ea96336@oracle.com> References: <019e6d51-b4d9-114d-5f07-35f22ea96336@oracle.com> Message-ID: <5A205828.6070601@oracle.com> Erik: > When building macosx openjdk and enabling bundling of freetype (which is > usually not the default), the makefiles will copy the library in, but > libfontmanager will not be able to link to it at runtime. This is caused > by a peculiarity on macosx where a library that is being linked to > specifies the rpath to use in any library that links to it. At Oracle we > currently link to the libfreetype in x11 from Quartz, which is located > in /opt/X11/lib/libfreetype.6.dylib, so the libfontmanager we build will > only look in that location at runtime. > > This patch adds a new build step, using the install_name_tool which can > rewrite this rpath to where you actually have a dependency on your > system. In this case right next to libfontmanager in the same directory. > I also changed the import logic that copies in libfreetype so that it > doesn't a .6 at the end on macosx. > > This patch does not change the defaults for bundling of freetype, nor > does it change how Oracle bundles freetype. That may come later. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139653 > > Webrev: http://cr.openjdk.java.net/~erikj/8139653/webrev.01/ Looks good to me. Tim From philip.race at oracle.com Thu Nov 30 20:39:53 2017 From: philip.race at oracle.com (Philip Race) Date: Thu, 30 Nov 2017 12:39:53 -0800 Subject: RFR: JDK-8139653: Freetype bundled on macosx, but not correctly linked In-Reply-To: <019e6d51-b4d9-114d-5f07-35f22ea96336@oracle.com> References: <019e6d51-b4d9-114d-5f07-35f22ea96336@oracle.com> Message-ID: <5A206C99.7000302@oracle.com> Looks good .. and worked for me when I tested with --enable-freetype-bundling. I used otool to verify the rpath used by fontmanager and used vmmap to verify an executing process was picking up freetype from the JDK's lib. So when we do bundle freetype then it should work as expected. -phil. On 11/29/17, 2:48 PM, Erik Joelsson wrote: > When building macosx openjdk and enabling bundling of freetype (which > is usually not the default), the makefiles will copy the library in, > but libfontmanager will not be able to link to it at runtime. This is > caused by a peculiarity on macosx where a library that is being linked > to specifies the rpath to use in any library that links to it. At > Oracle we currently link to the libfreetype in x11 from Quartz, which > is located in /opt/X11/lib/libfreetype.6.dylib, so the libfontmanager > we build will only look in that location at runtime. > > This patch adds a new build step, using the install_name_tool which > can rewrite this rpath to where you actually have a dependency on your > system. In this case right next to libfontmanager in the same > directory. I also changed the import logic that copies in libfreetype > so that it doesn't a .6 at the end on macosx. > > This patch does not change the defaults for bundling of freetype, nor > does it change how Oracle bundles freetype. That may come later. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139653 > > Webrev: http://cr.openjdk.java.net/~erikj/8139653/webrev.01/ > > /Erik > From tim.bell at oracle.com Thu Nov 30 21:45:54 2017 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 30 Nov 2017 13:45:54 -0800 Subject: RFR: JDK-8192816 Let run-test save exit code In-Reply-To: <7e77422e-b488-41fe-1bd7-aacb6a3bd9e0@oracle.com> References: <4dcc4736-a3f9-7b8d-9bc9-d6cb3d933ba4@oracle.com> <7e77422e-b488-41fe-1bd7-aacb6a3bd9e0@oracle.com> Message-ID: <5A207C12.3050301@oracle.com> Magnus: Looks good. > On well-behaving unix systems, tr -c '[a-z]' '_' would >>> take the complement of a-z and replace it by underscore. But on >>> solaris, -c [a-z] would evaluate to a (not clearly defined) massive >>> string of all characters except a-z in the current locale. I wish we could get away from using tr due to sometimes surprising behavior depending on locale, but that is a separate project. Tim On 11/30/17 09:20, Erik Joelsson wrote: > Looks good. > > / > > > On 2017-11-30 06:09, Magnus Ihse Bursie wrote: >> To support all the use cases of the old test/Makefile way of running >> tests, we need to save the exit code from running tests. >> >> This patch also includes three other bug fixes: >> * Saving the test ID:s of the latest run in test-last-ids.txt, so we >> can programmatically discover which new tests were run. >> * Test roots were not normalized for jtreg tests given only by group >> (e.g. ":tier1") >> * Fix for solaris version of tr. >> >> The last one was actually quite interesting, and took a while to >> figure out. On well-behaving unix systems, tr -c '[a-z]' '_' would >> take the complement of a-z and replace it by underscore. But on >> solaris, -c [a-z] would evaluate to a (not clearly defined) massive >> string of all characters except a-z in the current locale. And then, >> if the second string ('_') is *shorter* than the first, the behavior >> of tr is *undefinied* (which, in practice, means that it doesn't do >> anything). Like, "wtf?!? how could this possibly work for anyone?". >> The workaround, after much hair-pulling, turned out to be a notation >> to repeat a single character ('[_*1000]'), hoping that the character >> set never exceeds 1000. *sigh* >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8192816 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8192816-let-run-test-save-exit-code/webrev.01 >> >> >> /Magnus >> > From erik.joelsson at oracle.com Thu Nov 30 21:58:28 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 30 Nov 2017 13:58:28 -0800 Subject: RFR: JDK-8190464: OpenJDK on macosx needs to bundle freetype Message-ID: Since X11 and freetype aren't available on Macosx by default, and we (Oracle) are now shipping OpenJDK builds for Macosx, we need to start bundling freetype on Macosx, just like we do on Windows. This patch adds a new freetype bundle as a dependency for Macosx builds. It also updates the dependencies for Windows builds to get a new license file. Previously we only included the license file in RI builds (openjdk only builds with BCL source license) but we have now decided to include it with GPL licensed builds as well. The patch removes the special handling of the license for RI builds. It also makes configure look for the license file in the root of the --with-freetype argument so that Jib only has to provide the one argument. Finally, the --with-freetype-license logic was outside of the "needs freetype" block so I moved inside that block. Bug: https://bugs.openjdk.java.net/browse/JDK-8190464 Webrev: http://cr.openjdk.java.net/~erikj/8190464/webrev.01/ /Erik From magnus.ihse.bursie at oracle.com Thu Nov 30 22:47:34 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 30 Nov 2017 23:47:34 +0100 Subject: RFR: JDK-8190464: OpenJDK on macosx needs to bundle freetype In-Reply-To: References: Message-ID: <97E7957E-F7C6-44B7-9505-E273AABCC3AE@oracle.com> Looks good to me. /Magnus > 30 nov. 2017 kl. 22:58 skrev Erik Joelsson : > > Since X11 and freetype aren't available on Macosx by default, and we (Oracle) are now shipping OpenJDK builds for Macosx, we need to start bundling freetype on Macosx, just like we do on Windows. This patch adds a new freetype bundle as a dependency for Macosx builds. It also updates the dependencies for Windows builds to get a new license file. > > Previously we only included the license file in RI builds (openjdk only builds with BCL source license) but we have now decided to include it with GPL licensed builds as well. The patch removes the special handling of the license for RI builds. It also makes configure look for the license file in the root of the --with-freetype argument so that Jib only has to provide the one argument. Finally, the --with-freetype-license logic was outside of the "needs freetype" block so I moved inside that block. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8190464 > > Webrev: http://cr.openjdk.java.net/~erikj/8190464/webrev.01/ > > /Erik > From magnus.ihse.bursie at oracle.com Thu Nov 30 22:50:55 2017 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 30 Nov 2017 23:50:55 +0100 Subject: RFR: JDK-8139653: Freetype bundled on macosx, but not correctly linked In-Reply-To: <019e6d51-b4d9-114d-5f07-35f22ea96336@oracle.com> References: <019e6d51-b4d9-114d-5f07-35f22ea96336@oracle.com> Message-ID: <28CCAD0A-DA27-4FAA-AF42-670E5177DA7A@oracle.com> Looks good to me. /Magnus > 29 nov. 2017 kl. 23:48 skrev Erik Joelsson : > > When building macosx openjdk and enabling bundling of freetype (which is usually not the default), the makefiles will copy the library in, but libfontmanager will not be able to link to it at runtime. This is caused by a peculiarity on macosx where a library that is being linked to specifies the rpath to use in any library that links to it. At Oracle we currently link to the libfreetype in x11 from Quartz, which is located in /opt/X11/lib/libfreetype.6.dylib, so the libfontmanager we build will only look in that location at runtime. > > This patch adds a new build step, using the install_name_tool which can rewrite this rpath to where you actually have a dependency on your system. In this case right next to libfontmanager in the same directory. I also changed the import logic that copies in libfreetype so that it doesn't a .6 at the end on macosx. > > This patch does not change the defaults for bundling of freetype, nor does it change how Oracle bundles freetype. That may come later. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8139653 > > Webrev: http://cr.openjdk.java.net/~erikj/8139653/webrev.01/ > > /Erik >