From magnus.ihse.bursie at oracle.com Mon Jun 1 09:55:40 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 01 Jun 2015 11:55:40 +0200 Subject: RFR(S): 8081037: serviceability/sa/ tests time out on Windows In-Reply-To: <556729F0.70703@oracle.com> References: <5565C048.4050801@oracle.com> <556729F0.70703@oracle.com> Message-ID: <556C2C1C.50900@oracle.com> On 2015-05-28 16:45, Yekaterina Kantserova wrote: > Hi, > > due to https://bugs.openjdk.java.net/browse/JDK-8081381 I wasn't able > to push this fix. The problem is LingeredApp.java contains JDK 9 > feature java.lang.Process.getPid() but the test library is compiled > with JDK 8 today. This issue is not trivial to solve so I suggest a > temporary fix to test/lib/Makefile. > > webrev root: http://cr.openjdk.java.net/~ykantser/8081037/webrev.01 The temporary fix looks good from a build perspective, I guess, as long as you're satisfied with the lib including just the files in hprof. It looks like https://bugs.openjdk.java.net/browse/JDK-8081381 is in the intersection between hotspot testing and the build infrastructure. Please keep us in the loop when discussion solutions to that. /Magnus > > Thanks, > Katja > > > > On 05/27/2015 03:02 PM, Yekaterina Kantserova wrote: >> Hi, >> >> Could I please have a review of this fix. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8081037 >> webrev root: http://cr.openjdk.java.net/~ykantser/8081037/webrev.00 >> webrev jdk: http://cr.openjdk.java.net/~ykantser/8081037.jdk/webrev.00 >> webrev hotspot: >> http://cr.openjdk.java.net/~ykantser/8081037.hotspot/webrev.00 >> >> From the bug: >> "The problem is most likely that SA will pause the target process >> while it is running. In this case, the target process is the same as >> the process that launched SA. That process is also handling the >> output from SA over a pipe, but when that pipe fills up the process >> cannot empty it and the SA process is blocked because it cannot write >> any more output. Deadlock." >> >> The solutions is to start a separate target process. Dmitry Samersoff >> has already created a test application for such cases so I've decided >> to move it on the top level library instead of duplicating it. The >> test application will reside under >> test/lib/share/classes/jdk/test/lib/apps and the test under >> test/lib-test/jdk/test/lib/apps. >> >> Thanks, >> Katja > From jan.lahoda at oracle.com Mon Jun 1 15:56:04 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 01 Jun 2015 17:56:04 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <5565B730.5030602@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> Message-ID: <556C8094.3050800@oracle.com> Hi, I made a somewhat bigger update (partially based on other feedback). Summary of changes: -the history data has been moved into langtools (I also moved the Ctsym.gmk) -there are JDK 6 data now -renamed the "-platform" option to "-release". Code/tests directly related to the option has been also changed as well. I kept the internal PlatformProvider API in javac as is, and also kept related code. -added a note that the is generated by CreateSymbols. Webrevs: top-level: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ langtools: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ Delta webrevs are also available. How does this look? Thanks for the comments so far! Jan On 27.5.2015 14:23, Jan Lahoda wrote: > Ah, yes, I did not realize that. Thanks, will fix. > > Thanks, > Jan > > On 27.5.2015 11:59, Maurizio Cimadamore wrote: >> Looks great. The only nitpick is that the comments in CreateSymbols >> don't mention the fact that a side effect of the sym.txt generation is >> the mentioned earlier in the same comments >> (so one might wonder where does that come from). >> >> Maurizio >> >> On 27/05/15 10:37, Jan Lahoda wrote: >>> Hi, >>> >>> I've uploaded another iteration, with these changes: >>> -the "symbols" file is now generated automatically (for the typical >>> OpenJDK case). >>> -fixed a minor issue in CreateSymbols that could cause putting class >>> description into wrong a file (the "break" -> "break OUTER;" change). >>> -jdk.management module has been split out from java.management >>> recently, so splitting the corresponding .sym.txt files into >>> java.management and jdk.management as well. >>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>> >>> Webrevs: >>> -top-level: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>> -langtools (no changes against the last webrev): >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>> >>> Delta webrevs against the previous iteration are included under >>> "Author comments". >>> >>> Thanks for the comments so far! >>> >>> Jan >>> >>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>> Excellent work. >>>>> >>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>> Probe >>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>> >>>>> /bin/java Probe --> classes-8 >>>>> /bin/java Probe --> classes-7 >>>>> /bin/java Probe --> classes-7 >>>>> >>>>> etc. >>>> >>>> Sure, will do. >>>> >>>> I'll also look at generating the make/data/symbols/symbols descriptions >>>> automatically, per our offline discussion. >>>> >>>> Thanks! >>>> >>>> Jan >>>> >>>>> >>>>> Maurizio >>>>> >>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I've uploaded a new iteration of the patch(es): >>>>>> top-level repository: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>> langtools: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>> >>>>>> (besides full webrevs, there are also webrevs showing the differences >>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>> "Author's comments") >>>>>> >>>>>> Summary of changes: >>>>>> -applied Eric's build changes >>>>>> -moved CreateSymbols into >>>>>> make/src/classes/build/tools/symbolgenerator >>>>>> -tried to improve the specification of base platforms in >>>>>> CreateSymbols, per Maurizio's comment >>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>> >>>>>> Thanks, >>>>>> Jan >>>>>> >>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>> Hi Jan, >>>>>>> great work - couple of comments below: >>>>>>> >>>>>>> * it seems like some of the routines in Arguments can be simplified >>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>> checkOptionAllowed >>>>>>> * Why JDKPlatformProvider is not called >>>>>>> JDKPlatformProvider*Factory* ? >>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>> commonalities >>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>> this a >>>>>>> bit? >>>>>>> * What's the rationale for giving an error if -platform is specified >>>>>>> and >>>>>>> a non-StandardFileManager is provided? Can't we simply swallow that, >>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>> * Would it make sense for some of the classfile generation logic in >>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>> * I had hard time reconciling some of the comments in CreateSymbols >>>>>>> with >>>>>>> how the files were laid out. I think in the end, what you mean is >>>>>>> that >>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>> (i.e. 8) >>>>>>> and then generate diffs for 9 and 7 against the 8 one. If that's the >>>>>>> use >>>>>>> case, I think the command line can be simplified a bit in order to >>>>>>> explicitly state which of the platform is the baseline one, and the >>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>> seem to be typically all >>>>>>> identical >>>>>>> but one which is set to - the one for the baseline). Maybe >>>>>>> the >>>>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>>>> 7 and >>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>> should be >>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>> there >>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>> >>>>>>>> Patch for the top-level repository is here: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>> >>>>>>>> Patch for the langtools repository is here: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>> >>>>>>>> These changes also require additional langtools changes as their >>>>>>>> prerequisite: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>> >>>>>>>> Overall, one can imagine '-platform N' to have the same effect as >>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>> values >>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>> correspond to >>>>>>>> Open JDK 7 and 8 GA. >>>>>>>> >>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>> N. The >>>>>>>> proposal is to include history data in the textual format inside >>>>>>>> the >>>>>>>> OpenJDK repositories (the input data), process them at build time >>>>>>>> and >>>>>>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>>>>>> running with the -platform option then compiles against the >>>>>>>> lib/ct.sym >>>>>>>> file. The input history data are placed >>>>>>>> /make/data/symbols (the sym.txt files). This >>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for public >>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>> >>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>> checkout and >>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>> significantly >>>>>>>> if additional classes/elements, like non-public API classes, would >>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>> >>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>> them as >>>>>>>> classfiles), but are missing some attributes, most notably the Code >>>>>>>> attribute. On the top-level, the ct.sym contains directories named >>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>> bootclasspath >>>>>>>> for that version is obtained by using directories which have 'N' in >>>>>>>> their name. >>>>>>>> >>>>>>>> The sigfiles for ct.sym are created by >>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>> >>>>>>>> >>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>> Concise >>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>> >>>>>>>> I am sending this as one review, as the changes together make one >>>>>>>> feature, but the langtools and top-level changes are independent >>>>>>>> to a >>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>> and the >>>>>>>> top-level changes add the history data and ability to build the >>>>>>>> ct.sym >>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>> independently. >>>>>>>> >>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, Alan >>>>>>>> Bateman and others who have provided advices and help on the matter >>>>>>>> before. >>>>>>>> >>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jan >>>>>>> >>>>> >> From bertrand.delsart at oracle.com Mon Jun 1 17:23:10 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Mon, 01 Jun 2015 19:23:10 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors Message-ID: <556C94FE.9000805@oracle.com> Hi all, A small open webrev to fix some issues around --disable-warnings-as-errors (this is not a full cleanup): http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ Without the fix, -Werror is used to compiled native JDK libraries even when the --disable-warnings-as-errors is used. A lot of these libs are addressed by clearing CFLAGS_WARNINGS_ARE_ERRORS in flags.m4 Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the mechanism put in place in that file to disable -Werror and control it through the WARNINGS_AS_ERRORS configured value. Best regards, Bertrand. -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From bertrand.delsart at oracle.com Mon Jun 1 17:38:29 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Mon, 01 Jun 2015 19:38:29 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556C94FE.9000805@oracle.com> References: <556C94FE.9000805@oracle.com> Message-ID: <556C9895.30507@oracle.com> Resending the message since I was not yet a member of build-dev. Bertrand. On 01/06/2015 19:23, Bertrand Delsart wrote: > Hi all, > > A small open webrev to fix some issues around > --disable-warnings-as-errors (this is not a full cleanup): > > http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ > > Without the fix, -Werror is used to compiled native JDK libraries even > when the --disable-warnings-as-errors is used. > > A lot of these libs are addressed by clearing CFLAGS_WARNINGS_ARE_ERRORS > in flags.m4 > > Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. > Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the > mechanism put in place in that file to disable -Werror and control it > through the WARNINGS_AS_ERRORS configured value. > > Best regards, > > Bertrand. > -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From semyon.sadetsky at oracle.com Mon Jun 1 19:17:09 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 01 Jun 2015 22:17:09 +0300 Subject: Solaris jdk9 build problem Message-ID: <556CAFB5.3070407@oracle.com> Hello, Could you help me to resolve 9 build problem on Solaris 11.2: /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory gmake[8]: *** [libjvm.so] Error 1 gmake[8]: Leaving directory `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' gmake[7]: *** [the_vm] Error 2 gmake[7]: Leaving directory `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' and earlier in the log: Assembling /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s rm -f solaris_x86_64.o xarch=amd64 -o solaris_x86_64.o /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s /usr/bin/bash: -o: command not found gmake[8]: [solaris_x86_64.o] Error 127 (ignored) Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp rm -f space.o /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - ... I guess there should be cc before xarch, but it's omited. ./configure did not report any warnings. Thank you. --Semyon From david.holmes at oracle.com Mon Jun 1 23:34:02 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 09:34:02 +1000 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556C94FE.9000805@oracle.com> References: <556C94FE.9000805@oracle.com> Message-ID: <556CEBEA.3020804@oracle.com> Hi Bertrand, On 2/06/2015 3:23 AM, Bertrand Delsart wrote: > Hi all, > > A small open webrev to fix some issues around > --disable-warnings-as-errors (this is not a full cleanup): > > http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ > > Without the fix, -Werror is used to compiled native JDK libraries even > when the --disable-warnings-as-errors is used. > > A lot of these libs are addressed by clearing CFLAGS_WARNINGS_ARE_ERRORS > in flags.m4 I'd be tempted to make the whole case statement that sets CFLAGS_WARNINGS_ARE_ERRORS and DISABLE_WARNING_PREFIX conditional on WARNINGS_AS_ERRORS. But that's for the build folk to decide. But I think your change should probably be expressed as: if test "WARNINGS_AS_ERRORS" = "true"; then ... > Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. > Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the > mechanism put in place in that file to disable -Werror and control it > through the WARNINGS_AS_ERRORS configured value. Seems fine. Thanks, David > Best regards, > > Bertrand. > From magnus.ihse.bursie at oracle.com Mon Jun 1 23:35:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 01:35:06 +0200 Subject: Solaris jdk9 build problem In-Reply-To: <556CAFB5.3070407@oracle.com> References: <556CAFB5.3070407@oracle.com> Message-ID: <556CEC2A.30504@oracle.com> On 2015-06-01 21:17, Semyon Sadetsky wrote: > Hello, > > Could you help me to resolve 9 build problem on Solaris 11.2: > > /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory > gmake[8]: *** [libjvm.so] Error 1 > gmake[8]: Leaving directory > `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' > gmake[7]: *** [the_vm] Error 2 > gmake[7]: Leaving directory > `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' > > > and earlier in the log: > > Assembling > /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s > rm -f solaris_x86_64.o > xarch=amd64 -o solaris_x86_64.o > /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s > /usr/bin/bash: -o: command not found > gmake[8]: [solaris_x86_64.o] Error 127 (ignored) > Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp > rm -f space.o > /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - > ... > > > I guess there should be cc before xarch, but it's omited. I'm guessing that .s is an assembly file, so most likely it is $(AS) that resolves to empty. Can you check your spec.gmk for the value of AS? /Magnus From magnus.ihse.bursie at oracle.com Mon Jun 1 23:39:05 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 01:39:05 +0200 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <5567924B.5030604@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> Message-ID: <556CED19.5050700@oracle.com> On 2015-05-29 00:10, Valerie Peng wrote: > > Please find comments in line... > > On 5/27/2015 3:42 PM, Mandy Chung wrote: >> Valerie, >> >> Did you see my comment yesterday? >> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html > Yes, we exchanged emails after this above one. I will follow up your > latest one later today. > >> >> Since you have reverted the java.security to keep the classname, to >> avoid causing merge conflict to jimage refresh, let?s remove the >> META-INF files in the first push and the build change. >> >> The security providers will be loaded via the fallback mechanism >> (i.e. ProviderLoader.legacyLoad method). You should keep the >> ProviderLoader.load method to take the provider name instead of >> classname. > Sure, I can remove the META-INF files so the providers are loaded > through the legacyLoad(). > Hmm, the ProviderLoader.load() method is used by java.security file > provider loading. Since the current list still uses class name, it > should take class name when checking for matches while iterating > through the list returned by ServiceLoader. > This way, when changes are sync'ed into Jake, no extra change required > and the providers will be loaded through ProviderLoader.load() > automatically with the current list. > >> I?ll file a bug to follow up to change java.security to list the >> provider name. This will wait after the jimage refresh goes into >> jdk9/dev > Ok. > Thanks, > Valerie I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? /Magnus >> . >> >> Mandy >> >>> On May 27, 2015, at 3:29 PM, Valerie Peng >>> wrote: >>> >>> Hi, build experts, >>> >>> Can you please review the make file related change, i.e. the new >>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>> >>> This is for merging the java.security.Provider file from various >>> providers and use the (merged) result for the final image build. >>> >>> The rest of source code changes are reviewed by my team already. >>> Thanks, >>> Valerie >>> (Java Security Team) From semyon.sadetsky at oracle.com Tue Jun 2 06:20:20 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 09:20:20 +0300 Subject: Solaris jdk9 build problem In-Reply-To: <556CEC2A.30504@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> Message-ID: <556D4B24.9010201@oracle.com> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: > On 2015-06-01 21:17, Semyon Sadetsky wrote: >> Hello, >> >> Could you help me to resolve 9 build problem on Solaris 11.2: >> >> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >> gmake[8]: *** [libjvm.so] Error 1 >> gmake[8]: Leaving directory >> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >> gmake[7]: *** [the_vm] Error 2 >> gmake[7]: Leaving directory >> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >> >> >> and earlier in the log: >> >> Assembling >> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >> rm -f solaris_x86_64.o >> xarch=amd64 -o solaris_x86_64.o >> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >> /usr/bin/bash: -o: command not found >> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >> rm -f space.o >> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >> ... >> >> >> I guess there should be cc before xarch, but it's omited. > I'm guessing that .s is an assembly file, so most likely it is $(AS) > that resolves to empty. Can you check your spec.gmk for the value of AS? > > /Magnus > Yes, AS was empty. after I set it to /opt/solarisstudio12.3/bin/cc the first error message has gone but then I got: cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit programs ld: fatal: file solaris_x86_64.o: not an ELF object gmake[8]: *** [solaris_x86_64.o] Error 2 gmake[8]: *** Waiting for unfinished jobs.... From david.holmes at oracle.com Tue Jun 2 06:27:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 16:27:24 +1000 Subject: Solaris jdk9 build problem In-Reply-To: <556D4B24.9010201@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> Message-ID: <556D4CCC.6030303@oracle.com> On 2/06/2015 4:20 PM, Semyon Sadetsky wrote: > On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>> Hello, >>> >>> Could you help me to resolve 9 build problem on Solaris 11.2: >>> >>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>> gmake[8]: *** [libjvm.so] Error 1 >>> gmake[8]: Leaving directory >>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>> >>> gmake[7]: *** [the_vm] Error 2 >>> gmake[7]: Leaving directory >>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>> >>> >>> >>> and earlier in the log: >>> >>> Assembling >>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>> rm -f solaris_x86_64.o >>> xarch=amd64 -o solaris_x86_64.o >>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>> /usr/bin/bash: -o: command not found >>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>> rm -f space.o >>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>> ... >>> >>> >>> I guess there should be cc before xarch, but it's omited. >> I'm guessing that .s is an assembly file, so most likely it is $(AS) >> that resolves to empty. Can you check your spec.gmk for the value of AS? >> >> /Magnus >> > Yes, AS was empty. That suggests something is not set correctly. > after I set it to /opt/solarisstudio12.3/bin/cc the first error message > has gone but then I got: > > cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit programs > ld: fatal: file solaris_x86_64.o: not an ELF object > gmake[8]: *** [solaris_x86_64.o] Error 2 > gmake[8]: *** Waiting for unfinished jobs.... what does cc -V show? The make logic is looking 5.9 or greater to use the new -m64 option. David ----- > > From semyon.sadetsky at oracle.com Tue Jun 2 07:54:43 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 10:54:43 +0300 Subject: Solaris jdk9 build problem In-Reply-To: <556D4CCC.6030303@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D4CCC.6030303@oracle.com> Message-ID: <556D6143.5050001@oracle.com> On 6/2/2015 9:27 AM, David Holmes wrote: > On 2/06/2015 4:20 PM, Semyon Sadetsky wrote: >> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>> >>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>> gmake[8]: *** [libjvm.so] Error 1 >>>> gmake[8]: Leaving directory >>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>> >>>> >>>> gmake[7]: *** [the_vm] Error 2 >>>> gmake[7]: Leaving directory >>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>> >>>> >>>> >>>> >>>> and earlier in the log: >>>> >>>> Assembling >>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>> rm -f solaris_x86_64.o >>>> xarch=amd64 -o solaris_x86_64.o >>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>> /usr/bin/bash: -o: command not found >>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>> rm -f space.o >>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>> ... >>>> >>>> >>>> I guess there should be cc before xarch, but it's omited. >>> I'm guessing that .s is an assembly file, so most likely it is $(AS) >>> that resolves to empty. Can you check your spec.gmk for the value of >>> AS? >>> >>> /Magnus >>> >> Yes, AS was empty. > > That suggests something is not set correctly. > >> after I set it to /opt/solarisstudio12.3/bin/cc the first error message >> has gone but then I got: >> >> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >> programs >> ld: fatal: file solaris_x86_64.o: not an ELF object >> gmake[8]: *** [solaris_x86_64.o] Error 2 >> gmake[8]: *** Waiting for unfinished jobs.... > > what does cc -V show? The make logic is looking 5.9 or greater to use > the new -m64 option. > > David > ----- > dev at solaris1:/jdk9/client$ /opt/solarisstudio12.3/bin/cc -V cc: Sun C 5.12 SunOS_i386 2011/11/16 I have also solaris studio 12.4 installed in this VM but it is in another dir and not on the path. From bertrand.delsart at oracle.com Tue Jun 2 08:40:17 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 02 Jun 2015 10:40:17 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556CEBEA.3020804@oracle.com> References: <556C94FE.9000805@oracle.com> <556CEBEA.3020804@oracle.com> Message-ID: <556D6BF1.4020507@oracle.com> Thanks David, Answers inlined. On 02/06/2015 01:34, David Holmes wrote: > Hi Bertrand, > > On 2/06/2015 3:23 AM, Bertrand Delsart wrote: >> Hi all, >> >> A small open webrev to fix some issues around >> --disable-warnings-as-errors (this is not a full cleanup): >> >> http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ >> >> Without the fix, -Werror is used to compiled native JDK libraries even >> when the --disable-warnings-as-errors is used. >> >> A lot of these libs are addressed by clearing CFLAGS_WARNINGS_ARE_ERRORS >> in flags.m4 > > I'd be tempted to make the whole case statement that sets > CFLAGS_WARNINGS_ARE_ERRORS and DISABLE_WARNING_PREFIX conditional on > WARNINGS_AS_ERRORS. But that's for the build folk to decide. I did not do it so that DISABLE_WARNING_PREFIX is always defined. This allows to tune the reported warnings while still not causing an error if we cannot eliminate all warnings (e.g. use something like "-Wall -Wno-..." without "-Werror"). > > But I think your change should probably be expressed as: > > if test "WARNINGS_AS_ERRORS" = "true"; then ... I had tried something like that first but must have got the syntax wrong. The new version below seems to work (will do a jprt run to check all platforms): if test "$WARNINGS_AS_ERRORS" = "false"; then CFLAGS_WARNINGS_ARE_ERRORS="" fi Bertrand. >> Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. >> Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the >> mechanism put in place in that file to disable -Werror and control it >> through the WARNINGS_AS_ERRORS configured value. > > Seems fine. > > Thanks, > David > > >> Best regards, >> >> Bertrand. >> -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From magnus.ihse.bursie at oracle.com Tue Jun 2 08:47:18 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 10:47:18 +0200 Subject: Solaris jdk9 build problem In-Reply-To: <556D4B24.9010201@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> Message-ID: <556D6D96.1080605@oracle.com> On 2015-06-02 08:20, Semyon Sadetsky wrote: > On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>> Hello, >>> >>> Could you help me to resolve 9 build problem on Solaris 11.2: >>> >>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>> gmake[8]: *** [libjvm.so] Error 1 >>> gmake[8]: Leaving directory >>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>> gmake[7]: *** [the_vm] Error 2 >>> gmake[7]: Leaving directory >>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>> >>> >>> and earlier in the log: >>> >>> Assembling >>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>> rm -f solaris_x86_64.o >>> xarch=amd64 -o solaris_x86_64.o >>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>> /usr/bin/bash: -o: command not found >>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>> rm -f space.o >>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>> ... >>> >>> >>> I guess there should be cc before xarch, but it's omited. >> I'm guessing that .s is an assembly file, so most likely it is $(AS) >> that resolves to empty. Can you check your spec.gmk for the value of AS? >> >> /Magnus >> > Yes, AS was empty. > after I set it to /opt/solarisstudio12.3/bin/cc the first error > message has gone but then I got: You cannot set it manually. If configure has failed to detect it, all bets are off. I'm a bit surprised that configure allowed AS to be empty, it should have aborted. Try running configure with --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help you get a proper value of AS. /Magnus > > cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit > programs > ld: fatal: file solaris_x86_64.o: not an ELF object > gmake[8]: *** [solaris_x86_64.o] Error 2 > gmake[8]: *** Waiting for unfinished jobs.... > > > From magnus.ihse.bursie at oracle.com Tue Jun 2 08:58:33 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 10:58:33 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556C94FE.9000805@oracle.com> References: <556C94FE.9000805@oracle.com> Message-ID: <556D7039.1020606@oracle.com> On 2015-06-01 19:23, Bertrand Delsart wrote: > Hi all, > > A small open webrev to fix some issues around > --disable-warnings-as-errors (this is not a full cleanup): > > http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ > > Without the fix, -Werror is used to compiled native JDK libraries even > when the --disable-warnings-as-errors is used. > > A lot of these libs are addressed by clearing > CFLAGS_WARNINGS_ARE_ERRORS in flags.m4 > > Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. > Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the > mechanism put in place in that file to disable -Werror and control it > through the WARNINGS_AS_ERRORS configured value. I think this patch will require some work to be OK. First of all, I'm not quite sure I understand what problem you are trying to solve. What libraries are compiled with -Werror when --disable-warnings-as-errors is used? This should not be the case, and I cannot reproduce it on my system. CFLAGS_WARNINGS_ARE_ERRORS should never be cleared, since that is only exported as the mechanism to use for enabling warnings as errors. If no compilation includes it (which it should not if warnings-as-errors are disabled), it won't affect the build. If CFLAGS_WARNINGS_ARE_ERRORS are used even though warnings-as-errors are disabled, then it is this usage that should be fixed. I can see that libsctp is a special case that hard-codes -Werror. But in this case we should remove the hard-coding and relying on the system setting. This is probably a remnant from before the overall -Werror usage, where the authors of a specific lib wanted to enforce a higher standard. Also, it might be worth revisiting if -Wno-error=unused-parameter is really needed. These things tend to bit-rot. /Magnus > > Best regards, > > Bertrand. > From semyon.sadetsky at oracle.com Tue Jun 2 09:25:28 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 12:25:28 +0300 Subject: Solaris jdk9 build problem In-Reply-To: <556D6D96.1080605@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> Message-ID: <556D7688.5090000@oracle.com> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: > On 2015-06-02 08:20, Semyon Sadetsky wrote: >> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>> Hello, >>>> >>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>> >>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>> gmake[8]: *** [libjvm.so] Error 1 >>>> gmake[8]: Leaving directory >>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>> gmake[7]: *** [the_vm] Error 2 >>>> gmake[7]: Leaving directory >>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>> >>>> >>>> and earlier in the log: >>>> >>>> Assembling >>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>> rm -f solaris_x86_64.o >>>> xarch=amd64 -o solaris_x86_64.o >>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>> /usr/bin/bash: -o: command not found >>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>> rm -f space.o >>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>> ... >>>> >>>> >>>> I guess there should be cc before xarch, but it's omited. >>> I'm guessing that .s is an assembly file, so most likely it is $(AS) >>> that resolves to empty. Can you check your spec.gmk for the value of >>> AS? >>> >>> /Magnus >>> >> Yes, AS was empty. >> after I set it to /opt/solarisstudio12.3/bin/cc the first error >> message has gone but then I got: > You cannot set it manually. If configure has failed to detect it, all > bets are off. I'm a bit surprised that configure allowed AS to be > empty, it should have aborted. > > Try running configure with > --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help you > get a proper value of AS. > > /Magnus AS remains empty: ==================================================== A new configuration has been successfully created in /jdk9/client/build/solaris-x86_64-normal-server-fastdebug using configure arguments '--enable-debug --with-toolchain-path=/opt/solarisstudio12.3/bin'. Configuration summary: * Debug level: fastdebug * HS debug level: fastdebug * JDK variant: normal * JVM variants: server * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 64 Tools summary: * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) * Toolchain: solstudio (Oracle Solaris Studio) * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) Build performance summary: * Cores to use: 2 * Memory limit: 2048 MB dev at solaris1:/jdk9/client$ grep "AS:" /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk AS:= dev at solaris1:/jdk9/client$ > >> >> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >> programs >> ld: fatal: file solaris_x86_64.o: not an ELF object >> gmake[8]: *** [solaris_x86_64.o] Error 2 >> gmake[8]: *** Waiting for unfinished jobs.... >> >> >> > From david.holmes at oracle.com Tue Jun 2 09:57:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 19:57:14 +1000 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D7039.1020606@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> Message-ID: <556D7DFA.4020706@oracle.com> On 2/06/2015 6:58 PM, Magnus Ihse Bursie wrote: > On 2015-06-01 19:23, Bertrand Delsart wrote: >> Hi all, >> >> A small open webrev to fix some issues around >> --disable-warnings-as-errors (this is not a full cleanup): >> >> http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ >> >> Without the fix, -Werror is used to compiled native JDK libraries even >> when the --disable-warnings-as-errors is used. >> >> A lot of these libs are addressed by clearing >> CFLAGS_WARNINGS_ARE_ERRORS in flags.m4 >> >> Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. >> Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the >> mechanism put in place in that file to disable -Werror and control it >> through the WARNINGS_AS_ERRORS configured value. > I think this patch will require some work to be OK. > > First of all, I'm not quite sure I understand what problem you are > trying to solve. What libraries are compiled with -Werror when > --disable-warnings-as-errors is used? This should not be the case, and I > cannot reproduce it on my system. > > CFLAGS_WARNINGS_ARE_ERRORS should never be cleared, since that is only > exported as the mechanism to use for enabling warnings as errors. If no > compilation includes it (which it should not if warnings-as-errors are > disabled), it won't affect the build. If CFLAGS_WARNINGS_ARE_ERRORS are > used even though warnings-as-errors are disabled, then it is this usage > that should be fixed. AFAICS most uses of CFLAGS_WARNINGS_ARE_ERRORS are unconditional eg: $(eval $(call SetupNativeCompilation,BUILD_LIBINSTRUMENT, \ LIBRARY := instrument, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ SRC := $(LIBINSTRUMENT_SRC), \ OPTIMIZATION := LOW, \ CFLAGS := $(LIBINSTRUMENT_CFLAGS) $(CFLAGS_WARNINGS_ARE_ERRORS), \ So clearing it is the simplest way to avoid it being applied. David ----- > I can see that libsctp is a special case that hard-codes -Werror. But in > this case we should remove the hard-coding and relying on the system > setting. This is probably a remnant from before the overall -Werror > usage, where the authors of a specific lib wanted to enforce a higher > standard. Also, it might be worth revisiting if > -Wno-error=unused-parameter is really needed. These things tend to bit-rot. > > /Magnus > >> >> Best regards, >> >> Bertrand. >> > From david.holmes at oracle.com Tue Jun 2 09:57:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 19:57:37 +1000 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D6BF1.4020507@oracle.com> References: <556C94FE.9000805@oracle.com> <556CEBEA.3020804@oracle.com> <556D6BF1.4020507@oracle.com> Message-ID: <556D7E11.1080900@oracle.com> On 2/06/2015 6:40 PM, Bertrand Delsart wrote: > Thanks David, > > Answers inlined. > > On 02/06/2015 01:34, David Holmes wrote: >> Hi Bertrand, >> >> On 2/06/2015 3:23 AM, Bertrand Delsart wrote: >>> Hi all, >>> >>> A small open webrev to fix some issues around >>> --disable-warnings-as-errors (this is not a full cleanup): >>> >>> http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ >>> >>> Without the fix, -Werror is used to compiled native JDK libraries even >>> when the --disable-warnings-as-errors is used. >>> >>> A lot of these libs are addressed by clearing CFLAGS_WARNINGS_ARE_ERRORS >>> in flags.m4 >> >> I'd be tempted to make the whole case statement that sets >> CFLAGS_WARNINGS_ARE_ERRORS and DISABLE_WARNING_PREFIX conditional on >> WARNINGS_AS_ERRORS. But that's for the build folk to decide. > > I did not do it so that DISABLE_WARNING_PREFIX is always defined. This > allows to tune the reported warnings while still not causing an error if > we cannot eliminate all warnings (e.g. use something like "-Wall > -Wno-..." without "-Werror"). Ah yes - good point. In that case what you have done seems the simplest fix. David >> >> But I think your change should probably be expressed as: >> >> if test "WARNINGS_AS_ERRORS" = "true"; then ... > > I had tried something like that first but must have got the syntax > wrong. The new version below seems to work (will do a jprt run to check > all platforms): > > if test "$WARNINGS_AS_ERRORS" = "false"; then > CFLAGS_WARNINGS_ARE_ERRORS="" > fi > > Bertrand. > >>> Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. >>> Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the >>> mechanism put in place in that file to disable -Werror and control it >>> through the WARNINGS_AS_ERRORS configured value. >> >> Seems fine. >> >> Thanks, >> David >> >> >>> Best regards, >>> >>> Bertrand. >>> > > From erik.joelsson at oracle.com Tue Jun 2 10:00:12 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 02 Jun 2015 12:00:12 +0200 Subject: RFR: JDK-8081471 Allow SetupTestFilesCompilation to set LDFLAGS for individual tests In-Reply-To: <55682E1F.3090106@oracle.com> References: <55682E1F.3090106@oracle.com> Message-ID: <556D7EAC.2060507@oracle.com> Looks good to me. /Erik On 2015-05-29 11:15, Magnus Ihse Bursie wrote: > A request have been made to be able to set specific LDFLAGS for > individual tests/libraries in SetupTestFilesCompilation, similar to > the CFLAGS_filename construct in SetupNativeCompilation, > e.g. > LDFLAGS_libFooBar := -lfooflag > > It is trivial to also add CFLAGS functionality in a similar manner. > > This functionality will be used to resolve a test problem in hotspot, > so it is possible that I will push this fix to a hotspot forest > instead of jdk9/dev. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081471 > WebRev inline: > > diff --git a/make/common/TestFilesCompilation.gmk > b/make/common/TestFilesCompilation.gmk > --- a/make/common/TestFilesCompilation.gmk > +++ b/make/common/TestFilesCompilation.gmk > @@ -86,8 +86,8 @@ > OBJECT_DIR := $$($1_OUTPUT_DIR)/support/$$($1_PREFIX)$$(name), \ > OUTPUT_DIR := $$($1_OUTPUT_DIR)/$$($1_OUTPUT_SUBDIR), \ > LANG := C, \ > - CFLAGS := $$($1_CFLAGS), \ > - LDFLAGS := $$($1_LDFLAGS), \ > + CFLAGS := $$($1_CFLAGS) $$($1_CFLAGS_$$($1_PREFIX)$$(name)), \ > + LDFLAGS := $$($1_LDFLAGS) > $$($1_LDFLAGS_$$($1_PREFIX)$$(name)), \ > OPTIMIZATION := LOW, \ > DEBUG_SYMBOLS := true)) \ > $$(eval $1 += $$(BUILD_TEST_$$(name)) ) \ > > /Magnus > From david.holmes at oracle.com Tue Jun 2 10:00:50 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 20:00:50 +1000 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D7DFA.4020706@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> Message-ID: <556D7ED2.5030806@oracle.com> On 2/06/2015 7:57 PM, David Holmes wrote: > On 2/06/2015 6:58 PM, Magnus Ihse Bursie wrote: >> On 2015-06-01 19:23, Bertrand Delsart wrote: >>> Hi all, >>> >>> A small open webrev to fix some issues around >>> --disable-warnings-as-errors (this is not a full cleanup): >>> >>> http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ >>> >>> Without the fix, -Werror is used to compiled native JDK libraries even >>> when the --disable-warnings-as-errors is used. >>> >>> A lot of these libs are addressed by clearing >>> CFLAGS_WARNINGS_ARE_ERRORS in flags.m4 >>> >>> Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. >>> Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the >>> mechanism put in place in that file to disable -Werror and control it >>> through the WARNINGS_AS_ERRORS configured value. >> I think this patch will require some work to be OK. >> >> First of all, I'm not quite sure I understand what problem you are >> trying to solve. What libraries are compiled with -Werror when >> --disable-warnings-as-errors is used? This should not be the case, and I >> cannot reproduce it on my system. >> >> CFLAGS_WARNINGS_ARE_ERRORS should never be cleared, since that is only >> exported as the mechanism to use for enabling warnings as errors. If no >> compilation includes it (which it should not if warnings-as-errors are >> disabled), it won't affect the build. If CFLAGS_WARNINGS_ARE_ERRORS are >> used even though warnings-as-errors are disabled, then it is this usage >> that should be fixed. > > AFAICS most uses of CFLAGS_WARNINGS_ARE_ERRORS are unconditional eg: > > $(eval $(call SetupNativeCompilation,BUILD_LIBINSTRUMENT, \ > LIBRARY := instrument, \ > OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ > SRC := $(LIBINSTRUMENT_SRC), \ > OPTIMIZATION := LOW, \ > CFLAGS := $(LIBINSTRUMENT_CFLAGS) $(CFLAGS_WARNINGS_ARE_ERRORS), \ > > So clearing it is the simplest way to avoid it being applied. Aside: this looks like a bug: ./lib/Lib-jdk.jdwp.agent.gmk $(eval $(call SetupNativeCompilation,BUILD_LIBDT_SOCKET, \ LIBRARY := dt_socket, \ OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ SRC := $(LIBDT_SOCKET_SRC), \ OPTIMIZATION := LOW, \ CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_CFLAGS_WARNINGS_ARE_ERRORS) -DUSE_MMAP \ CFLAGS_CFLAGS ? David > David > ----- > > > >> I can see that libsctp is a special case that hard-codes -Werror. But in >> this case we should remove the hard-coding and relying on the system >> setting. This is probably a remnant from before the overall -Werror >> usage, where the authors of a specific lib wanted to enforce a higher >> standard. Also, it might be worth revisiting if >> -Wno-error=unused-parameter is really needed. These things tend to >> bit-rot. >> >> /Magnus >> >>> >>> Best regards, >>> >>> Bertrand. >>> >> From magnus.ihse.bursie at oracle.com Tue Jun 2 10:06:49 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 12:06:49 +0200 Subject: Solaris jdk9 build problem In-Reply-To: <556D7688.5090000@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> Message-ID: <556D8039.3000400@oracle.com> On 2015-06-02 11:25, Semyon Sadetsky wrote: > > On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>> >>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>> gmake[8]: Leaving directory >>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>> gmake[7]: *** [the_vm] Error 2 >>>>> gmake[7]: Leaving directory >>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>> >>>>> >>>>> and earlier in the log: >>>>> >>>>> Assembling >>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>> rm -f solaris_x86_64.o >>>>> xarch=amd64 -o solaris_x86_64.o >>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>> /usr/bin/bash: -o: command not found >>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>> rm -f space.o >>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>> ... >>>>> >>>>> >>>>> I guess there should be cc before xarch, but it's omited. >>>> I'm guessing that .s is an assembly file, so most likely it is >>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>> value of AS? >>>> >>>> /Magnus >>>> >>> Yes, AS was empty. >>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>> message has gone but then I got: >> You cannot set it manually. If configure has failed to detect it, all >> bets are off. I'm a bit surprised that configure allowed AS to be >> empty, it should have aborted. >> >> Try running configure with >> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help you >> get a proper value of AS. >> >> /Magnus > > AS remains empty: > ==================================================== > A new configuration has been successfully created in > /jdk9/client/build/solaris-x86_64-normal-server-fastdebug > using configure arguments '--enable-debug > --with-toolchain-path=/opt/solarisstudio12.3/bin'. > > Configuration summary: > * Debug level: fastdebug > * HS debug level: fastdebug > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 64 > > Tools summary: > * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime > Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM > (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) > * Toolchain: solstudio (Oracle Solaris Studio) > * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) > * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) > > Build performance summary: > * Cores to use: 2 > * Memory limit: 2048 MB > > dev at solaris1:/jdk9/client$ grep "AS:" > /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk > AS:= Do you have an as in your path or in /opt/solarisstudio12.3/bin then? Have you even built jdk successfully on this machine? /Magnus > dev at solaris1:/jdk9/client$ > > >> >>> >>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>> programs >>> ld: fatal: file solaris_x86_64.o: not an ELF object >>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>> gmake[8]: *** Waiting for unfinished jobs.... >>> >>> >>> >> > From semyon.sadetsky at oracle.com Tue Jun 2 10:12:15 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 13:12:15 +0300 Subject: Solaris jdk9 build problem In-Reply-To: <556D8039.3000400@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> Message-ID: <556D817F.8090206@oracle.com> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: > On 2015-06-02 11:25, Semyon Sadetsky wrote: >> >> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>> >>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>> gmake[8]: Leaving directory >>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>> gmake[7]: Leaving directory >>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>> >>>>>> >>>>>> and earlier in the log: >>>>>> >>>>>> Assembling >>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>> rm -f solaris_x86_64.o >>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>> /usr/bin/bash: -o: command not found >>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>> rm -f space.o >>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>> ... >>>>>> >>>>>> >>>>>> I guess there should be cc before xarch, but it's omited. >>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>>> value of AS? >>>>> >>>>> /Magnus >>>>> >>>> Yes, AS was empty. >>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>> message has gone but then I got: >>> You cannot set it manually. If configure has failed to detect it, >>> all bets are off. I'm a bit surprised that configure allowed AS to >>> be empty, it should have aborted. >>> >>> Try running configure with >>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help you >>> get a proper value of AS. >>> >>> /Magnus >> >> AS remains empty: >> ==================================================== >> A new configuration has been successfully created in >> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >> using configure arguments '--enable-debug >> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >> >> Configuration summary: >> * Debug level: fastdebug >> * HS debug level: fastdebug >> * JDK variant: normal >> * JVM variants: server >> * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 64 >> >> Tools summary: >> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >> * Toolchain: solstudio (Oracle Solaris Studio) >> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >> >> Build performance summary: >> * Cores to use: 2 >> * Memory limit: 2048 MB >> >> dev at solaris1:/jdk9/client$ grep "AS:" >> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >> AS:= > > Do you have an as in your path or in /opt/solarisstudio12.3/bin then? > Have you even built jdk successfully on this machine? > > /Magnus > No it's a new installation. And I'm building jdk on Solaris for the first time. as is absent in /opt/solarisstudio12.3/bin. dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin CC cscope er_bit f90 rtc_patch_area sunf90 CCadmin ctc er_cp f95 rxm sunf95 amd64 ctcr er_export fbe rxs sunstudio analyzer ctrace er_generic fdumpmod smctl tcov bcheck cxref er_html fpp solstudio tha binopt dbx er_kernel fpr spot uncover c++filt dbxtool er_mpipp fsplit spot_diff version c89 dem er_mv gen_custom ss_attach whatdir c99 discover er_otfdump getmsg sunCC xprof_atob cb dlight er_print indent sunas xprof_btoa cc dmake er_rm lint sunc89 cc-5.0 dumpstabs er_src lock_lint sunc99 cflow dwarfdump er_vtunify ptclean suncc collect er_archive f77 ripc sunf77 Should it be there? >> dev at solaris1:/jdk9/client$ >> >> >>> >>>> >>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>>> programs >>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>> gmake[8]: *** Waiting for unfinished jobs.... >>>> >>>> >>>> >>> >> > From david.holmes at oracle.com Tue Jun 2 10:13:37 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 20:13:37 +1000 Subject: Solaris jdk9 build problem In-Reply-To: <556D6143.5050001@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D4CCC.6030303@oracle.com> <556D6143.5050001@oracle.com> Message-ID: <556D81D1.6040801@oracle.com> On 2/06/2015 5:54 PM, Semyon Sadetsky wrote: > > On 6/2/2015 9:27 AM, David Holmes wrote: >> On 2/06/2015 4:20 PM, Semyon Sadetsky wrote: >>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>> Hello, >>>>> >>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>> >>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>> gmake[8]: Leaving directory >>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>> >>>>> >>>>> gmake[7]: *** [the_vm] Error 2 >>>>> gmake[7]: Leaving directory >>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>> >>>>> >>>>> >>>>> >>>>> and earlier in the log: >>>>> >>>>> Assembling >>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>> rm -f solaris_x86_64.o >>>>> xarch=amd64 -o solaris_x86_64.o >>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>> /usr/bin/bash: -o: command not found >>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>> rm -f space.o >>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>> ... >>>>> >>>>> >>>>> I guess there should be cc before xarch, but it's omited. >>>> I'm guessing that .s is an assembly file, so most likely it is $(AS) >>>> that resolves to empty. Can you check your spec.gmk for the value of >>>> AS? >>>> >>>> /Magnus >>>> >>> Yes, AS was empty. >> >> That suggests something is not set correctly. >> >>> after I set it to /opt/solarisstudio12.3/bin/cc the first error message >>> has gone but then I got: >>> >>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>> programs >>> ld: fatal: file solaris_x86_64.o: not an ELF object >>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>> gmake[8]: *** Waiting for unfinished jobs.... >> >> what does cc -V show? The make logic is looking 5.9 or greater to use >> the new -m64 option. >> >> David >> ----- >> > dev at solaris1:/jdk9/client$ /opt/solarisstudio12.3/bin/cc -V > cc: Sun C 5.12 SunOS_i386 2011/11/16 Then something else must be going wrong that prevents the version check from being executed successfully. If you configure with LOG_LEVEL=debug does the build log show any missing commands etc prior to the error above? There's obviously something generally wrong with your setup based on the AS problem. David > I have also solaris studio 12.4 installed in this VM but it is in > another dir and not on the path. > From erik.joelsson at oracle.com Tue Jun 2 10:17:10 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 02 Jun 2015 12:17:10 +0200 Subject: Solaris jdk9 build problem In-Reply-To: <556D817F.8090206@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> Message-ID: <556D82A6.7040107@oracle.com> When I build on Solaris, configure finds 'as' in the Solaris Studio bin dir. /Erik On 2015-06-02 12:12, Semyon Sadetsky wrote: > > On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>> >>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>> >>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>> gmake[8]: Leaving directory >>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>> gmake[7]: Leaving directory >>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>> >>>>>>> >>>>>>> and earlier in the log: >>>>>>> >>>>>>> Assembling >>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>> rm -f solaris_x86_64.o >>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>> /usr/bin/bash: -o: command not found >>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>> rm -f space.o >>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>>>> value of AS? >>>>>> >>>>>> /Magnus >>>>>> >>>>> Yes, AS was empty. >>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>> message has gone but then I got: >>>> You cannot set it manually. If configure has failed to detect it, >>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>> be empty, it should have aborted. >>>> >>>> Try running configure with >>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help >>>> you get a proper value of AS. >>>> >>>> /Magnus >>> >>> AS remains empty: >>> ==================================================== >>> A new configuration has been successfully created in >>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>> using configure arguments '--enable-debug >>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>> >>> Configuration summary: >>> * Debug level: fastdebug >>> * HS debug level: fastdebug >>> * JDK variant: normal >>> * JVM variants: server >>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>> length: 64 >>> >>> Tools summary: >>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>> * Toolchain: solstudio (Oracle Solaris Studio) >>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>> >>> Build performance summary: >>> * Cores to use: 2 >>> * Memory limit: 2048 MB >>> >>> dev at solaris1:/jdk9/client$ grep "AS:" >>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>> AS:= >> >> Do you have an as in your path or in /opt/solarisstudio12.3/bin then? >> Have you even built jdk successfully on this machine? >> >> /Magnus >> > No it's a new installation. And I'm building jdk on Solaris for the > first time. > as is absent in /opt/solarisstudio12.3/bin. > > dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin > CC cscope er_bit f90 rtc_patch_area > sunf90 > CCadmin ctc er_cp f95 rxm > sunf95 > amd64 ctcr er_export fbe rxs > sunstudio > analyzer ctrace er_generic fdumpmod > smctl tcov > bcheck cxref er_html fpp solstudio tha > binopt dbx er_kernel fpr spot > uncover > c++filt dbxtool er_mpipp fsplit spot_diff > version > c89 dem er_mv gen_custom > ss_attach whatdir > c99 discover er_otfdump getmsg sunCC > xprof_atob > cb dlight er_print indent sunas > xprof_btoa > cc dmake er_rm lint sunc89 > cc-5.0 dumpstabs er_src lock_lint sunc99 > cflow dwarfdump er_vtunify ptclean suncc > collect er_archive f77 ripc sunf77 > > Should it be there? > > > >>> dev at solaris1:/jdk9/client$ >>> >>> >>>> >>>>> >>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>>>> programs >>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>> >>>>> >>>>> >>>> >>> >> > From erik.joelsson at oracle.com Tue Jun 2 10:18:53 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 02 Jun 2015 12:18:53 +0200 Subject: Solaris jdk9 build problem In-Reply-To: <556D82A6.7040107@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D82A6.7040107@oracle.com> Message-ID: <556D830D.6060200@oracle.com> Or no, I wrote too fast. The assembler 'as' is part of Solaris and not Solaris Studio. You need to install the correct package to get it in /usr/bin/as. /Erik On 2015-06-02 12:17, Erik Joelsson wrote: > When I build on Solaris, configure finds 'as' in the Solaris Studio > bin dir. > > /Erik > > On 2015-06-02 12:12, Semyon Sadetsky wrote: >> >> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>> >>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>> >>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>> gmake[8]: Leaving directory >>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>> gmake[7]: Leaving directory >>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>> >>>>>>>> >>>>>>>> and earlier in the log: >>>>>>>> >>>>>>>> Assembling >>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>> rm -f solaris_x86_64.o >>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>> rm -f space.o >>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for >>>>>>> the value of AS? >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>> Yes, AS was empty. >>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>> message has gone but then I got: >>>>> You cannot set it manually. If configure has failed to detect it, >>>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>>> be empty, it should have aborted. >>>>> >>>>> Try running configure with >>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help >>>>> you get a proper value of AS. >>>>> >>>>> /Magnus >>>> >>>> AS remains empty: >>>> ==================================================== >>>> A new configuration has been successfully created in >>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>> using configure arguments '--enable-debug >>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>> >>>> Configuration summary: >>>> * Debug level: fastdebug >>>> * HS debug level: fastdebug >>>> * JDK variant: normal >>>> * JVM variants: server >>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>> length: 64 >>>> >>>> Tools summary: >>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>> >>>> Build performance summary: >>>> * Cores to use: 2 >>>> * Memory limit: 2048 MB >>>> >>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>> AS:= >>> >>> Do you have an as in your path or in /opt/solarisstudio12.3/bin >>> then? Have you even built jdk successfully on this machine? >>> >>> /Magnus >>> >> No it's a new installation. And I'm building jdk on Solaris for the >> first time. >> as is absent in /opt/solarisstudio12.3/bin. >> >> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >> CC cscope er_bit f90 rtc_patch_area >> sunf90 >> CCadmin ctc er_cp f95 rxm >> sunf95 >> amd64 ctcr er_export fbe rxs >> sunstudio >> analyzer ctrace er_generic fdumpmod >> smctl tcov >> bcheck cxref er_html fpp solstudio tha >> binopt dbx er_kernel fpr spot >> uncover >> c++filt dbxtool er_mpipp fsplit >> spot_diff version >> c89 dem er_mv gen_custom >> ss_attach whatdir >> c99 discover er_otfdump getmsg >> sunCC xprof_atob >> cb dlight er_print indent >> sunas xprof_btoa >> cc dmake er_rm lint sunc89 >> cc-5.0 dumpstabs er_src lock_lint sunc99 >> cflow dwarfdump er_vtunify ptclean suncc >> collect er_archive f77 ripc sunf77 >> >> Should it be there? >> >> >> >>>> dev at solaris1:/jdk9/client$ >>>> >>>> >>>>> >>>>>> >>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create >>>>>> 64-bit programs >>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Tue Jun 2 10:22:59 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 12:22:59 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D7DFA.4020706@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> Message-ID: <556D8403.8040905@oracle.com> On 2015-06-02 11:57, David Holmes wrote: > On 2/06/2015 6:58 PM, Magnus Ihse Bursie wrote: >> On 2015-06-01 19:23, Bertrand Delsart wrote: >>> Hi all, >>> >>> A small open webrev to fix some issues around >>> --disable-warnings-as-errors (this is not a full cleanup): >>> >>> http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ >>> >>> Without the fix, -Werror is used to compiled native JDK libraries even >>> when the --disable-warnings-as-errors is used. >>> >>> A lot of these libs are addressed by clearing >>> CFLAGS_WARNINGS_ARE_ERRORS in flags.m4 >>> >>> Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. >>> Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the >>> mechanism put in place in that file to disable -Werror and control it >>> through the WARNINGS_AS_ERRORS configured value. >> I think this patch will require some work to be OK. >> >> First of all, I'm not quite sure I understand what problem you are >> trying to solve. What libraries are compiled with -Werror when >> --disable-warnings-as-errors is used? This should not be the case, and I >> cannot reproduce it on my system. >> >> CFLAGS_WARNINGS_ARE_ERRORS should never be cleared, since that is only >> exported as the mechanism to use for enabling warnings as errors. If no >> compilation includes it (which it should not if warnings-as-errors are >> disabled), it won't affect the build. If CFLAGS_WARNINGS_ARE_ERRORS are >> used even though warnings-as-errors are disabled, then it is this usage >> that should be fixed. > > AFAICS most uses of CFLAGS_WARNINGS_ARE_ERRORS are unconditional eg: > > $(eval $(call SetupNativeCompilation,BUILD_LIBINSTRUMENT, \ > LIBRARY := instrument, \ > OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ > SRC := $(LIBINSTRUMENT_SRC), \ > OPTIMIZATION := LOW, \ > CFLAGS := $(LIBINSTRUMENT_CFLAGS) $(CFLAGS_WARNINGS_ARE_ERRORS), \ > > So clearing it is the simplest way to avoid it being applied. Ah, I see. It might be the simplest but it's not correct. :-) Arguably, these cases should have been removed when the global warnings-as-errors functionality was introduced. I count to 9 instances (including the incorrect usage in Lib-jdk.jdwp.agent.gmk) of excplicitely hard-coding CFLAGS_WARNINGS_ARE_ERRORS: make/lib/Lib-jdk.jdi.gmk: CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) -DUSE_MMAP \ make/lib/Lib-jdk.hprof.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ make/lib/Lib-jdk.hprof.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ make/lib/Lib-java.instrument.gmk: CFLAGS := $(LIBINSTRUMENT_CFLAGS) $(CFLAGS_WARNINGS_ARE_ERRORS), \ make/lib/Lib-jdk.management.gmk: CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) $(LIBMANAGEMENT_EXT_CFLAGS), \ make/lib/Lib-jdk.attach.gmk: CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) \ make/lib/Lib-jdk.jdwp.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_CFLAGS_WARNINGS_ARE_ERRORS) -DUSE_MMAP \ make/lib/Lib-jdk.jdwp.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) -DJDWP_LOGGING \ make/lib/Lib-java.management.gmk: CFLAGS := $(CFLAGS_JDKLIB) $(CFLAGS_WARNINGS_ARE_ERRORS) $(LIBMANAGEMENT_CFLAGS), \ These should be removed instead. I also checked for -Werror in the code, but could only find the already discovered location in Lib-jdk.sctp.gmk. For that, I believe the proper solution is: diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk --- a/make/lib/Lib-jdk.sctp.gmk +++ b/make/lib/Lib-jdk.sctp.gmk @@ -30,12 +30,8 @@ ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) - - # Suppress unused parameters required by exported JNI functions. - SCTP_WERROR := -Werror -Wno-error=unused-parameter - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) - SCTP_WERROR := - endif + # DISABLED_WARNINGS_gcc := unusused-parameter needed to + # suppress unused parameters required by exported JNI functions. $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ LIBRARY := sctp, \ @@ -49,7 +45,7 @@ $(LIBJAVA_HEADER_FLAGS) \ -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ - CFLAGS_linux := $(SCTP_WERROR), \ + DISABLED_WARNINGS_gcc := unusused-parameter, \ MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ LDFLAGS := $(LDFLAGS_JDKLIB) \ $(call SET_SHARED_LIBRARY_ORIGIN), \ However, as I said, it should probably be verified that it is correct that the unused-parameter warning is still triggered. /Magnus > > David > ----- > > > >> I can see that libsctp is a special case that hard-codes -Werror. But in >> this case we should remove the hard-coding and relying on the system >> setting. This is probably a remnant from before the overall -Werror >> usage, where the authors of a specific lib wanted to enforce a higher >> standard. Also, it might be worth revisiting if >> -Wno-error=unused-parameter is really needed. These things tend to >> bit-rot. >> >> /Magnus >> >>> >>> Best regards, >>> >>> Bertrand. >>> >> From david.holmes at oracle.com Tue Jun 2 10:22:15 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 20:22:15 +1000 Subject: Solaris jdk9 build problem In-Reply-To: <556D817F.8090206@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> Message-ID: <556D83D7.5020206@oracle.com> On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: > > On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>> >>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>> Hello, >>>>>>> >>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>> >>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>> gmake[8]: Leaving directory >>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>> >>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>> gmake[7]: Leaving directory >>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>> >>>>>>> >>>>>>> >>>>>>> and earlier in the log: >>>>>>> >>>>>>> Assembling >>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>> rm -f solaris_x86_64.o >>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>> /usr/bin/bash: -o: command not found >>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>> rm -f space.o >>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>> ... >>>>>>> >>>>>>> >>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>>>> value of AS? >>>>>> >>>>>> /Magnus >>>>>> >>>>> Yes, AS was empty. >>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>> message has gone but then I got: >>>> You cannot set it manually. If configure has failed to detect it, >>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>> be empty, it should have aborted. >>>> >>>> Try running configure with >>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help you >>>> get a proper value of AS. >>>> >>>> /Magnus >>> >>> AS remains empty: >>> ==================================================== >>> A new configuration has been successfully created in >>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>> using configure arguments '--enable-debug >>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>> >>> Configuration summary: >>> * Debug level: fastdebug >>> * HS debug level: fastdebug >>> * JDK variant: normal >>> * JVM variants: server >>> * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 64 >>> >>> Tools summary: >>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>> * Toolchain: solstudio (Oracle Solaris Studio) >>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>> >>> Build performance summary: >>> * Cores to use: 2 >>> * Memory limit: 2048 MB >>> >>> dev at solaris1:/jdk9/client$ grep "AS:" >>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>> AS:= >> >> Do you have an as in your path or in /opt/solarisstudio12.3/bin then? >> Have you even built jdk successfully on this machine? >> >> /Magnus >> > No it's a new installation. And I'm building jdk on Solaris for the > first time. > as is absent in /opt/solarisstudio12.3/bin. > > dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin > CC cscope er_bit f90 rtc_patch_area sunf90 > CCadmin ctc er_cp f95 rxm sunf95 > amd64 ctcr er_export fbe rxs sunstudio > analyzer ctrace er_generic fdumpmod smctl tcov > bcheck cxref er_html fpp solstudio tha > binopt dbx er_kernel fpr spot uncover > c++filt dbxtool er_mpipp fsplit spot_diff version > c89 dem er_mv gen_custom > ss_attach whatdir > c99 discover er_otfdump getmsg sunCC xprof_atob > cb dlight er_print indent sunas xprof_btoa > cc dmake er_rm lint sunc89 > cc-5.0 dumpstabs er_src lock_lint sunc99 > cflow dwarfdump er_vtunify ptclean suncc > collect er_archive f77 ripc sunf77 > > Should it be there? No it is in a separate package apparently (not installed by default on Solaris 11): pkg install pkg:/developer/assembler David ----- > > >>> dev at solaris1:/jdk9/client$ >>> >>> >>>> >>>>> >>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>>>> programs >>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>> >>>>> >>>>> >>>> >>> >> > From mikael.gerdin at oracle.com Tue Jun 2 10:25:04 2015 From: mikael.gerdin at oracle.com (Mikael Gerdin) Date: Tue, 02 Jun 2015 12:25:04 +0200 Subject: Solaris jdk9 build problem In-Reply-To: <556D8039.3000400@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> Message-ID: <556D8480.3090208@oracle.com> On 2015-06-02 12:06, Magnus Ihse Bursie wrote: > On 2015-06-02 11:25, Semyon Sadetsky wrote: >> >> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>> Hello, >>>>>> >>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>> >>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>> gmake[8]: Leaving directory >>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>> >>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>> gmake[7]: Leaving directory >>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>> >>>>>> >>>>>> >>>>>> and earlier in the log: >>>>>> >>>>>> Assembling >>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>> rm -f solaris_x86_64.o >>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>> /usr/bin/bash: -o: command not found >>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>> rm -f space.o >>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>> ... >>>>>> >>>>>> >>>>>> I guess there should be cc before xarch, but it's omited. >>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>>> value of AS? >>>>> >>>>> /Magnus >>>>> >>>> Yes, AS was empty. >>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>> message has gone but then I got: >>> You cannot set it manually. If configure has failed to detect it, all >>> bets are off. I'm a bit surprised that configure allowed AS to be >>> empty, it should have aborted. >>> >>> Try running configure with >>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help you >>> get a proper value of AS. >>> >>> /Magnus >> >> AS remains empty: >> ==================================================== >> A new configuration has been successfully created in >> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >> using configure arguments '--enable-debug >> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >> >> Configuration summary: >> * Debug level: fastdebug >> * HS debug level: fastdebug >> * JDK variant: normal >> * JVM variants: server >> * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 64 >> >> Tools summary: >> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >> * Toolchain: solstudio (Oracle Solaris Studio) >> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >> >> Build performance summary: >> * Cores to use: 2 >> * Memory limit: 2048 MB >> >> dev at solaris1:/jdk9/client$ grep "AS:" >> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >> AS:= > > Do you have an as in your path or in /opt/solarisstudio12.3/bin then? > Have you even built jdk successfully on this machine? I don't think the assembler is part of Solaris Studio, on S11 it's part of the 'devleoper/assembler' package and installed as /usr/bin/as. $ pkg contents developer/assembler PATH usr/bin/as /Mikael > > /Magnus > >> dev at solaris1:/jdk9/client$ >> >> >>> >>>> >>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>>> programs >>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>> gmake[8]: *** Waiting for unfinished jobs.... >>>> >>>> >>>> >>> >> > > From david.holmes at oracle.com Tue Jun 2 10:27:19 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 20:27:19 +1000 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D8403.8040905@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> Message-ID: <556D8507.304@oracle.com> On 2/06/2015 8:22 PM, Magnus Ihse Bursie wrote: > On 2015-06-02 11:57, David Holmes wrote: >> On 2/06/2015 6:58 PM, Magnus Ihse Bursie wrote: >>> On 2015-06-01 19:23, Bertrand Delsart wrote: >>>> Hi all, >>>> >>>> A small open webrev to fix some issues around >>>> --disable-warnings-as-errors (this is not a full cleanup): >>>> >>>> http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ >>>> >>>> Without the fix, -Werror is used to compiled native JDK libraries even >>>> when the --disable-warnings-as-errors is used. >>>> >>>> A lot of these libs are addressed by clearing >>>> CFLAGS_WARNINGS_ARE_ERRORS in flags.m4 >>>> >>>> Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. >>>> Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the >>>> mechanism put in place in that file to disable -Werror and control it >>>> through the WARNINGS_AS_ERRORS configured value. >>> I think this patch will require some work to be OK. >>> >>> First of all, I'm not quite sure I understand what problem you are >>> trying to solve. What libraries are compiled with -Werror when >>> --disable-warnings-as-errors is used? This should not be the case, and I >>> cannot reproduce it on my system. >>> >>> CFLAGS_WARNINGS_ARE_ERRORS should never be cleared, since that is only >>> exported as the mechanism to use for enabling warnings as errors. If no >>> compilation includes it (which it should not if warnings-as-errors are >>> disabled), it won't affect the build. If CFLAGS_WARNINGS_ARE_ERRORS are >>> used even though warnings-as-errors are disabled, then it is this usage >>> that should be fixed. >> >> AFAICS most uses of CFLAGS_WARNINGS_ARE_ERRORS are unconditional eg: >> >> $(eval $(call SetupNativeCompilation,BUILD_LIBINSTRUMENT, \ >> LIBRARY := instrument, \ >> OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ >> SRC := $(LIBINSTRUMENT_SRC), \ >> OPTIMIZATION := LOW, \ >> CFLAGS := $(LIBINSTRUMENT_CFLAGS) $(CFLAGS_WARNINGS_ARE_ERRORS), \ >> >> So clearing it is the simplest way to avoid it being applied. > > Ah, I see. It might be the simplest but it's not correct. :-) Arguably, > these cases should have been removed when the global warnings-as-errors > functionality was introduced. > > I count to 9 instances (including the incorrect usage in > Lib-jdk.jdwp.agent.gmk) of excplicitely hard-coding > CFLAGS_WARNINGS_ARE_ERRORS: > make/lib/Lib-jdk.jdi.gmk: CFLAGS := $(CFLAGS_JDKLIB) > $(CFLAGS_WARNINGS_ARE_ERRORS) -DUSE_MMAP \ > make/lib/Lib-jdk.hprof.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) > $(CFLAGS_WARNINGS_ARE_ERRORS) \ > make/lib/Lib-jdk.hprof.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) > $(CFLAGS_WARNINGS_ARE_ERRORS) \ > make/lib/Lib-java.instrument.gmk: CFLAGS := $(LIBINSTRUMENT_CFLAGS) > $(CFLAGS_WARNINGS_ARE_ERRORS), \ > make/lib/Lib-jdk.management.gmk: CFLAGS := $(CFLAGS_JDKLIB) > $(CFLAGS_WARNINGS_ARE_ERRORS) $(LIBMANAGEMENT_EXT_CFLAGS), \ > make/lib/Lib-jdk.attach.gmk: CFLAGS := $(CFLAGS_JDKLIB) > $(CFLAGS_WARNINGS_ARE_ERRORS) \ > make/lib/Lib-jdk.jdwp.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) > $(CFLAGS_CFLAGS_WARNINGS_ARE_ERRORS) -DUSE_MMAP \ > make/lib/Lib-jdk.jdwp.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) > $(CFLAGS_WARNINGS_ARE_ERRORS) -DJDWP_LOGGING \ > make/lib/Lib-java.management.gmk: CFLAGS := $(CFLAGS_JDKLIB) > $(CFLAGS_WARNINGS_ARE_ERRORS) $(LIBMANAGEMENT_CFLAGS), \ > > These should be removed instead. Okay but I don't think it reasonable to expect Bertrand to make such changes. In the interest of moving forward can we use his current patch and file a follow up bug to get this done properly by the build team? Thanks, David ----- > I also checked for -Werror in the code, but could only find the already > discovered location in Lib-jdk.sctp.gmk. For that, I believe the proper > solution is: > diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk > --- a/make/lib/Lib-jdk.sctp.gmk > +++ b/make/lib/Lib-jdk.sctp.gmk > @@ -30,12 +30,8 @@ > ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) > > ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) > - > - # Suppress unused parameters required by exported JNI functions. > - SCTP_WERROR := -Werror -Wno-error=unused-parameter > - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) > - SCTP_WERROR := > - endif > + # DISABLED_WARNINGS_gcc := unusused-parameter needed to > + # suppress unused parameters required by exported JNI functions. > > $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ > LIBRARY := sctp, \ > @@ -49,7 +45,7 @@ > $(LIBJAVA_HEADER_FLAGS) \ > -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ > -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ > - CFLAGS_linux := $(SCTP_WERROR), \ > + DISABLED_WARNINGS_gcc := unusused-parameter, \ > MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ > LDFLAGS := $(LDFLAGS_JDKLIB) \ > $(call SET_SHARED_LIBRARY_ORIGIN), \ > > > However, as I said, it should probably be verified that it is correct > that the unused-parameter warning is still triggered. > > /Magnus > > > >> >> David >> ----- >> >> >> >>> I can see that libsctp is a special case that hard-codes -Werror. But in >>> this case we should remove the hard-coding and relying on the system >>> setting. This is probably a remnant from before the overall -Werror >>> usage, where the authors of a specific lib wanted to enforce a higher >>> standard. Also, it might be worth revisiting if >>> -Wno-error=unused-parameter is really needed. These things tend to >>> bit-rot. >>> >>> /Magnus >>> >>>> >>>> Best regards, >>>> >>>> Bertrand. >>>> >>> > From semyon.sadetsky at oracle.com Tue Jun 2 10:30:19 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 13:30:19 +0300 Subject: Solaris jdk9 build problem In-Reply-To: <556D830D.6060200@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D82A6.7040107@oracle.com> <556D830D.6060200@oracle.com> Message-ID: <556D85BB.8050708@oracle.com> That helped. Thank you! --Semyon On 6/2/2015 1:18 PM, Erik Joelsson wrote: > Or no, I wrote too fast. The assembler 'as' is part of Solaris and not > Solaris Studio. You need to install the correct package to get it in > /usr/bin/as. > > /Erik > > On 2015-06-02 12:17, Erik Joelsson wrote: >> When I build on Solaris, configure finds 'as' in the Solaris Studio >> bin dir. >> >> /Erik >> >> On 2015-06-02 12:12, Semyon Sadetsky wrote: >>> >>> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>>> >>>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>>> >>>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>>> gmake[8]: Leaving directory >>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>>> gmake[7]: Leaving directory >>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>> >>>>>>>>> >>>>>>>>> and earlier in the log: >>>>>>>>> >>>>>>>>> Assembling >>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>> rm -f solaris_x86_64.o >>>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>>> rm -f space.o >>>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>>> ... >>>>>>>>> >>>>>>>>> >>>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for >>>>>>>> the value of AS? >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>> Yes, AS was empty. >>>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>>> message has gone but then I got: >>>>>> You cannot set it manually. If configure has failed to detect it, >>>>>> all bets are off. I'm a bit surprised that configure allowed AS >>>>>> to be empty, it should have aborted. >>>>>> >>>>>> Try running configure with >>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help >>>>>> you get a proper value of AS. >>>>>> >>>>>> /Magnus >>>>> >>>>> AS remains empty: >>>>> ==================================================== >>>>> A new configuration has been successfully created in >>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>>> using configure arguments '--enable-debug >>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>>> >>>>> Configuration summary: >>>>> * Debug level: fastdebug >>>>> * HS debug level: fastdebug >>>>> * JDK variant: normal >>>>> * JVM variants: server >>>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>>> length: 64 >>>>> >>>>> Tools summary: >>>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>>> >>>>> Build performance summary: >>>>> * Cores to use: 2 >>>>> * Memory limit: 2048 MB >>>>> >>>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>>> AS:= >>>> >>>> Do you have an as in your path or in /opt/solarisstudio12.3/bin >>>> then? Have you even built jdk successfully on this machine? >>>> >>>> /Magnus >>>> >>> No it's a new installation. And I'm building jdk on Solaris for the >>> first time. >>> as is absent in /opt/solarisstudio12.3/bin. >>> >>> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >>> CC cscope er_bit f90 rtc_patch_area >>> sunf90 >>> CCadmin ctc er_cp f95 rxm >>> sunf95 >>> amd64 ctcr er_export fbe rxs >>> sunstudio >>> analyzer ctrace er_generic fdumpmod >>> smctl tcov >>> bcheck cxref er_html fpp solstudio tha >>> binopt dbx er_kernel fpr spot >>> uncover >>> c++filt dbxtool er_mpipp fsplit >>> spot_diff version >>> c89 dem er_mv gen_custom >>> ss_attach whatdir >>> c99 discover er_otfdump getmsg >>> sunCC xprof_atob >>> cb dlight er_print indent >>> sunas xprof_btoa >>> cc dmake er_rm lint sunc89 >>> cc-5.0 dumpstabs er_src lock_lint sunc99 >>> cflow dwarfdump er_vtunify ptclean suncc >>> collect er_archive f77 ripc sunf77 >>> >>> Should it be there? >>> >>> >>> >>>>> dev at solaris1:/jdk9/client$ >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create >>>>>>> 64-bit programs >>>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Tue Jun 2 10:33:21 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 12:33:21 +0200 Subject: Solaris jdk9 build problem In-Reply-To: <556D83D7.5020206@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D83D7.5020206@oracle.com> Message-ID: <556D8671.4070501@oracle.com> On 2015-06-02 12:22, David Holmes wrote: > On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: >> >> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>> >>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>> Hello, >>>>>>>> >>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>> >>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>> gmake[8]: Leaving directory >>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>> >>>>>>>> >>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>> gmake[7]: Leaving directory >>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> and earlier in the log: >>>>>>>> >>>>>>>> Assembling >>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>> rm -f solaris_x86_64.o >>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>> rm -f space.o >>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>> ... >>>>>>>> >>>>>>>> >>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>>>>> value of AS? >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>> Yes, AS was empty. >>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>> message has gone but then I got: >>>>> You cannot set it manually. If configure has failed to detect it, >>>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>>> be empty, it should have aborted. >>>>> >>>>> Try running configure with >>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help you >>>>> get a proper value of AS. >>>>> >>>>> /Magnus >>>> >>>> AS remains empty: >>>> ==================================================== >>>> A new configuration has been successfully created in >>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>> using configure arguments '--enable-debug >>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>> >>>> Configuration summary: >>>> * Debug level: fastdebug >>>> * HS debug level: fastdebug >>>> * JDK variant: normal >>>> * JVM variants: server >>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>> length: 64 >>>> >>>> Tools summary: >>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>> >>>> Build performance summary: >>>> * Cores to use: 2 >>>> * Memory limit: 2048 MB >>>> >>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>> AS:= >>> >>> Do you have an as in your path or in /opt/solarisstudio12.3/bin then? >>> Have you even built jdk successfully on this machine? >>> >>> /Magnus >>> >> No it's a new installation. And I'm building jdk on Solaris for the >> first time. >> as is absent in /opt/solarisstudio12.3/bin. >> >> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >> CC cscope er_bit f90 rtc_patch_area >> sunf90 >> CCadmin ctc er_cp f95 rxm >> sunf95 >> amd64 ctcr er_export fbe rxs sunstudio >> analyzer ctrace er_generic fdumpmod smctl tcov >> bcheck cxref er_html fpp solstudio tha >> binopt dbx er_kernel fpr spot >> uncover >> c++filt dbxtool er_mpipp fsplit spot_diff version >> c89 dem er_mv gen_custom >> ss_attach whatdir >> c99 discover er_otfdump getmsg sunCC xprof_atob >> cb dlight er_print indent sunas xprof_btoa >> cc dmake er_rm lint sunc89 >> cc-5.0 dumpstabs er_src lock_lint sunc99 >> cflow dwarfdump er_vtunify ptclean suncc >> collect er_archive f77 ripc sunf77 >> >> Should it be there? > > No it is in a separate package apparently (not installed by default on > Solaris 11): > > pkg install pkg:/developer/assembler Thanks for the information David! I opened https://bugs.openjdk.java.net/browse/JDK-8081676 to track that we should verify that AS is properly detected on Solaris, and to print the help about pkg install in case as is missing. /Magnus > > David > ----- > >> >> >>>> dev at solaris1:/jdk9/client$ >>>> >>>> >>>>> >>>>>> >>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>>>>> programs >>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >> From bertrand.delsart at oracle.com Tue Jun 2 10:33:37 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 02 Jun 2015 12:33:37 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D8507.304@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> <556D8507.304@oracle.com> Message-ID: <556D8681.30600@oracle.com> On 02/06/2015 12:27, David Holmes wrote: > On 2/06/2015 8:22 PM, Magnus Ihse Bursie wrote: >> On 2015-06-02 11:57, David Holmes wrote: >>> On 2/06/2015 6:58 PM, Magnus Ihse Bursie wrote: >>>> On 2015-06-01 19:23, Bertrand Delsart wrote: >>>>> Hi all, >>>>> >>>>> A small open webrev to fix some issues around >>>>> --disable-warnings-as-errors (this is not a full cleanup): >>>>> >>>>> http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ >>>>> >>>>> Without the fix, -Werror is used to compiled native JDK libraries even >>>>> when the --disable-warnings-as-errors is used. >>>>> >>>>> A lot of these libs are addressed by clearing >>>>> CFLAGS_WARNINGS_ARE_ERRORS in flags.m4 >>>>> >>>>> Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. >>>>> Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use the >>>>> mechanism put in place in that file to disable -Werror and control it >>>>> through the WARNINGS_AS_ERRORS configured value. >>>> I think this patch will require some work to be OK. >>>> >>>> First of all, I'm not quite sure I understand what problem you are >>>> trying to solve. What libraries are compiled with -Werror when >>>> --disable-warnings-as-errors is used? This should not be the case, >>>> and I >>>> cannot reproduce it on my system. >>>> >>>> CFLAGS_WARNINGS_ARE_ERRORS should never be cleared, since that is only >>>> exported as the mechanism to use for enabling warnings as errors. If no >>>> compilation includes it (which it should not if warnings-as-errors are >>>> disabled), it won't affect the build. If CFLAGS_WARNINGS_ARE_ERRORS are >>>> used even though warnings-as-errors are disabled, then it is this usage >>>> that should be fixed. >>> >>> AFAICS most uses of CFLAGS_WARNINGS_ARE_ERRORS are unconditional eg: >>> >>> $(eval $(call SetupNativeCompilation,BUILD_LIBINSTRUMENT, \ >>> LIBRARY := instrument, \ >>> OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ >>> SRC := $(LIBINSTRUMENT_SRC), \ >>> OPTIMIZATION := LOW, \ >>> CFLAGS := $(LIBINSTRUMENT_CFLAGS) $(CFLAGS_WARNINGS_ARE_ERRORS), \ >>> >>> So clearing it is the simplest way to avoid it being applied. >> >> Ah, I see. It might be the simplest but it's not correct. :-) Arguably, >> these cases should have been removed when the global warnings-as-errors >> functionality was introduced. >> >> I count to 9 instances (including the incorrect usage in >> Lib-jdk.jdwp.agent.gmk) of excplicitely hard-coding >> CFLAGS_WARNINGS_ARE_ERRORS: >> make/lib/Lib-jdk.jdi.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) -DUSE_MMAP \ >> make/lib/Lib-jdk.hprof.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) \ >> make/lib/Lib-jdk.hprof.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) \ >> make/lib/Lib-java.instrument.gmk: CFLAGS := $(LIBINSTRUMENT_CFLAGS) >> $(CFLAGS_WARNINGS_ARE_ERRORS), \ >> make/lib/Lib-jdk.management.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) $(LIBMANAGEMENT_EXT_CFLAGS), \ >> make/lib/Lib-jdk.attach.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) \ >> make/lib/Lib-jdk.jdwp.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_CFLAGS_WARNINGS_ARE_ERRORS) -DUSE_MMAP \ >> make/lib/Lib-jdk.jdwp.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) -DJDWP_LOGGING \ >> make/lib/Lib-java.management.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) $(LIBMANAGEMENT_CFLAGS), \ >> >> These should be removed instead. > > Okay but I don't think it reasonable to expect Bertrand to make such > changes. In the interest of moving forward can we use his current patch > and file a follow up bug to get this done properly by the build team? Thanks David, I had written an answer but yours is more to the point :-) Stated differently, is there any issue with my proposed fixes except the fact that, while sufficient for our current issue, it does not fully clean up what started to bit-rot ? Do I need extra reviewers from the build-team ? Regards, Bertrand. > > Thanks, > David > ----- > >> I also checked for -Werror in the code, but could only find the already >> discovered location in Lib-jdk.sctp.gmk. For that, I believe the proper >> solution is: >> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >> --- a/make/lib/Lib-jdk.sctp.gmk >> +++ b/make/lib/Lib-jdk.sctp.gmk >> @@ -30,12 +30,8 @@ >> ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) >> >> ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) >> - >> - # Suppress unused parameters required by exported JNI functions. >> - SCTP_WERROR := -Werror -Wno-error=unused-parameter >> - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >> - SCTP_WERROR := >> - endif >> + # DISABLED_WARNINGS_gcc := unusused-parameter needed to >> + # suppress unused parameters required by exported JNI functions. >> >> $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ >> LIBRARY := sctp, \ >> @@ -49,7 +45,7 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >> - CFLAGS_linux := $(SCTP_WERROR), \ >> + DISABLED_WARNINGS_gcc := unusused-parameter, \ >> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >> LDFLAGS := $(LDFLAGS_JDKLIB) \ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> >> >> However, as I said, it should probably be verified that it is correct >> that the unused-parameter warning is still triggered. >> >> /Magnus >> >> >> >>> >>> David >>> ----- >>> >>> >>> >>>> I can see that libsctp is a special case that hard-codes -Werror. >>>> But in >>>> this case we should remove the hard-coding and relying on the system >>>> setting. This is probably a remnant from before the overall -Werror >>>> usage, where the authors of a specific lib wanted to enforce a higher >>>> standard. Also, it might be worth revisiting if >>>> -Wno-error=unused-parameter is really needed. These things tend to >>>> bit-rot. >>>> >>>> /Magnus >>>> >>>>> >>>>> Best regards, >>>>> >>>>> Bertrand. >>>>> >>>> >> -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From magnus.ihse.bursie at oracle.com Tue Jun 2 10:35:04 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 12:35:04 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D8507.304@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> <556D8507.304@oracle.com> Message-ID: <556D86D8.8090702@oracle.com> On 2015-06-02 12:27, David Holmes wrote: > On 2/06/2015 8:22 PM, Magnus Ihse Bursie wrote: >> On 2015-06-02 11:57, David Holmes wrote: >>> On 2/06/2015 6:58 PM, Magnus Ihse Bursie wrote: >>>> On 2015-06-01 19:23, Bertrand Delsart wrote: >>>>> Hi all, >>>>> >>>>> A small open webrev to fix some issues around >>>>> --disable-warnings-as-errors (this is not a full cleanup): >>>>> >>>>> http://cr.openjdk.java.net/~bdelsart/8081616/webrev.00/webrev/ >>>>> >>>>> Without the fix, -Werror is used to compiled native JDK libraries >>>>> even >>>>> when the --disable-warnings-as-errors is used. >>>>> >>>>> A lot of these libs are addressed by clearing >>>>> CFLAGS_WARNINGS_ARE_ERRORS in flags.m4 >>>>> >>>>> Lib-jdk.sctp.gmk is a special case because it uses directly -Werror. >>>>> Instead of modifying SCTP to use CFLAGS_WARNINGS_ARE_ERRORS, I use >>>>> the >>>>> mechanism put in place in that file to disable -Werror and control it >>>>> through the WARNINGS_AS_ERRORS configured value. >>>> I think this patch will require some work to be OK. >>>> >>>> First of all, I'm not quite sure I understand what problem you are >>>> trying to solve. What libraries are compiled with -Werror when >>>> --disable-warnings-as-errors is used? This should not be the case, >>>> and I >>>> cannot reproduce it on my system. >>>> >>>> CFLAGS_WARNINGS_ARE_ERRORS should never be cleared, since that is only >>>> exported as the mechanism to use for enabling warnings as errors. >>>> If no >>>> compilation includes it (which it should not if warnings-as-errors are >>>> disabled), it won't affect the build. If CFLAGS_WARNINGS_ARE_ERRORS >>>> are >>>> used even though warnings-as-errors are disabled, then it is this >>>> usage >>>> that should be fixed. >>> >>> AFAICS most uses of CFLAGS_WARNINGS_ARE_ERRORS are unconditional eg: >>> >>> $(eval $(call SetupNativeCompilation,BUILD_LIBINSTRUMENT, \ >>> LIBRARY := instrument, \ >>> OUTPUT_DIR := $(INSTALL_LIBRARIES_HERE), \ >>> SRC := $(LIBINSTRUMENT_SRC), \ >>> OPTIMIZATION := LOW, \ >>> CFLAGS := $(LIBINSTRUMENT_CFLAGS) $(CFLAGS_WARNINGS_ARE_ERRORS), \ >>> >>> So clearing it is the simplest way to avoid it being applied. >> >> Ah, I see. It might be the simplest but it's not correct. :-) Arguably, >> these cases should have been removed when the global warnings-as-errors >> functionality was introduced. >> >> I count to 9 instances (including the incorrect usage in >> Lib-jdk.jdwp.agent.gmk) of excplicitely hard-coding >> CFLAGS_WARNINGS_ARE_ERRORS: >> make/lib/Lib-jdk.jdi.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) -DUSE_MMAP \ >> make/lib/Lib-jdk.hprof.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) \ >> make/lib/Lib-jdk.hprof.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) \ >> make/lib/Lib-java.instrument.gmk: CFLAGS := $(LIBINSTRUMENT_CFLAGS) >> $(CFLAGS_WARNINGS_ARE_ERRORS), \ >> make/lib/Lib-jdk.management.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) $(LIBMANAGEMENT_EXT_CFLAGS), \ >> make/lib/Lib-jdk.attach.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) \ >> make/lib/Lib-jdk.jdwp.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_CFLAGS_WARNINGS_ARE_ERRORS) -DUSE_MMAP \ >> make/lib/Lib-jdk.jdwp.agent.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) -DJDWP_LOGGING \ >> make/lib/Lib-java.management.gmk: CFLAGS := $(CFLAGS_JDKLIB) >> $(CFLAGS_WARNINGS_ARE_ERRORS) $(LIBMANAGEMENT_CFLAGS), \ >> >> These should be removed instead. > > Okay but I don't think it reasonable to expect Bertrand to make such > changes. In the interest of moving forward can we use his current > patch and file a follow up bug to get this done properly by the build > team? It's not worth the trouble to put in bad code just to rip it out. I'll have the patch done in five minutes, brb. :) /Magnus > > Thanks, > David > ----- > >> I also checked for -Werror in the code, but could only find the already >> discovered location in Lib-jdk.sctp.gmk. For that, I believe the proper >> solution is: >> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >> --- a/make/lib/Lib-jdk.sctp.gmk >> +++ b/make/lib/Lib-jdk.sctp.gmk >> @@ -30,12 +30,8 @@ >> ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) >> >> ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) >> - >> - # Suppress unused parameters required by exported JNI functions. >> - SCTP_WERROR := -Werror -Wno-error=unused-parameter >> - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >> - SCTP_WERROR := >> - endif >> + # DISABLED_WARNINGS_gcc := unusused-parameter needed to >> + # suppress unused parameters required by exported JNI functions. >> >> $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ >> LIBRARY := sctp, \ >> @@ -49,7 +45,7 @@ >> $(LIBJAVA_HEADER_FLAGS) \ >> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >> - CFLAGS_linux := $(SCTP_WERROR), \ >> + DISABLED_WARNINGS_gcc := unusused-parameter, \ >> MAPFILE := $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >> LDFLAGS := $(LDFLAGS_JDKLIB) \ >> $(call SET_SHARED_LIBRARY_ORIGIN), \ >> >> >> However, as I said, it should probably be verified that it is correct >> that the unused-parameter warning is still triggered. >> >> /Magnus >> >> >> >>> >>> David >>> ----- >>> >>> >>> >>>> I can see that libsctp is a special case that hard-codes -Werror. >>>> But in >>>> this case we should remove the hard-coding and relying on the system >>>> setting. This is probably a remnant from before the overall -Werror >>>> usage, where the authors of a specific lib wanted to enforce a higher >>>> standard. Also, it might be worth revisiting if >>>> -Wno-error=unused-parameter is really needed. These things tend to >>>> bit-rot. >>>> >>>> /Magnus >>>> >>>>> >>>>> Best regards, >>>>> >>>>> Bertrand. >>>>> >>>> >> From david.holmes at oracle.com Tue Jun 2 10:33:33 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 20:33:33 +1000 Subject: Solaris jdk9 build problem In-Reply-To: <556D8671.4070501@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D83D7.5020206@oracle.com> <556D8671.4070501@oracle.com> Message-ID: <556D867D.3060605@oracle.com> On 2/06/2015 8:33 PM, Magnus Ihse Bursie wrote: > On 2015-06-02 12:22, David Holmes wrote: >> On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: >>> >>> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>>> >>>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>>> >>>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>>> gmake[8]: Leaving directory >>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>> >>>>>>>>> >>>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>>> gmake[7]: Leaving directory >>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> and earlier in the log: >>>>>>>>> >>>>>>>>> Assembling >>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>> rm -f solaris_x86_64.o >>>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>>> rm -f space.o >>>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>>> ... >>>>>>>>> >>>>>>>>> >>>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>>>>>> value of AS? >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>> Yes, AS was empty. >>>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>>> message has gone but then I got: >>>>>> You cannot set it manually. If configure has failed to detect it, >>>>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>>>> be empty, it should have aborted. >>>>>> >>>>>> Try running configure with >>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help you >>>>>> get a proper value of AS. >>>>>> >>>>>> /Magnus >>>>> >>>>> AS remains empty: >>>>> ==================================================== >>>>> A new configuration has been successfully created in >>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>>> using configure arguments '--enable-debug >>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>>> >>>>> Configuration summary: >>>>> * Debug level: fastdebug >>>>> * HS debug level: fastdebug >>>>> * JDK variant: normal >>>>> * JVM variants: server >>>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>>> length: 64 >>>>> >>>>> Tools summary: >>>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>>> >>>>> Build performance summary: >>>>> * Cores to use: 2 >>>>> * Memory limit: 2048 MB >>>>> >>>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>>> AS:= >>>> >>>> Do you have an as in your path or in /opt/solarisstudio12.3/bin then? >>>> Have you even built jdk successfully on this machine? >>>> >>>> /Magnus >>>> >>> No it's a new installation. And I'm building jdk on Solaris for the >>> first time. >>> as is absent in /opt/solarisstudio12.3/bin. >>> >>> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >>> CC cscope er_bit f90 rtc_patch_area >>> sunf90 >>> CCadmin ctc er_cp f95 rxm sunf95 >>> amd64 ctcr er_export fbe rxs sunstudio >>> analyzer ctrace er_generic fdumpmod smctl tcov >>> bcheck cxref er_html fpp solstudio tha >>> binopt dbx er_kernel fpr spot uncover >>> c++filt dbxtool er_mpipp fsplit spot_diff version >>> c89 dem er_mv gen_custom >>> ss_attach whatdir >>> c99 discover er_otfdump getmsg sunCC xprof_atob >>> cb dlight er_print indent sunas xprof_btoa >>> cc dmake er_rm lint sunc89 >>> cc-5.0 dumpstabs er_src lock_lint sunc99 >>> cflow dwarfdump er_vtunify ptclean suncc >>> collect er_archive f77 ripc sunf77 >>> >>> Should it be there? >> >> No it is in a separate package apparently (not installed by default on >> Solaris 11): >> >> pkg install pkg:/developer/assembler > > Thanks for the information David! > > I opened https://bugs.openjdk.java.net/browse/JDK-8081676 to track that > we should verify that AS is properly detected on Solaris, and to print > the help about pkg install in case as is missing. FYI it looks like it was installed by default on S10 as part of /usr/ccs/bin, but needs the separate install on S11. Do we bundle it with devkits or rely on it being installed locally? Cheers, David > /Magnus > >> >> David >> ----- >> >>> >>> >>>>> dev at solaris1:/jdk9/client$ >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>>>>>> programs >>>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From semyon.sadetsky at oracle.com Tue Jun 2 10:40:50 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 13:40:50 +0300 Subject: Solaris jdk9 build problem In-Reply-To: <556D8671.4070501@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D83D7.5020206@oracle.com> <556D8671.4070501@oracle.com> Message-ID: <556D8832.8090508@oracle.com> On 6/2/2015 1:33 PM, Magnus Ihse Bursie wrote: > On 2015-06-02 12:22, David Holmes wrote: >> On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: >>> >>> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>>> >>>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>>> >>>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>>> gmake[8]: Leaving directory >>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>> >>>>>>>>> >>>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>>> gmake[7]: Leaving directory >>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> and earlier in the log: >>>>>>>>> >>>>>>>>> Assembling >>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>> rm -f solaris_x86_64.o >>>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>>> rm -f space.o >>>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>>> ... >>>>>>>>> >>>>>>>>> >>>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>>>>>> value of AS? >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>> Yes, AS was empty. >>>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>>> message has gone but then I got: >>>>>> You cannot set it manually. If configure has failed to detect it, >>>>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>>>> be empty, it should have aborted. >>>>>> >>>>>> Try running configure with >>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help you >>>>>> get a proper value of AS. >>>>>> >>>>>> /Magnus >>>>> >>>>> AS remains empty: >>>>> ==================================================== >>>>> A new configuration has been successfully created in >>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>>> using configure arguments '--enable-debug >>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>>> >>>>> Configuration summary: >>>>> * Debug level: fastdebug >>>>> * HS debug level: fastdebug >>>>> * JDK variant: normal >>>>> * JVM variants: server >>>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>>> length: 64 >>>>> >>>>> Tools summary: >>>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>>> >>>>> Build performance summary: >>>>> * Cores to use: 2 >>>>> * Memory limit: 2048 MB >>>>> >>>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>>> AS:= >>>> >>>> Do you have an as in your path or in /opt/solarisstudio12.3/bin then? >>>> Have you even built jdk successfully on this machine? >>>> >>>> /Magnus >>>> >>> No it's a new installation. And I'm building jdk on Solaris for the >>> first time. >>> as is absent in /opt/solarisstudio12.3/bin. >>> >>> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >>> CC cscope er_bit f90 rtc_patch_area >>> sunf90 >>> CCadmin ctc er_cp f95 rxm >>> sunf95 >>> amd64 ctcr er_export fbe rxs sunstudio >>> analyzer ctrace er_generic fdumpmod smctl tcov >>> bcheck cxref er_html fpp solstudio tha >>> binopt dbx er_kernel fpr spot >>> uncover >>> c++filt dbxtool er_mpipp fsplit spot_diff >>> version >>> c89 dem er_mv gen_custom >>> ss_attach whatdir >>> c99 discover er_otfdump getmsg sunCC xprof_atob >>> cb dlight er_print indent sunas xprof_btoa >>> cc dmake er_rm lint sunc89 >>> cc-5.0 dumpstabs er_src lock_lint sunc99 >>> cflow dwarfdump er_vtunify ptclean suncc >>> collect er_archive f77 ripc sunf77 >>> >>> Should it be there? >> >> No it is in a separate package apparently (not installed by default >> on Solaris 11): >> >> pkg install pkg:/developer/assembler > > Thanks for the information David! > > I opened https://bugs.openjdk.java.net/browse/JDK-8081676 to track > that we should verify that AS is properly detected on Solaris, and to > print the help about pkg install in case as is missing. > > /Magnus > Possible it would be worth to add this information to the readme as well. On other linuxes gcc is used instead of as and configure does not produce any warnings about it. It is not trivial to find the reason for people building solaris jdk for the first time. --Semyon >> >> David >> ----- >> >>> >>> >>>>> dev at solaris1:/jdk9/client$ >>>>> >>>>> >>>>>> >>>>>>> >>>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>>>>>> programs >>>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>> > From magnus.ihse.bursie at oracle.com Tue Jun 2 10:45:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 12:45:06 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D86D8.8090702@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> <556D8507.304@oracle.com> <556D86D8.8090702@oracle.com> Message-ID: <556D8932.6090900@oracle.com> On 2015-06-02 12:35, Magnus Ihse Bursie wrote: > On 2015-06-02 12:27, David Holmes wrote: >> These should be removed instead. >> >> Okay but I don't think it reasonable to expect Bertrand to make such >> changes. In the interest of moving forward can we use his current >> patch and file a follow up bug to get this done properly by the build >> team? > It's not worth the trouble to put in bad code just to rip it out. I'll > have the patch done in five minutes, brb. :) Here's the webrev: http://cr.openjdk.java.net/~ihse/JDK-8081616-respect-disable-warnings-as-errors/webrev.01 No top level changes are needed. I kept the disabling of unused-parameter in libsctp for pragmatic reasons. On my computer it compiled fine without it, but it requires more work to determine if it can be removed. /Magnus > > /Magnus > >> >> Thanks, >> David >> ----- >> >>> I also checked for -Werror in the code, but could only find the already >>> discovered location in Lib-jdk.sctp.gmk. For that, I believe the proper >>> solution is: >>> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >>> --- a/make/lib/Lib-jdk.sctp.gmk >>> +++ b/make/lib/Lib-jdk.sctp.gmk >>> @@ -30,12 +30,8 @@ >>> ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) >>> >>> ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) >>> - >>> - # Suppress unused parameters required by exported JNI functions. >>> - SCTP_WERROR := -Werror -Wno-error=unused-parameter >>> - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >>> - SCTP_WERROR := >>> - endif >>> + # DISABLED_WARNINGS_gcc := unusused-parameter needed to >>> + # suppress unused parameters required by exported JNI functions. >>> >>> $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ >>> LIBRARY := sctp, \ >>> @@ -49,7 +45,7 @@ >>> $(LIBJAVA_HEADER_FLAGS) \ >>> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >>> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >>> - CFLAGS_linux := $(SCTP_WERROR), \ >>> + DISABLED_WARNINGS_gcc := unusused-parameter, \ >>> MAPFILE := >>> $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>> >>> >>> However, as I said, it should probably be verified that it is correct >>> that the unused-parameter warning is still triggered. >>> >>> /Magnus >>> >>> >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>> >>>>> I can see that libsctp is a special case that hard-codes -Werror. >>>>> But in >>>>> this case we should remove the hard-coding and relying on the system >>>>> setting. This is probably a remnant from before the overall -Werror >>>>> usage, where the authors of a specific lib wanted to enforce a higher >>>>> standard. Also, it might be worth revisiting if >>>>> -Wno-error=unused-parameter is really needed. These things tend to >>>>> bit-rot. >>>>> >>>>> /Magnus >>>>> >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Bertrand. >>>>>> >>>>> >>> > From david.holmes at oracle.com Tue Jun 2 11:29:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 21:29:52 +1000 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D8932.6090900@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> <556D8507.304@oracle.com> <556D86D8.8090702@oracle.com> <556D8932.6090900@oracle.com> Message-ID: <556D93B0.9050805@oracle.com> On 2/06/2015 8:45 PM, Magnus Ihse Bursie wrote: > On 2015-06-02 12:35, Magnus Ihse Bursie wrote: >> On 2015-06-02 12:27, David Holmes wrote: >>> These should be removed instead. >>> >>> Okay but I don't think it reasonable to expect Bertrand to make such >>> changes. In the interest of moving forward can we use his current >>> patch and file a follow up bug to get this done properly by the build >>> team? >> It's not worth the trouble to put in bad code just to rip it out. I'll >> have the patch done in five minutes, brb. :) > > Here's the webrev: > http://cr.openjdk.java.net/~ihse/JDK-8081616-respect-disable-warnings-as-errors/webrev.01 > > > No top level changes are needed. I kept the disabling of > unused-parameter in libsctp for pragmatic reasons. On my computer it > compiled fine without it, but it requires more work to determine if it > can be removed. I'm missing something - where does CFLAGS_WARNINGS_ARE_ERRORS get added in when it is enabled ?? Also we will need to this to go in via hs-rt please (using JPRT). Thanks, David > /Magnus > >> >> /Magnus >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> I also checked for -Werror in the code, but could only find the already >>>> discovered location in Lib-jdk.sctp.gmk. For that, I believe the proper >>>> solution is: >>>> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >>>> --- a/make/lib/Lib-jdk.sctp.gmk >>>> +++ b/make/lib/Lib-jdk.sctp.gmk >>>> @@ -30,12 +30,8 @@ >>>> ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) >>>> >>>> ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) >>>> - >>>> - # Suppress unused parameters required by exported JNI functions. >>>> - SCTP_WERROR := -Werror -Wno-error=unused-parameter >>>> - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >>>> - SCTP_WERROR := >>>> - endif >>>> + # DISABLED_WARNINGS_gcc := unusused-parameter needed to >>>> + # suppress unused parameters required by exported JNI functions. >>>> >>>> $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ >>>> LIBRARY := sctp, \ >>>> @@ -49,7 +45,7 @@ >>>> $(LIBJAVA_HEADER_FLAGS) \ >>>> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >>>> - CFLAGS_linux := $(SCTP_WERROR), \ >>>> + DISABLED_WARNINGS_gcc := unusused-parameter, \ >>>> MAPFILE := >>>> $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>> >>>> >>>> However, as I said, it should probably be verified that it is correct >>>> that the unused-parameter warning is still triggered. >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> >>>>>> I can see that libsctp is a special case that hard-codes -Werror. >>>>>> But in >>>>>> this case we should remove the hard-coding and relying on the system >>>>>> setting. This is probably a remnant from before the overall -Werror >>>>>> usage, where the authors of a specific lib wanted to enforce a higher >>>>>> standard. Also, it might be worth revisiting if >>>>>> -Wno-error=unused-parameter is really needed. These things tend to >>>>>> bit-rot. >>>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Bertrand. >>>>>>> >>>>>> >>>> >> > From erik.joelsson at oracle.com Tue Jun 2 11:46:50 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 02 Jun 2015 13:46:50 +0200 Subject: Solaris jdk9 build problem In-Reply-To: <556D867D.3060605@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D83D7.5020206@oracle.com> <556D8671.4070501@oracle.com> <556D867D.3060605@oracle.com> Message-ID: <556D97AA.2020902@oracle.com> On 2015-06-02 12:33, David Holmes wrote: > On 2/06/2015 8:33 PM, Magnus Ihse Bursie wrote: >> On 2015-06-02 12:22, David Holmes wrote: >>> On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: >>>> >>>> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>>>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>>>> >>>>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>>>> >>>>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>>>> gmake[8]: Leaving directory >>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>>>> gmake[7]: Leaving directory >>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and earlier in the log: >>>>>>>>>> >>>>>>>>>> Assembling >>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>> rm -f solaris_x86_64.o >>>>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>>>> rm -f space.o >>>>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>>>>>>> value of AS? >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>> Yes, AS was empty. >>>>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>>>> message has gone but then I got: >>>>>>> You cannot set it manually. If configure has failed to detect it, >>>>>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>>>>> be empty, it should have aborted. >>>>>>> >>>>>>> Try running configure with >>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help >>>>>>> you >>>>>>> get a proper value of AS. >>>>>>> >>>>>>> /Magnus >>>>>> >>>>>> AS remains empty: >>>>>> ==================================================== >>>>>> A new configuration has been successfully created in >>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>>>> using configure arguments '--enable-debug >>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>>>> >>>>>> Configuration summary: >>>>>> * Debug level: fastdebug >>>>>> * HS debug level: fastdebug >>>>>> * JDK variant: normal >>>>>> * JVM variants: server >>>>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>>>> length: 64 >>>>>> >>>>>> Tools summary: >>>>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>>>> >>>>>> Build performance summary: >>>>>> * Cores to use: 2 >>>>>> * Memory limit: 2048 MB >>>>>> >>>>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>>>> AS:= >>>>> >>>>> Do you have an as in your path or in /opt/solarisstudio12.3/bin then? >>>>> Have you even built jdk successfully on this machine? >>>>> >>>>> /Magnus >>>>> >>>> No it's a new installation. And I'm building jdk on Solaris for the >>>> first time. >>>> as is absent in /opt/solarisstudio12.3/bin. >>>> >>>> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >>>> CC cscope er_bit f90 rtc_patch_area >>>> sunf90 >>>> CCadmin ctc er_cp f95 rxm sunf95 >>>> amd64 ctcr er_export fbe rxs sunstudio >>>> analyzer ctrace er_generic fdumpmod smctl tcov >>>> bcheck cxref er_html fpp solstudio >>>> tha >>>> binopt dbx er_kernel fpr spot uncover >>>> c++filt dbxtool er_mpipp fsplit spot_diff >>>> version >>>> c89 dem er_mv gen_custom >>>> ss_attach whatdir >>>> c99 discover er_otfdump getmsg sunCC >>>> xprof_atob >>>> cb dlight er_print indent sunas >>>> xprof_btoa >>>> cc dmake er_rm lint sunc89 >>>> cc-5.0 dumpstabs er_src lock_lint sunc99 >>>> cflow dwarfdump er_vtunify ptclean suncc >>>> collect er_archive f77 ripc sunf77 >>>> >>>> Should it be there? >>> >>> No it is in a separate package apparently (not installed by default on >>> Solaris 11): >>> >>> pkg install pkg:/developer/assembler >> >> Thanks for the information David! >> >> I opened https://bugs.openjdk.java.net/browse/JDK-8081676 to track that >> we should verify that AS is properly detected on Solaris, and to print >> the help about pkg install in case as is missing. > > FYI it looks like it was installed by default on S10 as part of > /usr/ccs/bin, but needs the separate install on S11. Do we bundle it > with devkits or rely on it being installed locally? > We bundle it with devkits, which is why I first thought it was part of Solaris Studio, until I looked closer. /Erik > Cheers, > David > >> /Magnus >> >>> >>> David >>> ----- >>> >>>> >>>> >>>>>> dev at solaris1:/jdk9/client$ >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>>>>>>> programs >>>>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> From bertrand.delsart at oracle.com Tue Jun 2 11:50:14 2015 From: bertrand.delsart at oracle.com (Bertrand Delsart) Date: Tue, 02 Jun 2015 13:50:14 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D8932.6090900@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> <556D8507.304@oracle.com> <556D86D8.8090702@oracle.com> <556D8932.6090900@oracle.com> Message-ID: <556D9876.1080308@oracle.com> On 02/06/2015 12:45, Magnus Ihse Bursie wrote: > On 2015-06-02 12:35, Magnus Ihse Bursie wrote: >> On 2015-06-02 12:27, David Holmes wrote: >>> These should be removed instead. >>> >>> Okay but I don't think it reasonable to expect Bertrand to make such >>> changes. In the interest of moving forward can we use his current >>> patch and file a follow up bug to get this done properly by the build >>> team? >> It's not worth the trouble to put in bad code just to rip it out. I'll >> have the patch done in five minutes, brb. :) > > Here's the webrev: > http://cr.openjdk.java.net/~ihse/JDK-8081616-respect-disable-warnings-as-errors/webrev.01 > > > No top level changes are needed. I kept the disabling of > unused-parameter in libsctp for pragmatic reasons. On my computer it > compiled fine without it, but it requires more work to determine if it > can be removed. I was shooting for a simple fix, with no cleanup, to reduce regression risks (particularly since I'm not an expert on the new build system). Your fix looks like a good cleanup and should be sufficient to solve my issue... but may have a small side effect. In particular, If I understand correctly, the Werror in Lib-jdk.sctp.gmk was redundant. Hence, on ppc, we were by default compiling with Werror but without -Wno-unused-parameter. With your fix we will now be less strict on PPC, allowing unused parameters. This may not be a big deal since AIX is filtered-out. This would apply only to open linux-ppc ports, if any. Hence, this is probably OK but I'll let you grab the CR and decide whether to push it as is or not. Thanks, Bertrand. > > /Magnus > >> >> /Magnus >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> I also checked for -Werror in the code, but could only find the already >>>> discovered location in Lib-jdk.sctp.gmk. For that, I believe the proper >>>> solution is: >>>> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >>>> --- a/make/lib/Lib-jdk.sctp.gmk >>>> +++ b/make/lib/Lib-jdk.sctp.gmk >>>> @@ -30,12 +30,8 @@ >>>> ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) >>>> >>>> ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) >>>> - >>>> - # Suppress unused parameters required by exported JNI functions. >>>> - SCTP_WERROR := -Werror -Wno-error=unused-parameter >>>> - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >>>> - SCTP_WERROR := >>>> - endif >>>> + # DISABLED_WARNINGS_gcc := unusused-parameter needed to >>>> + # suppress unused parameters required by exported JNI functions. >>>> >>>> $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ >>>> LIBRARY := sctp, \ >>>> @@ -49,7 +45,7 @@ >>>> $(LIBJAVA_HEADER_FLAGS) \ >>>> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >>>> - CFLAGS_linux := $(SCTP_WERROR), \ >>>> + DISABLED_WARNINGS_gcc := unusused-parameter, \ >>>> MAPFILE := >>>> $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>> >>>> >>>> However, as I said, it should probably be verified that it is correct >>>> that the unused-parameter warning is still triggered. >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> >>>>>> I can see that libsctp is a special case that hard-codes -Werror. >>>>>> But in >>>>>> this case we should remove the hard-coding and relying on the system >>>>>> setting. This is probably a remnant from before the overall -Werror >>>>>> usage, where the authors of a specific lib wanted to enforce a higher >>>>>> standard. Also, it might be worth revisiting if >>>>>> -Wno-error=unused-parameter is really needed. These things tend to >>>>>> bit-rot. >>>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Bertrand. >>>>>>> >>>>>> >>>> >> > -- Bertrand Delsart, Grenoble Engineering Center Oracle, 180 av. de l'Europe, ZIRST de Montbonnot 38330 Montbonnot Saint Martin, FRANCE bertrand.delsart at oracle.com Phone : +33 4 76 18 81 23 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ From erik.joelsson at oracle.com Tue Jun 2 12:05:10 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 02 Jun 2015 14:05:10 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D8932.6090900@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> <556D8507.304@oracle.com> <556D86D8.8090702@oracle.com> <556D8932.6090900@oracle.com> Message-ID: <556D9BF6.8050805@oracle.com> Looks good to me. /Erik On 2015-06-02 12:45, Magnus Ihse Bursie wrote: > On 2015-06-02 12:35, Magnus Ihse Bursie wrote: >> On 2015-06-02 12:27, David Holmes wrote: >>> These should be removed instead. >>> >>> Okay but I don't think it reasonable to expect Bertrand to make such >>> changes. In the interest of moving forward can we use his current >>> patch and file a follow up bug to get this done properly by the >>> build team? >> It's not worth the trouble to put in bad code just to rip it out. >> I'll have the patch done in five minutes, brb. :) > > Here's the webrev: > http://cr.openjdk.java.net/~ihse/JDK-8081616-respect-disable-warnings-as-errors/webrev.01 > > > No top level changes are needed. I kept the disabling of > unused-parameter in libsctp for pragmatic reasons. On my computer it > compiled fine without it, but it requires more work to determine if it > can be removed. > > /Magnus > >> >> /Magnus >> >>> >>> Thanks, >>> David >>> ----- >>> >>>> I also checked for -Werror in the code, but could only find the >>>> already >>>> discovered location in Lib-jdk.sctp.gmk. For that, I believe the >>>> proper >>>> solution is: >>>> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >>>> --- a/make/lib/Lib-jdk.sctp.gmk >>>> +++ b/make/lib/Lib-jdk.sctp.gmk >>>> @@ -30,12 +30,8 @@ >>>> ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) >>>> >>>> ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) >>>> - >>>> - # Suppress unused parameters required by exported JNI functions. >>>> - SCTP_WERROR := -Werror -Wno-error=unused-parameter >>>> - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >>>> - SCTP_WERROR := >>>> - endif >>>> + # DISABLED_WARNINGS_gcc := unusused-parameter needed to >>>> + # suppress unused parameters required by exported JNI functions. >>>> >>>> $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ >>>> LIBRARY := sctp, \ >>>> @@ -49,7 +45,7 @@ >>>> $(LIBJAVA_HEADER_FLAGS) \ >>>> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >>>> - CFLAGS_linux := $(SCTP_WERROR), \ >>>> + DISABLED_WARNINGS_gcc := unusused-parameter, \ >>>> MAPFILE := >>>> $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>> >>>> >>>> However, as I said, it should probably be verified that it is correct >>>> that the unused-parameter warning is still triggered. >>>> >>>> /Magnus >>>> >>>> >>>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>> >>>>> >>>>>> I can see that libsctp is a special case that hard-codes -Werror. >>>>>> But in >>>>>> this case we should remove the hard-coding and relying on the system >>>>>> setting. This is probably a remnant from before the overall -Werror >>>>>> usage, where the authors of a specific lib wanted to enforce a >>>>>> higher >>>>>> standard. Also, it might be worth revisiting if >>>>>> -Wno-error=unused-parameter is really needed. These things tend to >>>>>> bit-rot. >>>>>> >>>>>> /Magnus >>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Bertrand. >>>>>>> >>>>>> >>>> >> > From magnus.ihse.bursie at oracle.com Tue Jun 2 12:36:08 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 14:36:08 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D93B0.9050805@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> <556D8507.304@oracle.com> <556D86D8.8090702@oracle.com> <556D8932.6090900@oracle.com> <556D93B0.9050805@oracle.com> Message-ID: <556DA338.3060209@oracle.com> On 2015-06-02 13:29, David Holmes wrote: > On 2/06/2015 8:45 PM, Magnus Ihse Bursie wrote: >> On 2015-06-02 12:35, Magnus Ihse Bursie wrote: >>> On 2015-06-02 12:27, David Holmes wrote: >>>> These should be removed instead. >>>> >>>> Okay but I don't think it reasonable to expect Bertrand to make such >>>> changes. In the interest of moving forward can we use his current >>>> patch and file a follow up bug to get this done properly by the build >>>> team? >>> It's not worth the trouble to put in bad code just to rip it out. I'll >>> have the patch done in five minutes, brb. :) >> >> Here's the webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8081616-respect-disable-warnings-as-errors/webrev.01 >> >> >> >> No top level changes are needed. I kept the disabling of >> unused-parameter in libsctp for pragmatic reasons. On my computer it >> compiled fine without it, but it requires more work to determine if it >> can be removed. > > I'm missing something - where does CFLAGS_WARNINGS_ARE_ERRORS get > added in when it is enabled ?? It is used in SetupNativeCompilation.gmk. It is one of the "control flags" that are tightly coupled with the SetupNativeCompilation code, like SHARED_LIBRARY_FLAGS. The "control flags" are used to control the behavior of the compiler rather than to affect the resulting build. We have been doing a bad job in the past of separating "product flags" (e.g. -DPRODUCT_NAME=JDK) from control flags. This is the reason I didn't want CFLAGS_WARNINGS_ARE_ERRORS removed. > Also we will need to this to go in via hs-rt please (using JPRT). Okidoki! /Magnus > > Thanks, > David > >> /Magnus >> >>> >>> /Magnus >>> >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> I also checked for -Werror in the code, but could only find the >>>>> already >>>>> discovered location in Lib-jdk.sctp.gmk. For that, I believe the >>>>> proper >>>>> solution is: >>>>> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >>>>> --- a/make/lib/Lib-jdk.sctp.gmk >>>>> +++ b/make/lib/Lib-jdk.sctp.gmk >>>>> @@ -30,12 +30,8 @@ >>>>> ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) >>>>> >>>>> ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) >>>>> - >>>>> - # Suppress unused parameters required by exported JNI functions. >>>>> - SCTP_WERROR := -Werror -Wno-error=unused-parameter >>>>> - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >>>>> - SCTP_WERROR := >>>>> - endif >>>>> + # DISABLED_WARNINGS_gcc := unusused-parameter needed to >>>>> + # suppress unused parameters required by exported JNI functions. >>>>> >>>>> $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ >>>>> LIBRARY := sctp, \ >>>>> @@ -49,7 +45,7 @@ >>>>> $(LIBJAVA_HEADER_FLAGS) \ >>>>> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >>>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >>>>> - CFLAGS_linux := $(SCTP_WERROR), \ >>>>> + DISABLED_WARNINGS_gcc := unusused-parameter, \ >>>>> MAPFILE := >>>>> $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>> >>>>> >>>>> However, as I said, it should probably be verified that it is correct >>>>> that the unused-parameter warning is still triggered. >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> >>>>>>> I can see that libsctp is a special case that hard-codes -Werror. >>>>>>> But in >>>>>>> this case we should remove the hard-coding and relying on the >>>>>>> system >>>>>>> setting. This is probably a remnant from before the overall -Werror >>>>>>> usage, where the authors of a specific lib wanted to enforce a >>>>>>> higher >>>>>>> standard. Also, it might be worth revisiting if >>>>>>> -Wno-error=unused-parameter is really needed. These things tend to >>>>>>> bit-rot. >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Bertrand. >>>>>>>> >>>>>>> >>>>> >>> >> From david.holmes at oracle.com Tue Jun 2 12:36:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 02 Jun 2015 22:36:25 +1000 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556DA338.3060209@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> <556D8507.304@oracle.com> <556D86D8.8090702@oracle.com> <556D8932.6090900@oracle.com> <556D93B0.9050805@oracle.com> <556DA338.3060209@oracle.com> Message-ID: <556DA349.7000708@oracle.com> On 2/06/2015 10:36 PM, Magnus Ihse Bursie wrote: > On 2015-06-02 13:29, David Holmes wrote: >> On 2/06/2015 8:45 PM, Magnus Ihse Bursie wrote: >>> On 2015-06-02 12:35, Magnus Ihse Bursie wrote: >>>> On 2015-06-02 12:27, David Holmes wrote: >>>>> These should be removed instead. >>>>> >>>>> Okay but I don't think it reasonable to expect Bertrand to make such >>>>> changes. In the interest of moving forward can we use his current >>>>> patch and file a follow up bug to get this done properly by the build >>>>> team? >>>> It's not worth the trouble to put in bad code just to rip it out. I'll >>>> have the patch done in five minutes, brb. :) >>> >>> Here's the webrev: >>> http://cr.openjdk.java.net/~ihse/JDK-8081616-respect-disable-warnings-as-errors/webrev.01 >>> >>> >>> >>> No top level changes are needed. I kept the disabling of >>> unused-parameter in libsctp for pragmatic reasons. On my computer it >>> compiled fine without it, but it requires more work to determine if it >>> can be removed. >> >> I'm missing something - where does CFLAGS_WARNINGS_ARE_ERRORS get >> added in when it is enabled ?? > > It is used in SetupNativeCompilation.gmk. It is one of the "control > flags" that are tightly coupled with the SetupNativeCompilation code, > like SHARED_LIBRARY_FLAGS. > > The "control flags" are used to control the behavior of the compiler > rather than to affect the resulting build. We have been doing a bad job > in the past of separating "product flags" (e.g. -DPRODUCT_NAME=JDK) from > control flags. This is the reason I didn't want > CFLAGS_WARNINGS_ARE_ERRORS removed. Thanks for clarifying. >> Also we will need to this to go in via hs-rt please (using JPRT). > Okidoki! Please use "-testset hotspot". Thanks - and good night :) David ----- > /Magnus >> >> Thanks, >> David >> >>> /Magnus >>> >>>> >>>> /Magnus >>>> >>>>> >>>>> Thanks, >>>>> David >>>>> ----- >>>>> >>>>>> I also checked for -Werror in the code, but could only find the >>>>>> already >>>>>> discovered location in Lib-jdk.sctp.gmk. For that, I believe the >>>>>> proper >>>>>> solution is: >>>>>> diff --git a/make/lib/Lib-jdk.sctp.gmk b/make/lib/Lib-jdk.sctp.gmk >>>>>> --- a/make/lib/Lib-jdk.sctp.gmk >>>>>> +++ b/make/lib/Lib-jdk.sctp.gmk >>>>>> @@ -30,12 +30,8 @@ >>>>>> ifeq ($(OPENJDK_TARGET_OS_TYPE), unix) >>>>>> >>>>>> ifeq (, $(filter $(OPENJDK_TARGET_OS), macosx aix)) >>>>>> - >>>>>> - # Suppress unused parameters required by exported JNI functions. >>>>>> - SCTP_WERROR := -Werror -Wno-error=unused-parameter >>>>>> - ifeq ($(OPENJDK_TARGET_CPU_ARCH), ppc) >>>>>> - SCTP_WERROR := >>>>>> - endif >>>>>> + # DISABLED_WARNINGS_gcc := unusused-parameter needed to >>>>>> + # suppress unused parameters required by exported JNI functions. >>>>>> >>>>>> $(eval $(call SetupNativeCompilation,BUILD_LIBSCTP, \ >>>>>> LIBRARY := sctp, \ >>>>>> @@ -49,7 +45,7 @@ >>>>>> $(LIBJAVA_HEADER_FLAGS) \ >>>>>> -I$(SUPPORT_OUTPUTDIR)/headers/jdk.sctp \ >>>>>> -I$(SUPPORT_OUTPUTDIR)/headers/java.base, \ >>>>>> - CFLAGS_linux := $(SCTP_WERROR), \ >>>>>> + DISABLED_WARNINGS_gcc := unusused-parameter, \ >>>>>> MAPFILE := >>>>>> $(JDK_TOPDIR)/make/mapfiles/libsctp/mapfile-vers, \ >>>>>> LDFLAGS := $(LDFLAGS_JDKLIB) \ >>>>>> $(call SET_SHARED_LIBRARY_ORIGIN), \ >>>>>> >>>>>> >>>>>> However, as I said, it should probably be verified that it is correct >>>>>> that the unused-parameter warning is still triggered. >>>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>> >>>>>>> >>>>>>> David >>>>>>> ----- >>>>>>> >>>>>>> >>>>>>> >>>>>>>> I can see that libsctp is a special case that hard-codes -Werror. >>>>>>>> But in >>>>>>>> this case we should remove the hard-coding and relying on the >>>>>>>> system >>>>>>>> setting. This is probably a remnant from before the overall -Werror >>>>>>>> usage, where the authors of a specific lib wanted to enforce a >>>>>>>> higher >>>>>>>> standard. Also, it might be worth revisiting if >>>>>>>> -Wno-error=unused-parameter is really needed. These things tend to >>>>>>>> bit-rot. >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Bertrand. >>>>>>>>> >>>>>>>> >>>>>> >>>> >>> > From semyon.sadetsky at oracle.com Tue Jun 2 13:21:52 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 16:21:52 +0300 Subject: Solaris jdk9 build problem In-Reply-To: <556D8832.8090508@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D83D7.5020206@oracle.com> <556D8671.4070501@oracle.com> <556D8832.8090508@oracle.com> Message-ID: <556DADF0.40604@oracle.com> Hello, Hate to disturb you again but I got yet another show stopper for my Solaris build: Generating solaris_amd64_docs/jvmti.html Creating libverify.so from 2 file(s) Creating libjava.so from 60 file(s) Creating libfdlibm.a from 62 file(s) Creating libzip.so from 21 file(s) Creating libjli.so from 15 file(s) Creating libnet.so from 21 file(s) Creating libnio.so from 23 file(s) Compiling 3 properties into resource bundles for jdk.jdi Compiling 246 files for jdk.jdi "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line 384: error: statement not reached (E_STATEMENT_NOT_REACHED) cc: acomp failed for /jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c gmake[3]: *** [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/native/java.base/libjava/childproc.o] Error 2 gmake[3]: *** Waiting for unfinished jobs.... gmake[2]: *** [java.base-libs] Error 1 --Semyon On 6/2/2015 1:40 PM, Semyon Sadetsky wrote: > > On 6/2/2015 1:33 PM, Magnus Ihse Bursie wrote: >> On 2015-06-02 12:22, David Holmes wrote: >>> On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: >>>> >>>> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>>>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>>>> >>>>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>>>> Hello, >>>>>>>>>> >>>>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>>>> >>>>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>>>> gmake[8]: Leaving directory >>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>>>> gmake[7]: Leaving directory >>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> and earlier in the log: >>>>>>>>>> >>>>>>>>>> Assembling >>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>> rm -f solaris_x86_64.o >>>>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>>>> rm -f space.o >>>>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>>>> ... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for the >>>>>>>>> value of AS? >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>>> >>>>>>>> Yes, AS was empty. >>>>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>>>> message has gone but then I got: >>>>>>> You cannot set it manually. If configure has failed to detect it, >>>>>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>>>>> be empty, it should have aborted. >>>>>>> >>>>>>> Try running configure with >>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that help >>>>>>> you >>>>>>> get a proper value of AS. >>>>>>> >>>>>>> /Magnus >>>>>> >>>>>> AS remains empty: >>>>>> ==================================================== >>>>>> A new configuration has been successfully created in >>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>>>> using configure arguments '--enable-debug >>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>>>> >>>>>> Configuration summary: >>>>>> * Debug level: fastdebug >>>>>> * HS debug level: fastdebug >>>>>> * JDK variant: normal >>>>>> * JVM variants: server >>>>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>>>> length: 64 >>>>>> >>>>>> Tools summary: >>>>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>>>> >>>>>> Build performance summary: >>>>>> * Cores to use: 2 >>>>>> * Memory limit: 2048 MB >>>>>> >>>>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>>>> AS:= >>>>> >>>>> Do you have an as in your path or in /opt/solarisstudio12.3/bin then? >>>>> Have you even built jdk successfully on this machine? >>>>> >>>>> /Magnus >>>>> >>>> No it's a new installation. And I'm building jdk on Solaris for the >>>> first time. >>>> as is absent in /opt/solarisstudio12.3/bin. >>>> >>>> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >>>> CC cscope er_bit f90 rtc_patch_area >>>> sunf90 >>>> CCadmin ctc er_cp f95 rxm >>>> sunf95 >>>> amd64 ctcr er_export fbe rxs sunstudio >>>> analyzer ctrace er_generic fdumpmod smctl tcov >>>> bcheck cxref er_html fpp solstudio >>>> tha >>>> binopt dbx er_kernel fpr spot >>>> uncover >>>> c++filt dbxtool er_mpipp fsplit spot_diff >>>> version >>>> c89 dem er_mv gen_custom >>>> ss_attach whatdir >>>> c99 discover er_otfdump getmsg sunCC >>>> xprof_atob >>>> cb dlight er_print indent sunas >>>> xprof_btoa >>>> cc dmake er_rm lint sunc89 >>>> cc-5.0 dumpstabs er_src lock_lint sunc99 >>>> cflow dwarfdump er_vtunify ptclean suncc >>>> collect er_archive f77 ripc sunf77 >>>> >>>> Should it be there? >>> >>> No it is in a separate package apparently (not installed by default >>> on Solaris 11): >>> >>> pkg install pkg:/developer/assembler >> >> Thanks for the information David! >> >> I opened https://bugs.openjdk.java.net/browse/JDK-8081676 to track >> that we should verify that AS is properly detected on Solaris, and to >> print the help about pkg install in case as is missing. >> >> /Magnus >> > Possible it would be worth to add this information to the readme as > well. On other linuxes gcc is used instead of as and configure does > not produce any warnings about it. It is not trivial to find the > reason for people building solaris jdk for the first time. > > --Semyon > >>> >>> David >>> ----- >>> >>>> >>>> >>>>>> dev at solaris1:/jdk9/client$ >>>>>> >>>>>> >>>>>>> >>>>>>>> >>>>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create 64-bit >>>>>>>> programs >>>>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>>> >> > From magnus.ihse.bursie at oracle.com Tue Jun 2 13:47:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 15:47:55 +0200 Subject: RFR [XXS] : JDK-8081616: build fixes for --disable-warnings-as-errors In-Reply-To: <556D9876.1080308@oracle.com> References: <556C94FE.9000805@oracle.com> <556D7039.1020606@oracle.com> <556D7DFA.4020706@oracle.com> <556D8403.8040905@oracle.com> <556D8507.304@oracle.com> <556D86D8.8090702@oracle.com> <556D8932.6090900@oracle.com> <556D9876.1080308@oracle.com> Message-ID: <556DB40B.4030008@oracle.com> On 2015-06-02 13:50, Bertrand Delsart wrote: > On 02/06/2015 12:45, Magnus Ihse Bursie wrote: >> On 2015-06-02 12:35, Magnus Ihse Bursie wrote: >>> On 2015-06-02 12:27, David Holmes wrote: >>>> These should be removed instead. >>>> >>>> Okay but I don't think it reasonable to expect Bertrand to make such >>>> changes. In the interest of moving forward can we use his current >>>> patch and file a follow up bug to get this done properly by the build >>>> team? >>> It's not worth the trouble to put in bad code just to rip it out. I'll >>> have the patch done in five minutes, brb. :) >> >> Here's the webrev: >> http://cr.openjdk.java.net/~ihse/JDK-8081616-respect-disable-warnings-as-errors/webrev.01 >> >> >> >> No top level changes are needed. I kept the disabling of >> unused-parameter in libsctp for pragmatic reasons. On my computer it >> compiled fine without it, but it requires more work to determine if it >> can be removed. > > I was shooting for a simple fix, with no cleanup, to reduce regression > risks (particularly since I'm not an expert on the new build system). > > Your fix looks like a good cleanup and should be sufficient to solve > my issue... but may have a small side effect. > > In particular, If I understand correctly, the Werror in > Lib-jdk.sctp.gmk was redundant. Hence, on ppc, we were by default > compiling with Werror but without -Wno-unused-parameter. With your fix > we will now be less strict on PPC, allowing unused parameters. > > This may not be a big deal since AIX is filtered-out. This would apply > only to open linux-ppc ports, if any. Hence, this is probably OK but > I'll let you grab the CR and decide whether to push it as is or not. Yeah. Watch me don't care about the strictness on linux-ppc. ;-) When I tested locally, -Wno-unused-parameters where not needed on my system either (linux-x64). So it's possible it's become outdated. So just for completeness, I opened https://bugs.openjdk.java.net/browse/JDK-8081694 to track this, suggesting that the warning disabling should be removed. /Magnus From magnus.ihse.bursie at oracle.com Tue Jun 2 13:50:03 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 02 Jun 2015 15:50:03 +0200 Subject: Solaris jdk9 build problem In-Reply-To: <556DADF0.40604@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D83D7.5020206@oracle.com> <556D8671.4070501@oracle.com> <556D8832.8090508@oracle.com> <556DADF0.40604@oracle.com> Message-ID: <556DB48B.2080003@oracle.com> On 2015-06-02 15:21, Semyon Sadetsky wrote: > Hello, > > Hate to disturb you again but I got yet another show stopper for my > Solaris build: > > Generating solaris_amd64_docs/jvmti.html > Creating libverify.so from 2 file(s) > Creating libjava.so from 60 file(s) > Creating libfdlibm.a from 62 file(s) > Creating libzip.so from 21 file(s) > Creating libjli.so from 15 file(s) > Creating libnet.so from 21 file(s) > Creating libnio.so from 23 file(s) > Compiling 3 properties into resource bundles for jdk.jdi > Compiling 246 files for jdk.jdi > "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line > 384: error: statement not reached (E_STATEMENT_NOT_REACHED) > cc: acomp failed for > /jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c > gmake[3]: *** > [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/native/java.base/libjava/childproc.o] > Error 2 > gmake[3]: *** Waiting for unfinished jobs.... > gmake[2]: *** [java.base-libs] Error 1 I belive the rest of the log says: "please try again with --disable-warnings-as-errors" or something like that. Do it! :) An even better solution is to investigate the warning and fix the code. I can't really say why you're getting this warning, though. Your version of the compiler might differ too much from the official ones. /Magnus > > --Semyon > > > > On 6/2/2015 1:40 PM, Semyon Sadetsky wrote: >> >> On 6/2/2015 1:33 PM, Magnus Ihse Bursie wrote: >>> On 2015-06-02 12:22, David Holmes wrote: >>>> On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: >>>>> >>>>> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>>>>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>>>>> >>>>>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>>>>> >>>>>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>>>>> gmake[8]: Leaving directory >>>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>>>>> gmake[7]: Leaving directory >>>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and earlier in the log: >>>>>>>>>>> >>>>>>>>>>> Assembling >>>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>>> rm -f solaris_x86_64.o >>>>>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>>>>> rm -f space.o >>>>>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for >>>>>>>>>> the >>>>>>>>>> value of AS? >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>> Yes, AS was empty. >>>>>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>>>>> message has gone but then I got: >>>>>>>> You cannot set it manually. If configure has failed to detect it, >>>>>>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>>>>>> be empty, it should have aborted. >>>>>>>> >>>>>>>> Try running configure with >>>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that >>>>>>>> help you >>>>>>>> get a proper value of AS. >>>>>>>> >>>>>>>> /Magnus >>>>>>> >>>>>>> AS remains empty: >>>>>>> ==================================================== >>>>>>> A new configuration has been successfully created in >>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>>>>> using configure arguments '--enable-debug >>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>>>>> >>>>>>> Configuration summary: >>>>>>> * Debug level: fastdebug >>>>>>> * HS debug level: fastdebug >>>>>>> * JDK variant: normal >>>>>>> * JVM variants: server >>>>>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>>>>> length: 64 >>>>>>> >>>>>>> Tools summary: >>>>>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>>>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>>>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>>>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>>>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>>>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>>>>> >>>>>>> Build performance summary: >>>>>>> * Cores to use: 2 >>>>>>> * Memory limit: 2048 MB >>>>>>> >>>>>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>>>>> AS:= >>>>>> >>>>>> Do you have an as in your path or in /opt/solarisstudio12.3/bin >>>>>> then? >>>>>> Have you even built jdk successfully on this machine? >>>>>> >>>>>> /Magnus >>>>>> >>>>> No it's a new installation. And I'm building jdk on Solaris for the >>>>> first time. >>>>> as is absent in /opt/solarisstudio12.3/bin. >>>>> >>>>> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >>>>> CC cscope er_bit f90 >>>>> rtc_patch_area sunf90 >>>>> CCadmin ctc er_cp f95 >>>>> rxm sunf95 >>>>> amd64 ctcr er_export fbe rxs sunstudio >>>>> analyzer ctrace er_generic fdumpmod smctl tcov >>>>> bcheck cxref er_html fpp >>>>> solstudio tha >>>>> binopt dbx er_kernel fpr >>>>> spot uncover >>>>> c++filt dbxtool er_mpipp fsplit spot_diff >>>>> version >>>>> c89 dem er_mv gen_custom >>>>> ss_attach whatdir >>>>> c99 discover er_otfdump getmsg sunCC >>>>> xprof_atob >>>>> cb dlight er_print indent sunas >>>>> xprof_btoa >>>>> cc dmake er_rm lint sunc89 >>>>> cc-5.0 dumpstabs er_src lock_lint sunc99 >>>>> cflow dwarfdump er_vtunify ptclean suncc >>>>> collect er_archive f77 ripc sunf77 >>>>> >>>>> Should it be there? >>>> >>>> No it is in a separate package apparently (not installed by default >>>> on Solaris 11): >>>> >>>> pkg install pkg:/developer/assembler >>> >>> Thanks for the information David! >>> >>> I opened https://bugs.openjdk.java.net/browse/JDK-8081676 to track >>> that we should verify that AS is properly detected on Solaris, and >>> to print the help about pkg install in case as is missing. >>> >>> /Magnus >>> >> Possible it would be worth to add this information to the readme as >> well. On other linuxes gcc is used instead of as and configure does >> not produce any warnings about it. It is not trivial to find the >> reason for people building solaris jdk for the first time. >> >> --Semyon >> >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> >>>>>>> dev at solaris1:/jdk9/client$ >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create >>>>>>>>> 64-bit >>>>>>>>> programs >>>>>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From Roger.Riggs at Oracle.com Tue Jun 2 13:49:59 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 02 Jun 2015 09:49:59 -0400 Subject: Solaris jdk9 build problem In-Reply-To: <556DADF0.40604@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D83D7.5020206@oracle.com> <556D8671.4070501@oracle.com> <556D8832.8090508@oracle.com> <556DADF0.40604@oracle.com> Message-ID: <556DB487.1000103@Oracle.com> HI, The compiler is doing more checking than others. The other compilers don't seem to know that _exit() does not return. The following patch may get past the issue. (I'm not sure if it will with all compilers.) Let me know if that works and we'll see about patching 9. Roger diff --git a/src/java.base/unix/native/libjava/childproc.c b/src/java.base/unix/native/libjava/childproc.c --- a/src/java.base/unix/native/libjava/childproc.c +++ b/src/java.base/unix/native/libjava/childproc.c @@ -303,6 +303,8 @@ JDK_execvpe(int mode, const char *file, } } +int childProcess(void *arg) __attribute__ ((__noreturn__)); + /** * Child process after a successful fork(). * This function must not return, and must be prepared for either all @@ -381,5 +383,4 @@ childProcess(void *arg) } close(FAIL_FILENO); _exit(-1); - return 0; /* Suppress warning "no return value from function" */ } On 6/2/2015 9:21 AM, Semyon Sadetsky wrote: > Hello, > > Hate to disturb you again but I got yet another show stopper for my > Solaris build: > > Generating solaris_amd64_docs/jvmti.html > Creating libverify.so from 2 file(s) > Creating libjava.so from 60 file(s) > Creating libfdlibm.a from 62 file(s) > Creating libzip.so from 21 file(s) > Creating libjli.so from 15 file(s) > Creating libnet.so from 21 file(s) > Creating libnio.so from 23 file(s) > Compiling 3 properties into resource bundles for jdk.jdi > Compiling 246 files for jdk.jdi > "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line > 384: error: statement not reached (E_STATEMENT_NOT_REACHED) > cc: acomp failed for > /jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c > gmake[3]: *** > [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/native/java.base/libjava/childproc.o] > Error 2 > gmake[3]: *** Waiting for unfinished jobs.... > gmake[2]: *** [java.base-libs] Error 1 > > --Semyon > > > > On 6/2/2015 1:40 PM, Semyon Sadetsky wrote: >> >> On 6/2/2015 1:33 PM, Magnus Ihse Bursie wrote: >>> On 2015-06-02 12:22, David Holmes wrote: >>>> On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: >>>>> >>>>> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>>>>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>>>>> >>>>>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>>>>> Hello, >>>>>>>>>>> >>>>>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>>>>> >>>>>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>>>>> gmake[8]: Leaving directory >>>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>>>>> gmake[7]: Leaving directory >>>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> and earlier in the log: >>>>>>>>>>> >>>>>>>>>>> Assembling >>>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>>> rm -f solaris_x86_64.o >>>>>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>>>>> rm -f space.o >>>>>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>>>>> ... >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for >>>>>>>>>> the >>>>>>>>>> value of AS? >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>>>>>>> Yes, AS was empty. >>>>>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>>>>> message has gone but then I got: >>>>>>>> You cannot set it manually. If configure has failed to detect it, >>>>>>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>>>>>> be empty, it should have aborted. >>>>>>>> >>>>>>>> Try running configure with >>>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that >>>>>>>> help you >>>>>>>> get a proper value of AS. >>>>>>>> >>>>>>>> /Magnus >>>>>>> >>>>>>> AS remains empty: >>>>>>> ==================================================== >>>>>>> A new configuration has been successfully created in >>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>>>>> using configure arguments '--enable-debug >>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>>>>> >>>>>>> Configuration summary: >>>>>>> * Debug level: fastdebug >>>>>>> * HS debug level: fastdebug >>>>>>> * JDK variant: normal >>>>>>> * JVM variants: server >>>>>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>>>>> length: 64 >>>>>>> >>>>>>> Tools summary: >>>>>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>>>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>>>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>>>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>>>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>>>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>>>>> >>>>>>> Build performance summary: >>>>>>> * Cores to use: 2 >>>>>>> * Memory limit: 2048 MB >>>>>>> >>>>>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>>>>> AS:= >>>>>> >>>>>> Do you have an as in your path or in /opt/solarisstudio12.3/bin >>>>>> then? >>>>>> Have you even built jdk successfully on this machine? >>>>>> >>>>>> /Magnus >>>>>> >>>>> No it's a new installation. And I'm building jdk on Solaris for the >>>>> first time. >>>>> as is absent in /opt/solarisstudio12.3/bin. >>>>> >>>>> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >>>>> CC cscope er_bit f90 >>>>> rtc_patch_area sunf90 >>>>> CCadmin ctc er_cp f95 >>>>> rxm sunf95 >>>>> amd64 ctcr er_export fbe rxs sunstudio >>>>> analyzer ctrace er_generic fdumpmod smctl tcov >>>>> bcheck cxref er_html fpp >>>>> solstudio tha >>>>> binopt dbx er_kernel fpr >>>>> spot uncover >>>>> c++filt dbxtool er_mpipp fsplit spot_diff >>>>> version >>>>> c89 dem er_mv gen_custom >>>>> ss_attach whatdir >>>>> c99 discover er_otfdump getmsg sunCC >>>>> xprof_atob >>>>> cb dlight er_print indent sunas >>>>> xprof_btoa >>>>> cc dmake er_rm lint sunc89 >>>>> cc-5.0 dumpstabs er_src lock_lint sunc99 >>>>> cflow dwarfdump er_vtunify ptclean suncc >>>>> collect er_archive f77 ripc sunf77 >>>>> >>>>> Should it be there? >>>> >>>> No it is in a separate package apparently (not installed by default >>>> on Solaris 11): >>>> >>>> pkg install pkg:/developer/assembler >>> >>> Thanks for the information David! >>> >>> I opened https://bugs.openjdk.java.net/browse/JDK-8081676 to track >>> that we should verify that AS is properly detected on Solaris, and >>> to print the help about pkg install in case as is missing. >>> >>> /Magnus >>> >> Possible it would be worth to add this information to the readme as >> well. On other linuxes gcc is used instead of as and configure does >> not produce any warnings about it. It is not trivial to find the >> reason for people building solaris jdk for the first time. >> >> --Semyon >> >>>> >>>> David >>>> ----- >>>> >>>>> >>>>> >>>>>>> dev at solaris1:/jdk9/client$ >>>>>>> >>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create >>>>>>>>> 64-bit >>>>>>>>> programs >>>>>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>>> >>> >> > From semyon.sadetsky at oracle.com Tue Jun 2 13:56:18 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 16:56:18 +0300 Subject: Solaris jdk9 build problem In-Reply-To: <556DB48B.2080003@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D83D7.5020206@oracle.com> <556D8671.4070501@oracle.com> <556D8832.8090508@oracle.com> <556DADF0.40604@oracle.com> <556DB48B.2080003@oracle.com> Message-ID: <556DB602.8080105@oracle.com> On 6/2/2015 4:50 PM, Magnus Ihse Bursie wrote: > On 2015-06-02 15:21, Semyon Sadetsky wrote: >> Hello, >> >> Hate to disturb you again but I got yet another show stopper for my >> Solaris build: >> >> Generating solaris_amd64_docs/jvmti.html >> Creating libverify.so from 2 file(s) >> Creating libjava.so from 60 file(s) >> Creating libfdlibm.a from 62 file(s) >> Creating libzip.so from 21 file(s) >> Creating libjli.so from 15 file(s) >> Creating libnet.so from 21 file(s) >> Creating libnio.so from 23 file(s) >> Compiling 3 properties into resource bundles for jdk.jdi >> Compiling 246 files for jdk.jdi >> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", >> line 384: error: statement not reached (E_STATEMENT_NOT_REACHED) >> cc: acomp failed for >> /jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c >> gmake[3]: *** >> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/native/java.base/libjava/childproc.o] >> Error 2 >> gmake[3]: *** Waiting for unfinished jobs.... >> gmake[2]: *** [java.base-libs] Error 1 > > I belive the rest of the log says: "please try again with > --disable-warnings-as-errors" or something like that. > > Do it! :) > > An even better solution is to investigate the warning and fix the code. > > I can't really say why you're getting this warning, though. Your > version of the compiler might differ too much from the official ones. > > /Magnus Okay. What is the official one? I used Solaris studio 12.3 it has compiler version 5.10 which was recommended in the docs. --Semyon > >> >> --Semyon >> >> >> >> On 6/2/2015 1:40 PM, Semyon Sadetsky wrote: >>> >>> On 6/2/2015 1:33 PM, Magnus Ihse Bursie wrote: >>>> On 2015-06-02 12:22, David Holmes wrote: >>>>> On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>>>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>>>>>> >>>>>>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>>>>>> gmake[8]: Leaving directory >>>>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>>>>>> gmake[7]: Leaving directory >>>>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> and earlier in the log: >>>>>>>>>>>> >>>>>>>>>>>> Assembling >>>>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>>>> >>>>>>>>>>>> rm -f solaris_x86_64.o >>>>>>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>>>> >>>>>>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>>>>>> Compiling >>>>>>>>>>>> /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>>>>>> rm -f space.o >>>>>>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk >>>>>>>>>>> for the >>>>>>>>>>> value of AS? >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>> Yes, AS was empty. >>>>>>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>>>>>> message has gone but then I got: >>>>>>>>> You cannot set it manually. If configure has failed to detect it, >>>>>>>>> all bets are off. I'm a bit surprised that configure allowed >>>>>>>>> AS to >>>>>>>>> be empty, it should have aborted. >>>>>>>>> >>>>>>>>> Try running configure with >>>>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that >>>>>>>>> help you >>>>>>>>> get a proper value of AS. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>> >>>>>>>> AS remains empty: >>>>>>>> ==================================================== >>>>>>>> A new configuration has been successfully created in >>>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>>>>>> using configure arguments '--enable-debug >>>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>>>>>> >>>>>>>> Configuration summary: >>>>>>>> * Debug level: fastdebug >>>>>>>> * HS debug level: fastdebug >>>>>>>> * JDK variant: normal >>>>>>>> * JVM variants: server >>>>>>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>>>>>> length: 64 >>>>>>>> >>>>>>>> Tools summary: >>>>>>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>>>>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>>>>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>>>>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>>>>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>>>>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>>>>>> >>>>>>>> Build performance summary: >>>>>>>> * Cores to use: 2 >>>>>>>> * Memory limit: 2048 MB >>>>>>>> >>>>>>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>>>>>> AS:= >>>>>>> >>>>>>> Do you have an as in your path or in /opt/solarisstudio12.3/bin >>>>>>> then? >>>>>>> Have you even built jdk successfully on this machine? >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>> No it's a new installation. And I'm building jdk on Solaris for the >>>>>> first time. >>>>>> as is absent in /opt/solarisstudio12.3/bin. >>>>>> >>>>>> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >>>>>> CC cscope er_bit f90 >>>>>> rtc_patch_area sunf90 >>>>>> CCadmin ctc er_cp f95 >>>>>> rxm sunf95 >>>>>> amd64 ctcr er_export fbe rxs sunstudio >>>>>> analyzer ctrace er_generic fdumpmod smctl tcov >>>>>> bcheck cxref er_html fpp >>>>>> solstudio tha >>>>>> binopt dbx er_kernel fpr >>>>>> spot uncover >>>>>> c++filt dbxtool er_mpipp fsplit spot_diff >>>>>> version >>>>>> c89 dem er_mv gen_custom >>>>>> ss_attach whatdir >>>>>> c99 discover er_otfdump getmsg sunCC >>>>>> xprof_atob >>>>>> cb dlight er_print indent sunas >>>>>> xprof_btoa >>>>>> cc dmake er_rm lint sunc89 >>>>>> cc-5.0 dumpstabs er_src lock_lint sunc99 >>>>>> cflow dwarfdump er_vtunify ptclean suncc >>>>>> collect er_archive f77 ripc sunf77 >>>>>> >>>>>> Should it be there? >>>>> >>>>> No it is in a separate package apparently (not installed by >>>>> default on Solaris 11): >>>>> >>>>> pkg install pkg:/developer/assembler >>>> >>>> Thanks for the information David! >>>> >>>> I opened https://bugs.openjdk.java.net/browse/JDK-8081676 to track >>>> that we should verify that AS is properly detected on Solaris, and >>>> to print the help about pkg install in case as is missing. >>>> >>>> /Magnus >>>> >>> Possible it would be worth to add this information to the readme as >>> well. On other linuxes gcc is used instead of as and configure does >>> not produce any warnings about it. It is not trivial to find the >>> reason for people building solaris jdk for the first time. >>> >>> --Semyon >>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> >>>>>>>> dev at solaris1:/jdk9/client$ >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create >>>>>>>>>> 64-bit >>>>>>>>>> programs >>>>>>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From erik.joelsson at oracle.com Tue Jun 2 14:04:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 02 Jun 2015 16:04:25 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556C8094.3050800@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> Message-ID: <556DB7E9.7090709@oracle.com> Hello Jan, Sorry to bother you with even more build changes, but with these file moves, I realized that this new file, ct.sym, is really a part of the jdk.compiler module and really not a special case at all. Because of this, it should be generated as part of the jdk.compiler-gendata target. This also eliminates all the changes in the top level repo and only leaves one new makefile in the langtools repo. http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ /Erik On 2015-06-01 17:56, Jan Lahoda wrote: > Hi, > > I made a somewhat bigger update (partially based on other feedback). > Summary of changes: > -the history data has been moved into langtools (I also moved the > Ctsym.gmk) > -there are JDK 6 data now > -renamed the "-platform" option to "-release". Code/tests directly > related to the option has been also changed as well. I kept the > internal PlatformProvider API in javac as is, and also kept related code. > -added a note that the is generated by > CreateSymbols. > > Webrevs: > top-level: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ > langtools: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ > > Delta webrevs are also available. > > How does this look? > > Thanks for the comments so far! > > Jan > > On 27.5.2015 14:23, Jan Lahoda wrote: >> Ah, yes, I did not realize that. Thanks, will fix. >> >> Thanks, >> Jan >> >> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>> Looks great. The only nitpick is that the comments in CreateSymbols >>> don't mention the fact that a side effect of the sym.txt generation is >>> the mentioned earlier in the same comments >>> (so one might wonder where does that come from). >>> >>> Maurizio >>> >>> On 27/05/15 10:37, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I've uploaded another iteration, with these changes: >>>> -the "symbols" file is now generated automatically (for the typical >>>> OpenJDK case). >>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>> description into wrong a file (the "break" -> "break OUTER;" change). >>>> -jdk.management module has been split out from java.management >>>> recently, so splitting the corresponding .sym.txt files into >>>> java.management and jdk.management as well. >>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>> >>>> Webrevs: >>>> -top-level: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>> -langtools (no changes against the last webrev): >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>> >>>> Delta webrevs against the previous iteration are included under >>>> "Author comments". >>>> >>>> Thanks for the comments so far! >>>> >>>> Jan >>>> >>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>> Excellent work. >>>>>> >>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>> Probe >>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>> >>>>>> /bin/java Probe --> classes-8 >>>>>> /bin/java Probe --> classes-7 >>>>>> /bin/java Probe --> classes-7 >>>>>> >>>>>> etc. >>>>> >>>>> Sure, will do. >>>>> >>>>> I'll also look at generating the make/data/symbols/symbols >>>>> descriptions >>>>> automatically, per our offline discussion. >>>>> >>>>> Thanks! >>>>> >>>>> Jan >>>>> >>>>>> >>>>>> Maurizio >>>>>> >>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>> top-level repository: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>> langtools: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>> >>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>> differences >>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>> "Author's comments") >>>>>>> >>>>>>> Summary of changes: >>>>>>> -applied Eric's build changes >>>>>>> -moved CreateSymbols into >>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>> -tried to improve the specification of base platforms in >>>>>>> CreateSymbols, per Maurizio's comment >>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>>>> >>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>> Hi Jan, >>>>>>>> great work - couple of comments below: >>>>>>>> >>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>> simplified >>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>> checkOptionAllowed >>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>> commonalities >>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>> this a >>>>>>>> bit? >>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>> specified >>>>>>>> and >>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>> that, >>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>> logic in >>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>> CreateSymbols >>>>>>>> with >>>>>>>> how the files were laid out. I think in the end, what you mean is >>>>>>>> that >>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>> (i.e. 8) >>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>> that's the >>>>>>>> use >>>>>>>> case, I think the command line can be simplified a bit in order to >>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>> the >>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>> seem to be typically all >>>>>>>> identical >>>>>>>> but one which is set to - the one for the baseline). Maybe >>>>>>>> the >>>>>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>>>>> 7 and >>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>> should be >>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>> there >>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>> >>>>>>>>> Patch for the top-level repository is here: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>> >>>>>>>>> Patch for the langtools repository is here: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>> >>>>>>>>> These changes also require additional langtools changes as their >>>>>>>>> prerequisite: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>> >>>>>>>>> Overall, one can imagine '-platform N' to have the same effect as >>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>> values >>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>> correspond to >>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>> >>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>> N. The >>>>>>>>> proposal is to include history data in the textual format inside >>>>>>>>> the >>>>>>>>> OpenJDK repositories (the input data), process them at build time >>>>>>>>> and >>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>>>>>>> running with the -platform option then compiles against the >>>>>>>>> lib/ct.sym >>>>>>>>> file. The input history data are placed >>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>> This >>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>> public >>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>> >>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>> checkout and >>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>> significantly >>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>> would >>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>> >>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>> them as >>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>> Code >>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>> named >>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>> bootclasspath >>>>>>>>> for that version is obtained by using directories which have >>>>>>>>> 'N' in >>>>>>>>> their name. >>>>>>>>> >>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>> Concise >>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>> >>>>>>>>> I am sending this as one review, as the changes together make one >>>>>>>>> feature, but the langtools and top-level changes are independent >>>>>>>>> to a >>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>> and the >>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>> ct.sym >>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>> independently. >>>>>>>>> >>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>> Alan >>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>> matter >>>>>>>>> before. >>>>>>>>> >>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jan >>>>>>>> >>>>>> >>> From erik.joelsson at oracle.com Tue Jun 2 15:26:19 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 02 Jun 2015 17:26:19 +0200 Subject: [8u60] Request for review and approval: JDK-8074523: Windows native binaries have inconsistent "Product version" In-Reply-To: <5565CF1B.1030407@oracle.com> References: <555C7EF6.1010208@oracle.com> <555C82E1.6010606@oracle.com> <555C95A4.5010801@oracle.com> <556449E9.9040807@oracle.com> <5565CF1B.1030407@oracle.com> Message-ID: <556DCB1B.9020104@oracle.com> Thanks Magnus, but I still need an 8u reviewer, anyone? /Erik On 2015-05-27 16:05, Magnus Ihse Bursie wrote: > On 2015-05-26 12:24, Erik Joelsson wrote: >> Any chance I could get a review on this? > > Yeah, if you ask nicely, with sugar on top. ;-) > > Fix looks good to me. Thanks for taking care of this. > > /Magnus > >> >> /Erik >> >> On 2015-05-20 16:09, Erik Joelsson wrote: >>> Thanks, changed to: Windows native binaries have inconsistent >>> "Product version" >>> >>> Changed the label. >>> >>> /Erik >>> >>> On 2015-05-20 14:49, Se?n Coffey wrote: >>>> It might be good to edit the bug synopsis before pushing the >>>> change. I don't think this issue is specific to java.net bundles. >>>> Might also be useful to use the noreg-sqe label rather than >>>> noreg-build given that SQE team do appear to have test code for >>>> this area. >>>> >>>> Approved pending code review. >>>> >>>> Regards, >>>> Sean. >>>> >>>> On 20/05/15 13:32, Erik Joelsson wrote: >>>>> Please review and approve this fix for 8u60. >>>>> >>>>> On windows, native libraries and executables have version numbers >>>>> embedded into them. These can be seen when right-clicking the >>>>> binary in explorer, on the Details tab, as "Product version". >>>>> Currently in 8 update releases, these versions strings are >>>>> inconsistent. An example: >>>>> >>>>> in 8u45 b09 we have: >>>>> >>>>> bin\client\jvm.dll: 8.0.0.9 >>>>> bin\decora_sse.dll: 8.0.45.09 >>>>> bin\deploy.dll: 8.0.450.9 >>>>> bin\java.exe: 8.0.45.9 >>>>> >>>>> These differences fall into 4 different categories. >>>>> >>>>> 1. jvm.dll in hotspot is not picking up the update version at all. >>>>> This is due to a bug in the build-infra makefile rewrite that >>>>> wasn't discovered in JDK 8 because it didn't have an update version. >>>>> >>>>> 2. decora_sse.dll is part of javafx. Fixing their version scheme >>>>> is out of scope of this fix. A separate bug for javafx would be >>>>> needed. >>>>> >>>>> 3. deploy.dll is actually the correct one. Historically we have >>>>> encoded the update version with an extra digit for a potential >>>>> letter at the end of the string. >>>>> >>>>> 4. java.exe, and the rest of the binaries from the jdk repository >>>>> lost their extra 0 in the build-infra makefile rewrite and it >>>>> wasn't discovered in JDK 8. >>>>> >>>>> Since we no longer use letters in update version strings, we could >>>>> fix this by removing the extra 0. However, we have already >>>>> released 8 updates where some binaries have the extra 0. Removing >>>>> it would mean releasing 8u60 with binaries having version numbers >>>>> lower than previous updates. For this reason I propose fixing this >>>>> by adding the 0 for JDK and Hotspot binaries again, and of course >>>>> by supplying the correct variable to the hotspot makefiles so that >>>>> it even gets the update version in there. For clarity, with this >>>>> patch, the above will log like this: >>>>> >>>>> bin\client\jvm.dll: 8.0.450.9 >>>>> bin\decora_sse.dll: 8.0.45.09 >>>>> bin\deploy.dll: 8.0.450.9 >>>>> bin\java.exe: 8.0.450.9 >>>>> >>>>> Note that in JDK 9, the version number scheme is being completely >>>>> reworked so this will not be an issue. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074523 >>>>> Webrev: >>>>> http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html >>>>> >>>>> /Erik >>>> >>> >> > From semyon.sadetsky at oracle.com Tue Jun 2 15:27:59 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 18:27:59 +0300 Subject: official compiler for Solaris jdk9 build? Message-ID: <556DCB7F.2020104@oracle.com> Hi, I'm trying to build jdk9 under the current Solaris 11.2 version. Which version of the Solaris Studio should be installed for that? The readme-builds states: ... At a minimum, the Studio 12 Update 1 Compilers (containing version 5.10 of the C and C++ compilers) is required, including specific patches. ... Currently there are 3 versions currently available for downloading: Oracle Solaris Studio 12.2 Oracle Solaris Studio 12.3 Oracle Solaris Studio 12.4 I tried all 3 and only with 12.3 I do no receive build warnings about wrong compiler version, but my build constantly fails with 12.3 with the next message: Compiling 246 files for jdk.jdi "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) ld: fatal: file /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: not an ELF object gmake[3]: *** [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] Error 2 gmake[3]: *** Waiting for unfinished jobs.... gmake[2]: *** [java.base-libs] Error 1 Even --disable-warnings-as-errors option does not save the build from failure. Could you send me the software list with the versions that should be installed on a clean Solaris 11.2 instance to have the build running smoothly? Thank you, --Semyon From erik.joelsson at oracle.com Tue Jun 2 15:37:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 02 Jun 2015 17:37:06 +0200 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <556DCB7F.2020104@oracle.com> References: <556DCB7F.2020104@oracle.com> Message-ID: <556DCDA2.9080607@oracle.com> Hello Semyon, Solaris Studio 12.3 is the correct version. However, internally we use devkits with the compiler and system headers/libraries all packaged together (details in separate mail). The devkits still use headers and libraries from Solaris 10u10 for compatibility with that release. We normally run the build on Solaris 11.1. /Erik On 2015-06-02 17:27, Semyon Sadetsky wrote: > Hi, > > I'm trying to build jdk9 under the current Solaris 11.2 version. > Which version of the Solaris Studio should be installed for that? The > readme-builds states: > ... > At a minimum, the Studio 12 Update 1 Compilers (containing version > 5.10 of the C and C++ compilers) is required, including specific patches. > ... > Currently there are 3 versions currently available for downloading: > > Oracle Solaris Studio 12.2 > Oracle Solaris Studio 12.3 > Oracle Solaris Studio 12.4 > > I tried all 3 and only with 12.3 I do no receive build warnings about > wrong compiler version, > but my build constantly fails with 12.3 with the next message: > > Compiling 246 files for jdk.jdi > "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line > 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) > "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", > line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) > ld: fatal: file > /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: > not an ELF object > gmake[3]: *** > [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] > Error 2 > gmake[3]: *** Waiting for unfinished jobs.... > gmake[2]: *** [java.base-libs] Error 1 > > Even --disable-warnings-as-errors option does not save the build from > failure. > Could you send me the software list with the versions that should be > installed on a clean Solaris 11.2 instance to have the build running > smoothly? > > Thank you, > --Semyon > > > From philip.race at oracle.com Tue Jun 2 15:47:19 2015 From: philip.race at oracle.com (Phil Race) Date: Tue, 02 Jun 2015 08:47:19 -0700 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <556DCDA2.9080607@oracle.com> References: <556DCB7F.2020104@oracle.com> <556DCDA2.9080607@oracle.com> Message-ID: <556DD007.7080900@oracle.com> E_STATEMENT_NOT_REACHED is a favourite of SunStudio and I recently fixed one such warning (in closed code so I can't point to it here) but I did not see this one .. however I was using jprt and locally Solaris 10 SPARC. So perhaps it is something to do with the headers ? Ironically the warning is apparently due to an attempt to suppress a previous warning :-( .. _exit(-1); return 0; /* Suppress warning "no return value from function" */ } .. -phil. On 06/02/2015 08:37 AM, Erik Joelsson wrote: > Hello Semyon, > > Solaris Studio 12.3 is the correct version. However, internally we use > devkits with the compiler and system headers/libraries all packaged > together (details in separate mail). The devkits still use headers and > libraries from Solaris 10u10 for compatibility with that release. We > normally run the build on Solaris 11.1. > > /Erik > > On 2015-06-02 17:27, Semyon Sadetsky wrote: >> Hi, >> >> I'm trying to build jdk9 under the current Solaris 11.2 version. >> Which version of the Solaris Studio should be installed for that? The >> readme-builds states: >> ... >> At a minimum, the Studio 12 Update 1 Compilers (containing version >> 5.10 of the C and C++ compilers) is required, including specific >> patches. >> ... >> Currently there are 3 versions currently available for downloading: >> >> Oracle Solaris Studio 12.2 >> Oracle Solaris Studio 12.3 >> Oracle Solaris Studio 12.4 >> >> I tried all 3 and only with 12.3 I do no receive build warnings about >> wrong compiler version, >> but my build constantly fails with 12.3 with the next message: >> >> Compiling 246 files for jdk.jdi >> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", >> line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line >> 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >> ld: fatal: file >> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: >> not an ELF object >> gmake[3]: *** >> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] >> Error 2 >> gmake[3]: *** Waiting for unfinished jobs.... >> gmake[2]: *** [java.base-libs] Error 1 >> >> Even --disable-warnings-as-errors option does not save the build from >> failure. >> Could you send me the software list with the versions that should be >> installed on a clean Solaris 11.2 instance to have the build running >> smoothly? >> >> Thank you, >> --Semyon >> >> >> > From semyon.sadetsky at oracle.com Tue Jun 2 16:12:00 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Tue, 02 Jun 2015 19:12:00 +0300 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <556DD007.7080900@oracle.com> References: <556DCB7F.2020104@oracle.com> <556DCDA2.9080607@oracle.com> <556DD007.7080900@oracle.com> Message-ID: <556DD5D0.7000308@oracle.com> The repository version should be buildable on all platforms without any source code modifications, shouldn't it? --Semyon On 6/2/2015 6:47 PM, Phil Race wrote: > E_STATEMENT_NOT_REACHED is a favourite of SunStudio and > I recently fixed one such warning (in closed code so I can't point to > it here) > but I did not see this one .. however I was using jprt and locally > Solaris 10 SPARC. So perhaps it is something to do with the headers ? > > Ironically the warning is apparently due to an attempt to suppress > a previous warning :-( > .. > _exit(-1); > return 0; /* Suppress warning "no return value from function" */ > } > .. > > -phil. > > On 06/02/2015 08:37 AM, Erik Joelsson wrote: >> Hello Semyon, >> >> Solaris Studio 12.3 is the correct version. However, internally we >> use devkits with the compiler and system headers/libraries all >> packaged together (details in separate mail). The devkits still use >> headers and libraries from Solaris 10u10 for compatibility with that >> release. We normally run the build on Solaris 11.1. >> >> /Erik >> >> On 2015-06-02 17:27, Semyon Sadetsky wrote: >>> Hi, >>> >>> I'm trying to build jdk9 under the current Solaris 11.2 version. >>> Which version of the Solaris Studio should be installed for that? >>> The readme-builds states: >>> ... >>> At a minimum, the Studio 12 Update 1 Compilers (containing version >>> 5.10 of the C and C++ compilers) is required, including specific >>> patches. >>> ... >>> Currently there are 3 versions currently available for downloading: >>> >>> Oracle Solaris Studio 12.2 >>> Oracle Solaris Studio 12.3 >>> Oracle Solaris Studio 12.4 >>> >>> I tried all 3 and only with 12.3 I do no receive build warnings >>> about wrong compiler version, >>> but my build constantly fails with 12.3 with the next message: >>> >>> Compiling 246 files for jdk.jdi >>> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", >>> line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", >>> line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>> ld: fatal: file >>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: >>> not an ELF object >>> gmake[3]: *** >>> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] >>> Error 2 >>> gmake[3]: *** Waiting for unfinished jobs.... >>> gmake[2]: *** [java.base-libs] Error 1 >>> >>> Even --disable-warnings-as-errors option does not save the build >>> from failure. >>> Could you send me the software list with the versions that should be >>> installed on a clean Solaris 11.2 instance to have the build running >>> smoothly? >>> >>> Thank you, >>> --Semyon >>> >>> >>> >> > From tim.bell at oracle.com Tue Jun 2 16:46:51 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 02 Jun 2015 09:46:51 -0700 Subject: [8u60] Request for review and approval: JDK-8074523: Windows native binaries have inconsistent "Product version" In-Reply-To: <556DCB1B.9020104@oracle.com> References: <555C7EF6.1010208@oracle.com> <555C82E1.6010606@oracle.com> <555C95A4.5010801@oracle.com> <556449E9.9040807@oracle.com> <5565CF1B.1030407@oracle.com> <556DCB1B.9020104@oracle.com> Message-ID: <556DDDFB.5000705@oracle.com> Hi Erik: > I still need an 8u reviewer, anyone? Line 534 in jdk-options.m4 needs to line up with the following comment lines. Otherwise, this looks good. No need to respin the webrev after fixing the white space. Tim > On 2015-05-27 16:05, Magnus Ihse Bursie wrote: >> On 2015-05-26 12:24, Erik Joelsson wrote: >>> Any chance I could get a review on this? >> >> Yeah, if you ask nicely, with sugar on top. ;-) >> >> Fix looks good to me. Thanks for taking care of this. >> >> /Magnus >> >>> >>> /Erik >>> >>> On 2015-05-20 16:09, Erik Joelsson wrote: >>>> Thanks, changed to: Windows native binaries have inconsistent >>>> "Product version" >>>> >>>> Changed the label. >>>> >>>> /Erik >>>> >>>> On 2015-05-20 14:49, Se?n Coffey wrote: >>>>> It might be good to edit the bug synopsis before pushing the >>>>> change. I don't think this issue is specific to java.net bundles. >>>>> Might also be useful to use the noreg-sqe label rather than >>>>> noreg-build given that SQE team do appear to have test code for >>>>> this area. >>>>> >>>>> Approved pending code review. >>>>> >>>>> Regards, >>>>> Sean. >>>>> >>>>> On 20/05/15 13:32, Erik Joelsson wrote: >>>>>> Please review and approve this fix for 8u60. >>>>>> >>>>>> On windows, native libraries and executables have version numbers >>>>>> embedded into them. These can be seen when right-clicking the >>>>>> binary in explorer, on the Details tab, as "Product version". >>>>>> Currently in 8 update releases, these versions strings are >>>>>> inconsistent. An example: >>>>>> >>>>>> in 8u45 b09 we have: >>>>>> >>>>>> bin\client\jvm.dll: 8.0.0.9 >>>>>> bin\decora_sse.dll: 8.0.45.09 >>>>>> bin\deploy.dll: 8.0.450.9 >>>>>> bin\java.exe: 8.0.45.9 >>>>>> >>>>>> These differences fall into 4 different categories. >>>>>> >>>>>> 1. jvm.dll in hotspot is not picking up the update version at >>>>>> all. This is due to a bug in the build-infra makefile rewrite >>>>>> that wasn't discovered in JDK 8 because it didn't have an update >>>>>> version. >>>>>> >>>>>> 2. decora_sse.dll is part of javafx. Fixing their version scheme >>>>>> is out of scope of this fix. A separate bug for javafx would be >>>>>> needed. >>>>>> >>>>>> 3. deploy.dll is actually the correct one. Historically we have >>>>>> encoded the update version with an extra digit for a potential >>>>>> letter at the end of the string. >>>>>> >>>>>> 4. java.exe, and the rest of the binaries from the jdk repository >>>>>> lost their extra 0 in the build-infra makefile rewrite and it >>>>>> wasn't discovered in JDK 8. >>>>>> >>>>>> Since we no longer use letters in update version strings, we >>>>>> could fix this by removing the extra 0. However, we have already >>>>>> released 8 updates where some binaries have the extra 0. Removing >>>>>> it would mean releasing 8u60 with binaries having version numbers >>>>>> lower than previous updates. For this reason I propose fixing >>>>>> this by adding the 0 for JDK and Hotspot binaries again, and of >>>>>> course by supplying the correct variable to the hotspot makefiles >>>>>> so that it even gets the update version in there. For clarity, >>>>>> with this patch, the above will log like this: >>>>>> >>>>>> bin\client\jvm.dll: 8.0.450.9 >>>>>> bin\decora_sse.dll: 8.0.45.09 >>>>>> bin\deploy.dll: 8.0.450.9 >>>>>> bin\java.exe: 8.0.450.9 >>>>>> >>>>>> Note that in JDK 9, the version number scheme is being completely >>>>>> reworked so this will not be an issue. >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8074523 >>>>>> Webrev: >>>>>> http://cr.openjdk.java.net/~erikj/8074523/webrev.01/index.html >>>>>> >>>>>> /Erik >>>>> >>>> >>> >> > From jan.lahoda at oracle.com Tue Jun 2 16:50:52 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 02 Jun 2015 18:50:52 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556DB7E9.7090709@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> Message-ID: <556DDEEC.2000505@oracle.com> Hello Eric, Thanks for the change, this seems definitely better to me. I've folded your change that into my patch. An updated version (just langtools this time): http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ Thanks! Jan On 2.6.2015 16:04, Erik Joelsson wrote: > Hello Jan, > > Sorry to bother you with even more build changes, but with these file > moves, I realized that this new file, ct.sym, is really a part of the > jdk.compiler module and really not a special case at all. Because of > this, it should be generated as part of the jdk.compiler-gendata target. > This also eliminates all the changes in the top level repo and only > leaves one new makefile in the langtools repo. > > http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ > > /Erik > > On 2015-06-01 17:56, Jan Lahoda wrote: >> Hi, >> >> I made a somewhat bigger update (partially based on other feedback). >> Summary of changes: >> -the history data has been moved into langtools (I also moved the >> Ctsym.gmk) >> -there are JDK 6 data now >> -renamed the "-platform" option to "-release". Code/tests directly >> related to the option has been also changed as well. I kept the >> internal PlatformProvider API in javac as is, and also kept related code. >> -added a note that the is generated by >> CreateSymbols. >> >> Webrevs: >> top-level: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >> langtools: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >> >> Delta webrevs are also available. >> >> How does this look? >> >> Thanks for the comments so far! >> >> Jan >> >> On 27.5.2015 14:23, Jan Lahoda wrote: >>> Ah, yes, I did not realize that. Thanks, will fix. >>> >>> Thanks, >>> Jan >>> >>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>> don't mention the fact that a side effect of the sym.txt generation is >>>> the mentioned earlier in the same comments >>>> (so one might wonder where does that come from). >>>> >>>> Maurizio >>>> >>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I've uploaded another iteration, with these changes: >>>>> -the "symbols" file is now generated automatically (for the typical >>>>> OpenJDK case). >>>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>>> description into wrong a file (the "break" -> "break OUTER;" change). >>>>> -jdk.management module has been split out from java.management >>>>> recently, so splitting the corresponding .sym.txt files into >>>>> java.management and jdk.management as well. >>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>> >>>>> Webrevs: >>>>> -top-level: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>> -langtools (no changes against the last webrev): >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>> >>>>> Delta webrevs against the previous iteration are included under >>>>> "Author comments". >>>>> >>>>> Thanks for the comments so far! >>>>> >>>>> Jan >>>>> >>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>> Excellent work. >>>>>>> >>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>> Probe >>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>> >>>>>>> /bin/java Probe --> classes-8 >>>>>>> /bin/java Probe --> classes-7 >>>>>>> /bin/java Probe --> classes-7 >>>>>>> >>>>>>> etc. >>>>>> >>>>>> Sure, will do. >>>>>> >>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>> descriptions >>>>>> automatically, per our offline discussion. >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Jan >>>>>> >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>> top-level repository: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>> langtools: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>> >>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>> differences >>>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>>> "Author's comments") >>>>>>>> >>>>>>>> Summary of changes: >>>>>>>> -applied Eric's build changes >>>>>>>> -moved CreateSymbols into >>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>> -tried to improve the specification of base platforms in >>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Jan >>>>>>>> >>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>> Hi Jan, >>>>>>>>> great work - couple of comments below: >>>>>>>>> >>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>> simplified >>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>> checkOptionAllowed >>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>> commonalities >>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>> this a >>>>>>>>> bit? >>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>> specified >>>>>>>>> and >>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>> that, >>>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>> logic in >>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>> CreateSymbols >>>>>>>>> with >>>>>>>>> how the files were laid out. I think in the end, what you mean is >>>>>>>>> that >>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>> (i.e. 8) >>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>> that's the >>>>>>>>> use >>>>>>>>> case, I think the command line can be simplified a bit in order to >>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>> the >>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>> seem to be typically all >>>>>>>>> identical >>>>>>>>> but one which is set to - the one for the baseline). Maybe >>>>>>>>> the >>>>>>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>>>>>> 7 and >>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>> should be >>>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>>> there >>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>> >>>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>> >>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>> >>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>> >>>>>>>>>> These changes also require additional langtools changes as their >>>>>>>>>> prerequisite: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>> >>>>>>>>>> Overall, one can imagine '-platform N' to have the same effect as >>>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>>> values >>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>> correspond to >>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>> >>>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>>> N. The >>>>>>>>>> proposal is to include history data in the textual format inside >>>>>>>>>> the >>>>>>>>>> OpenJDK repositories (the input data), process them at build time >>>>>>>>>> and >>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. javac >>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>> lib/ct.sym >>>>>>>>>> file. The input history data are placed >>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>> This >>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>> public >>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>> >>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>> checkout and >>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>> significantly >>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>> would >>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>> >>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>> them as >>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>> Code >>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>> named >>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>> bootclasspath >>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>> 'N' in >>>>>>>>>> their name. >>>>>>>>>> >>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>> Concise >>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>> >>>>>>>>>> I am sending this as one review, as the changes together make one >>>>>>>>>> feature, but the langtools and top-level changes are independent >>>>>>>>>> to a >>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>> and the >>>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>>> ct.sym >>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>> independently. >>>>>>>>>> >>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>> Alan >>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>> matter >>>>>>>>>> before. >>>>>>>>>> >>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jan >>>>>>>>> >>>>>>> >>>> > From joe.darcy at oracle.com Tue Jun 2 20:04:19 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 02 Jun 2015 13:04:19 -0700 Subject: Request for guidance on fixing JDK-8075571: Support tier1 and tier2 make targets Message-ID: <556E0C43.1010204@oracle.com> Hello makefile gurus, To provide the next level of support to the tiered testing policy [1], I'd like to get some advice on how best to tackle JDK-8075571: Support tier1 and tier2 make targets From the bug, currently one can invoke test groups like so: make test-only TEST=jdk_lang That this, this above make command will run the tests in the ":jdk_lang" test group. By applying the simple edit diff -r df4d75f58f15 test/Makefile --- a/test/Makefile Thu May 28 11:31:40 2015 -0700 +++ b/test/Makefile Tue Jun 02 13:00:06 2015 -0700 @@ -263,7 +263,7 @@ # ------------------------------------------------------------------ -jdk_% core_% svc_%: +jdk_% core_% svc_% tier%: $(ECHO) "Running tests: $@" for each in $@; do \ $(MAKE) -j 1 TEST_SELECTION=":$$each" UNIQUE_DIR=$$each jtreg_tests; \ to the test/Makefile, I was hoping make test-only TEST=tier1 would in turn be able to run the ":tier1" test group. But alas, that does not occur and I don't see what is (not) happening for that omission to take place. Thanks, -Joe [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html From joe.darcy at oracle.com Tue Jun 2 20:23:55 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 02 Jun 2015 13:23:55 -0700 Subject: Request for guidance on fixing JDK-8075571: Support tier1 and tier2 make targets In-Reply-To: <556E0C43.1010204@oracle.com> References: <556E0C43.1010204@oracle.com> Message-ID: <556E10DB.4090608@oracle.com> PS It is a bit lame, but if new new definitions are put into the jdk/test/TEST.groups file diff -r df4d75f58f15 test/TEST.groups --- a/test/TEST.groups Thu May 28 11:31:40 2015 -0700 +++ b/test/TEST.groups Tue Jun 02 13:21:06 2015 -0700 @@ -42,6 +42,9 @@ :jdk_other \ :jdk_svc +jdk_tier1 = :tier1 +jdk_tier2 = :tier2 + ############################################################################### # # Other test definitions; generally smaller granularity than tiers then make test TEST="jdk_tier1" does what is wanted, at least for the jdk repo. I don't know if invoking test targets is supported for repos other than jdk. Thanks, -Joe On 6/2/2015 1:04 PM, joe darcy wrote: > Hello makefile gurus, > > To provide the next level of support to the tiered testing policy [1], > I'd like to get some advice on how best to tackle > > JDK-8075571: Support tier1 and tier2 make targets > > From the bug, currently one can invoke test groups like so: > > make test-only TEST=jdk_lang > > That this, this above make command will run the tests in the > ":jdk_lang" test group. By applying the simple edit > > diff -r df4d75f58f15 test/Makefile > --- a/test/Makefile Thu May 28 11:31:40 2015 -0700 > +++ b/test/Makefile Tue Jun 02 13:00:06 2015 -0700 > @@ -263,7 +263,7 @@ > > # ------------------------------------------------------------------ > > -jdk_% core_% svc_%: > +jdk_% core_% svc_% tier%: > $(ECHO) "Running tests: $@" > for each in $@; do \ > $(MAKE) -j 1 TEST_SELECTION=":$$each" UNIQUE_DIR=$$each > jtreg_tests; \ > > to the test/Makefile, I was hoping > > make test-only TEST=tier1 > > would in turn be able to run the ":tier1" test group. But alas, that > does not occur and I don't see what is (not) happening for that > omission to take place. > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html From jonathan.gibbons at oracle.com Tue Jun 2 21:21:30 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 02 Jun 2015 14:21:30 -0700 Subject: Request for guidance on fixing JDK-8075571: Support tier1 and tier2 make targets In-Reply-To: <556E0C43.1010204@oracle.com> References: <556E0C43.1010204@oracle.com> Message-ID: <556E1E5A.9080304@oracle.com> Joe, The magic you need to manipulate is lines 54-71 (approx) in test/Makefile. # Default test target (core) default: jdk_core langtools_jtreg jaxp_all # All testing all: jdk_all langtools_all jaxp_all # Test targets langtools_% : @$(NO_STOPPING)$(call SUBDIR_TEST, $(LANGTOOLS_DIR), JT_JAVA=$(PRODUCT_HOME) JTREG_HOME=$(JT_HOME) TEST="$(subst langtools_,,$@)" $(subst langtools_,,$@)) jdk_% core_%s svc_%: @$(NO_STOPPING)$(call SUBDIR_TEST, $(JDK_DIR), TEST="$@" $@) jaxp_%: @$(NO_STOPPING)$(call SUBDIR_TEST, $(JAXP_DIR), TEST="$@" $@) hotspot_%: @$(NO_STOPPING)$(call SUBDIR_TEST, $(HOTSPOT_DIR), TEST="$@" $@) These lines set up how test targets are mapped into individual targets in the individual repos. Note the pattern-matching rules for langtools_%, jdk_%, jaxp_%, hotspot% To add a new top level :tier1 target, I would copy the "all" target and add something like tier1: jdk_tier1 langtools_tier1 jaxp_tier1 (i.e. delegating to all repos that support a :tier1 test target). You will want to add a tier1 target into langtools/test/Makefile for this to work, because the langtools_% target strips off the "langtools_" prefix For other repos, make sure there is a jdk-tier1 target, jaxp-tier1 target, etc, since no prefix stripping is done on those targets. You might want to consider whether to (or not to) run the test targets in parallel. Depending how the individual repo test targets are set up, you could easily swamp your machine if you run too many invocations of jtreg in parallel. -- Jon On 06/02/2015 01:04 PM, joe darcy wrote: > Hello makefile gurus, > > To provide the next level of support to the tiered testing policy [1], > I'd like to get some advice on how best to tackle > > JDK-8075571: Support tier1 and tier2 make targets > > From the bug, currently one can invoke test groups like so: > > make test-only TEST=jdk_lang > > That this, this above make command will run the tests in the > ":jdk_lang" test group. By applying the simple edit > > diff -r df4d75f58f15 test/Makefile > --- a/test/Makefile Thu May 28 11:31:40 2015 -0700 > +++ b/test/Makefile Tue Jun 02 13:00:06 2015 -0700 > @@ -263,7 +263,7 @@ > > # ------------------------------------------------------------------ > > -jdk_% core_% svc_%: > +jdk_% core_% svc_% tier%: > $(ECHO) "Running tests: $@" > for each in $@; do \ > $(MAKE) -j 1 TEST_SELECTION=":$$each" UNIQUE_DIR=$$each > jtreg_tests; \ > > to the test/Makefile, I was hoping > > make test-only TEST=tier1 > > would in turn be able to run the ":tier1" test group. But alas, that > does not occur and I don't see what is (not) happening for that > omission to take place. > > Thanks, > > -Joe > > [1] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html From david.holmes at oracle.com Wed Jun 3 04:41:03 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 03 Jun 2015 14:41:03 +1000 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <556DD5D0.7000308@oracle.com> References: <556DCB7F.2020104@oracle.com> <556DCDA2.9080607@oracle.com> <556DD007.7080900@oracle.com> <556DD5D0.7000308@oracle.com> Message-ID: <556E855F.4070100@oracle.com> On 3/06/2015 2:12 AM, Semyon Sadetsky wrote: > The repository version should be buildable on all platforms without any > source code modifications, shouldn't it? The repository version should build with Studio12u3 on Solaris 10u6, or Solaris 10u10. However if you want to build on Solaris 11.x then you need to use a "devkit" (as Erik mentioned) that uses the S10u6 or S10u10 system headers. Otherwise you will need to pass --disable-warnings-as-errors to configure (but even that might not be enough). David > --Semyon > > On 6/2/2015 6:47 PM, Phil Race wrote: >> E_STATEMENT_NOT_REACHED is a favourite of SunStudio and >> I recently fixed one such warning (in closed code so I can't point to >> it here) >> but I did not see this one .. however I was using jprt and locally >> Solaris 10 SPARC. So perhaps it is something to do with the headers ? >> >> Ironically the warning is apparently due to an attempt to suppress >> a previous warning :-( >> .. >> _exit(-1); >> return 0; /* Suppress warning "no return value from function" */ >> } >> .. >> >> -phil. >> >> On 06/02/2015 08:37 AM, Erik Joelsson wrote: >>> Hello Semyon, >>> >>> Solaris Studio 12.3 is the correct version. However, internally we >>> use devkits with the compiler and system headers/libraries all >>> packaged together (details in separate mail). The devkits still use >>> headers and libraries from Solaris 10u10 for compatibility with that >>> release. We normally run the build on Solaris 11.1. >>> >>> /Erik >>> >>> On 2015-06-02 17:27, Semyon Sadetsky wrote: >>>> Hi, >>>> >>>> I'm trying to build jdk9 under the current Solaris 11.2 version. >>>> Which version of the Solaris Studio should be installed for that? >>>> The readme-builds states: >>>> ... >>>> At a minimum, the Studio 12 Update 1 Compilers (containing version >>>> 5.10 of the C and C++ compilers) is required, including specific >>>> patches. >>>> ... >>>> Currently there are 3 versions currently available for downloading: >>>> >>>> Oracle Solaris Studio 12.2 >>>> Oracle Solaris Studio 12.3 >>>> Oracle Solaris Studio 12.4 >>>> >>>> I tried all 3 and only with 12.3 I do no receive build warnings >>>> about wrong compiler version, >>>> but my build constantly fails with 12.3 with the next message: >>>> >>>> Compiling 246 files for jdk.jdi >>>> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", >>>> line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", >>>> line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>> ld: fatal: file >>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: >>>> not an ELF object >>>> gmake[3]: *** >>>> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] >>>> Error 2 >>>> gmake[3]: *** Waiting for unfinished jobs.... >>>> gmake[2]: *** [java.base-libs] Error 1 >>>> >>>> Even --disable-warnings-as-errors option does not save the build >>>> from failure. >>>> Could you send me the software list with the versions that should be >>>> installed on a clean Solaris 11.2 instance to have the build running >>>> smoothly? >>>> >>>> Thank you, >>>> --Semyon >>>> >>>> >>>> >>> >> > From joe.darcy at oracle.com Wed Jun 3 05:52:24 2015 From: joe.darcy at oracle.com (joe darcy) Date: Tue, 02 Jun 2015 22:52:24 -0700 Subject: Request for guidance on fixing JDK-8075571: Support tier1 and tier2 make targets In-Reply-To: <556E1E5A.9080304@oracle.com> References: <556E0C43.1010204@oracle.com> <556E1E5A.9080304@oracle.com> Message-ID: <556E9618.600@oracle.com> Thanks for the pointers Jon. A not-quite-finished version of this work is up at http://cr.openjdk.java.net/~darcy/8075571.0/ The nashorn test makefile is copied from the jaxp one with s/jaxp/nashorn/g. While I'm at it, I think it is worthwhile to add support nominal support for tier 3 tests since there are at least some tier 3 tests we'll want to add in the future. The top-level filtering of the langtools targets isn't quite working as desired; a colon to indicate a test group is not getting passed along. Some different filtering of the langtools arguments is needed? Thanks, -Joe On 6/2/2015 2:21 PM, Jonathan Gibbons wrote: > Joe, > > The magic you need to manipulate is lines 54-71 (approx) in > test/Makefile. > > # Default test target (core) > default: jdk_core langtools_jtreg jaxp_all > > # All testing > all: jdk_all langtools_all jaxp_all > > # Test targets > langtools_% : > @$(NO_STOPPING)$(call SUBDIR_TEST, $(LANGTOOLS_DIR), > JT_JAVA=$(PRODUCT_HOME) JTREG_HOME=$(JT_HOME) TEST="$(subst > langtools_,,$@)" $(subst langtools_,,$@)) > > jdk_% core_%s svc_%: > @$(NO_STOPPING)$(call SUBDIR_TEST, $(JDK_DIR), TEST="$@" $@) > > jaxp_%: > @$(NO_STOPPING)$(call SUBDIR_TEST, $(JAXP_DIR), TEST="$@" $@) > > hotspot_%: > @$(NO_STOPPING)$(call SUBDIR_TEST, $(HOTSPOT_DIR), TEST="$@" $@) > > > These lines set up how test targets are mapped into individual targets > in the individual repos. Note the pattern-matching rules for > langtools_%, jdk_%, jaxp_%, hotspot% > > To add a new top level :tier1 target, I would copy the "all" target > and add something like > > tier1: jdk_tier1 langtools_tier1 jaxp_tier1 > > (i.e. delegating to all repos that support a :tier1 test target). > > You will want to add a tier1 target into langtools/test/Makefile for > this to work, because the langtools_% target strips off the > "langtools_" prefix > For other repos, make sure there is a jdk-tier1 target, jaxp-tier1 > target, etc, since no prefix stripping is done on those targets. > > You might want to consider whether to (or not to) run the test targets > in parallel. Depending how the individual repo test targets are set > up, you could easily swamp your machine if you run too many > invocations of jtreg in parallel. > > -- Jon > > > > > > On 06/02/2015 01:04 PM, joe darcy wrote: >> Hello makefile gurus, >> >> To provide the next level of support to the tiered testing policy >> [1], I'd like to get some advice on how best to tackle >> >> JDK-8075571: Support tier1 and tier2 make targets >> >> From the bug, currently one can invoke test groups like so: >> >> make test-only TEST=jdk_lang >> >> That this, this above make command will run the tests in the >> ":jdk_lang" test group. By applying the simple edit >> >> diff -r df4d75f58f15 test/Makefile >> --- a/test/Makefile Thu May 28 11:31:40 2015 -0700 >> +++ b/test/Makefile Tue Jun 02 13:00:06 2015 -0700 >> @@ -263,7 +263,7 @@ >> >> # ------------------------------------------------------------------ >> >> -jdk_% core_% svc_%: >> +jdk_% core_% svc_% tier%: >> $(ECHO) "Running tests: $@" >> for each in $@; do \ >> $(MAKE) -j 1 TEST_SELECTION=":$$each" UNIQUE_DIR=$$each >> jtreg_tests; \ >> >> to the test/Makefile, I was hoping >> >> make test-only TEST=tier1 >> >> would in turn be able to run the ":tier1" test group. But alas, that >> does not occur and I don't see what is (not) happening for that >> omission to take place. >> >> Thanks, >> >> -Joe >> >> [1] >> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html > From david.holmes at oracle.com Wed Jun 3 08:07:24 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 03 Jun 2015 18:07:24 +1000 Subject: Solaris jdk9 build problem In-Reply-To: <556DB48B.2080003@oracle.com> References: <556CAFB5.3070407@oracle.com> <556CEC2A.30504@oracle.com> <556D4B24.9010201@oracle.com> <556D6D96.1080605@oracle.com> <556D7688.5090000@oracle.com> <556D8039.3000400@oracle.com> <556D817F.8090206@oracle.com> <556D83D7.5020206@oracle.com> <556D8671.4070501@oracle.com> <556D8832.8090508@oracle.com> <556DADF0.40604@oracle.com> <556DB48B.2080003@oracle.com> Message-ID: <556EB5BC.2080905@oracle.com> On 2/06/2015 11:50 PM, Magnus Ihse Bursie wrote: > On 2015-06-02 15:21, Semyon Sadetsky wrote: >> Hello, >> >> Hate to disturb you again but I got yet another show stopper for my >> Solaris build: >> >> Generating solaris_amd64_docs/jvmti.html >> Creating libverify.so from 2 file(s) >> Creating libjava.so from 60 file(s) >> Creating libfdlibm.a from 62 file(s) >> Creating libzip.so from 21 file(s) >> Creating libjli.so from 15 file(s) >> Creating libnet.so from 21 file(s) >> Creating libnio.so from 23 file(s) >> Compiling 3 properties into resource bundles for jdk.jdi >> Compiling 246 files for jdk.jdi >> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line >> 384: error: statement not reached (E_STATEMENT_NOT_REACHED) >> cc: acomp failed for >> /jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c >> gmake[3]: *** >> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/native/java.base/libjava/childproc.o] >> Error 2 >> gmake[3]: *** Waiting for unfinished jobs.... >> gmake[2]: *** [java.base-libs] Error 1 > > I belive the rest of the log says: "please try again with > --disable-warnings-as-errors" or something like that. > > Do it! :) > > An even better solution is to investigate the warning and fix the code. > > I can't really say why you're getting this warning, though. Your version > of the compiler might differ too much from the official ones. It isn't the version of the compiler but the version of the header files that is too new. They have the "no return" attribute so the compiler complains that a following statement is unreachable. As per the other thread on this you either need to use a Solaris 10u6 or 10u10 build machine, or else use a devkit with those headers. David > /Magnus > >> >> --Semyon >> >> >> >> On 6/2/2015 1:40 PM, Semyon Sadetsky wrote: >>> >>> On 6/2/2015 1:33 PM, Magnus Ihse Bursie wrote: >>>> On 2015-06-02 12:22, David Holmes wrote: >>>>> On 2/06/2015 8:12 PM, Semyon Sadetsky wrote: >>>>>> >>>>>> On 6/2/2015 1:06 PM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-06-02 11:25, Semyon Sadetsky wrote: >>>>>>>> >>>>>>>> On 6/2/2015 11:47 AM, Magnus Ihse Bursie wrote: >>>>>>>>> On 2015-06-02 08:20, Semyon Sadetsky wrote: >>>>>>>>>> On 6/2/2015 2:35 AM, Magnus Ihse Bursie wrote: >>>>>>>>>>> On 2015-06-01 21:17, Semyon Sadetsky wrote: >>>>>>>>>>>> Hello, >>>>>>>>>>>> >>>>>>>>>>>> Could you help me to resolve 9 build problem on Solaris 11.2: >>>>>>>>>>>> >>>>>>>>>>>> /usr/ccs/bin/nm: solaris_x86_64.o: No such file or directory >>>>>>>>>>>> gmake[8]: *** [libjvm.so] Error 1 >>>>>>>>>>>> gmake[8]: Leaving directory >>>>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> gmake[7]: *** [the_vm] Error 2 >>>>>>>>>>>> gmake[7]: Leaving directory >>>>>>>>>>>> `/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/hotspot/solaris_amd64_compiler2/fastdebug' >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> and earlier in the log: >>>>>>>>>>>> >>>>>>>>>>>> Assembling >>>>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>>>> rm -f solaris_x86_64.o >>>>>>>>>>>> xarch=amd64 -o solaris_x86_64.o >>>>>>>>>>>> /jdk9/client/hotspot/src/os_cpu/solaris_x86/vm/solaris_x86_64.s >>>>>>>>>>>> /usr/bin/bash: -o: command not found >>>>>>>>>>>> gmake[8]: [solaris_x86_64.o] Error 127 (ignored) >>>>>>>>>>>> Compiling /jdk9/client/hotspot/src/share/vm/gc/shared/space.cpp >>>>>>>>>>>> rm -f space.o >>>>>>>>>>>> /opt/solarisstudio12.3/bin/CC -DSOLARIS -DSPARC_WORKS - >>>>>>>>>>>> ... >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> I guess there should be cc before xarch, but it's omited. >>>>>>>>>>> I'm guessing that .s is an assembly file, so most likely it is >>>>>>>>>>> $(AS) that resolves to empty. Can you check your spec.gmk for >>>>>>>>>>> the >>>>>>>>>>> value of AS? >>>>>>>>>>> >>>>>>>>>>> /Magnus >>>>>>>>>>> >>>>>>>>>> Yes, AS was empty. >>>>>>>>>> after I set it to /opt/solarisstudio12.3/bin/cc the first error >>>>>>>>>> message has gone but then I got: >>>>>>>>> You cannot set it manually. If configure has failed to detect it, >>>>>>>>> all bets are off. I'm a bit surprised that configure allowed AS to >>>>>>>>> be empty, it should have aborted. >>>>>>>>> >>>>>>>>> Try running configure with >>>>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin. Does that >>>>>>>>> help you >>>>>>>>> get a proper value of AS. >>>>>>>>> >>>>>>>>> /Magnus >>>>>>>> >>>>>>>> AS remains empty: >>>>>>>> ==================================================== >>>>>>>> A new configuration has been successfully created in >>>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug >>>>>>>> using configure arguments '--enable-debug >>>>>>>> --with-toolchain-path=/opt/solarisstudio12.3/bin'. >>>>>>>> >>>>>>>> Configuration summary: >>>>>>>> * Debug level: fastdebug >>>>>>>> * HS debug level: fastdebug >>>>>>>> * JDK variant: normal >>>>>>>> * JVM variants: server >>>>>>>> * OpenJDK target: OS: solaris, CPU architecture: x86, address >>>>>>>> length: 64 >>>>>>>> >>>>>>>> Tools summary: >>>>>>>> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime >>>>>>>> Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM >>>>>>>> (build 25.45-b02, mixed mode) (at /usr/jdk/instances/jdk1.8.0_45) >>>>>>>> * Toolchain: solstudio (Oracle Solaris Studio) >>>>>>>> * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) >>>>>>>> * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) >>>>>>>> >>>>>>>> Build performance summary: >>>>>>>> * Cores to use: 2 >>>>>>>> * Memory limit: 2048 MB >>>>>>>> >>>>>>>> dev at solaris1:/jdk9/client$ grep "AS:" >>>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/spec.gmk >>>>>>>> AS:= >>>>>>> >>>>>>> Do you have an as in your path or in /opt/solarisstudio12.3/bin >>>>>>> then? >>>>>>> Have you even built jdk successfully on this machine? >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>> No it's a new installation. And I'm building jdk on Solaris for the >>>>>> first time. >>>>>> as is absent in /opt/solarisstudio12.3/bin. >>>>>> >>>>>> dev at solaris1:/jdk9/client$ ls /opt/solstudio12.2/bin >>>>>> CC cscope er_bit f90 >>>>>> rtc_patch_area sunf90 >>>>>> CCadmin ctc er_cp f95 >>>>>> rxm sunf95 >>>>>> amd64 ctcr er_export fbe rxs sunstudio >>>>>> analyzer ctrace er_generic fdumpmod smctl tcov >>>>>> bcheck cxref er_html fpp >>>>>> solstudio tha >>>>>> binopt dbx er_kernel fpr >>>>>> spot uncover >>>>>> c++filt dbxtool er_mpipp fsplit spot_diff >>>>>> version >>>>>> c89 dem er_mv gen_custom >>>>>> ss_attach whatdir >>>>>> c99 discover er_otfdump getmsg sunCC >>>>>> xprof_atob >>>>>> cb dlight er_print indent sunas >>>>>> xprof_btoa >>>>>> cc dmake er_rm lint sunc89 >>>>>> cc-5.0 dumpstabs er_src lock_lint sunc99 >>>>>> cflow dwarfdump er_vtunify ptclean suncc >>>>>> collect er_archive f77 ripc sunf77 >>>>>> >>>>>> Should it be there? >>>>> >>>>> No it is in a separate package apparently (not installed by default >>>>> on Solaris 11): >>>>> >>>>> pkg install pkg:/developer/assembler >>>> >>>> Thanks for the information David! >>>> >>>> I opened https://bugs.openjdk.java.net/browse/JDK-8081676 to track >>>> that we should verify that AS is properly detected on Solaris, and >>>> to print the help about pkg install in case as is missing. >>>> >>>> /Magnus >>>> >>> Possible it would be worth to add this information to the readme as >>> well. On other linuxes gcc is used instead of as and configure does >>> not produce any warnings about it. It is not trivial to find the >>> reason for people building solaris jdk for the first time. >>> >>> --Semyon >>> >>>>> >>>>> David >>>>> ----- >>>>> >>>>>> >>>>>> >>>>>>>> dev at solaris1:/jdk9/client$ >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> cc: Warning: -xarch=amd64 is deprecated, use -m64 to create >>>>>>>>>> 64-bit >>>>>>>>>> programs >>>>>>>>>> ld: fatal: file solaris_x86_64.o: not an ELF object >>>>>>>>>> gmake[8]: *** [solaris_x86_64.o] Error 2 >>>>>>>>>> gmake[8]: *** Waiting for unfinished jobs.... >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> >>> >> > From magnus.ihse.bursie at oracle.com Wed Jun 3 08:28:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 03 Jun 2015 10:28:55 +0200 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <556DCB7F.2020104@oracle.com> References: <556DCB7F.2020104@oracle.com> Message-ID: <556EBAC7.9080009@oracle.com> On 2015-06-02 17:27, Semyon Sadetsky wrote: > Hi, > > I'm trying to build jdk9 under the current Solaris 11.2 version. > Which version of the Solaris Studio should be installed for that? The > readme-builds states: > ... > At a minimum, the Studio 12 Update 1 Compilers (containing version > 5.10 of the C and C++ compilers) is required, including specific patches. > ... > Currently there are 3 versions currently available for downloading: > > Oracle Solaris Studio 12.2 > Oracle Solaris Studio 12.3 > Oracle Solaris Studio 12.4 > > I tried all 3 and only with 12.3 I do no receive build warnings about > wrong compiler version, > but my build constantly fails with 12.3 with the next message: > > Compiling 246 files for jdk.jdi > "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line > 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) > "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", > line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) > ld: fatal: file > /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: > not an ELF object > gmake[3]: *** > [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] > Error 2 > gmake[3]: *** Waiting for unfinished jobs.... > gmake[2]: *** [java.base-libs] Error 1 > > Even --disable-warnings-as-errors option does not save the build from > failure. That's because the warning does not cause the build failure. Read the logs again. :-) The real error here is "libjvm.so: not an ELF object" which causes the linking to fail for libverify.so. The warning from libjava is just a red herring. Your hotspot build is broken. Try "make clean-hotspot" "make hotspot" and see if you spot any errors. Otherwise you'd probably just left the build in a bad state. /Magnus > Could you send me the software list with the versions that should be > installed on a clean Solaris 11.2 instance to have the build running > smoothly? > > Thank you, > --Semyon > > > From magnus.ihse.bursie at oracle.com Wed Jun 3 08:35:06 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 03 Jun 2015 10:35:06 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556DDEEC.2000505@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> Message-ID: <556EBC3A.8030605@oracle.com> On 2015-06-02 18:50, Jan Lahoda wrote: > Hello Eric, > > Thanks for the change, this seems definitely better to me. I've folded > your change that into my patch. An updated version (just langtools > this time): > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ > > Thanks! From a build perspective, this looks good - nah, awesome! :) - to me. /Magnus > > Jan > > On 2.6.2015 16:04, Erik Joelsson wrote: >> Hello Jan, >> >> Sorry to bother you with even more build changes, but with these file >> moves, I realized that this new file, ct.sym, is really a part of the >> jdk.compiler module and really not a special case at all. Because of >> this, it should be generated as part of the jdk.compiler-gendata target. >> This also eliminates all the changes in the top level repo and only >> leaves one new makefile in the langtools repo. >> >> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >> >> /Erik >> >> On 2015-06-01 17:56, Jan Lahoda wrote: >>> Hi, >>> >>> I made a somewhat bigger update (partially based on other feedback). >>> Summary of changes: >>> -the history data has been moved into langtools (I also moved the >>> Ctsym.gmk) >>> -there are JDK 6 data now >>> -renamed the "-platform" option to "-release". Code/tests directly >>> related to the option has been also changed as well. I kept the >>> internal PlatformProvider API in javac as is, and also kept related >>> code. >>> -added a note that the is generated by >>> CreateSymbols. >>> >>> Webrevs: >>> top-level: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>> langtools: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>> >>> Delta webrevs are also available. >>> >>> How does this look? >>> >>> Thanks for the comments so far! >>> >>> Jan >>> >>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>> Ah, yes, I did not realize that. Thanks, will fix. >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>> don't mention the fact that a side effect of the sym.txt >>>>> generation is >>>>> the mentioned earlier in the same >>>>> comments >>>>> (so one might wonder where does that come from). >>>>> >>>>> Maurizio >>>>> >>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I've uploaded another iteration, with these changes: >>>>>> -the "symbols" file is now generated automatically (for the typical >>>>>> OpenJDK case). >>>>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>> change). >>>>>> -jdk.management module has been split out from java.management >>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>> java.management and jdk.management as well. >>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>> >>>>>> Webrevs: >>>>>> -top-level: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>> -langtools (no changes against the last webrev): >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>> >>>>>> Delta webrevs against the previous iteration are included under >>>>>> "Author comments". >>>>>> >>>>>> Thanks for the comments so far! >>>>>> >>>>>> Jan >>>>>> >>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>> Excellent work. >>>>>>>> >>>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>>> Probe >>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>> >>>>>>>> /bin/java Probe --> classes-8 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> >>>>>>>> etc. >>>>>>> >>>>>>> Sure, will do. >>>>>>> >>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>> descriptions >>>>>>> automatically, per our offline discussion. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>> top-level repository: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>> langtools: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>> >>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>> differences >>>>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>>>> "Author's comments") >>>>>>>>> >>>>>>>>> Summary of changes: >>>>>>>>> -applied Eric's build changes >>>>>>>>> -moved CreateSymbols into >>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> great work - couple of comments below: >>>>>>>>>> >>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>> simplified >>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>> checkOptionAllowed >>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>> commonalities >>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>> this a >>>>>>>>>> bit? >>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>> specified >>>>>>>>>> and >>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>> that, >>>>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>> logic in >>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>> CreateSymbols >>>>>>>>>> with >>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>> mean is >>>>>>>>>> that >>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>> (i.e. 8) >>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>> that's the >>>>>>>>>> use >>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>> order to >>>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>>> the >>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>> seem to be typically all >>>>>>>>>> identical >>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>> Maybe >>>>>>>>>> the >>>>>>>>>> inference logic should be different (i.e. use 8 as a baseline >>>>>>>>>> for >>>>>>>>>> 7 and >>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>> should be >>>>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>>>> there >>>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>> >>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>> their >>>>>>>>>>> prerequisite: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>> effect as >>>>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>>>> values >>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>> correspond to >>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>> >>>>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>>>> N. The >>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>> inside >>>>>>>>>>> the >>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>> time >>>>>>>>>>> and >>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>> javac >>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>> lib/ct.sym >>>>>>>>>>> file. The input history data are placed >>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>> This >>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>> public >>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>> >>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>> checkout and >>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>> significantly >>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>> would >>>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>>> >>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>> them as >>>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>>> Code >>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>> named >>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>> bootclasspath >>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>> 'N' in >>>>>>>>>>> their name. >>>>>>>>>>> >>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>>> Concise >>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> I am sending this as one review, as the changes together >>>>>>>>>>> make one >>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>> independent >>>>>>>>>>> to a >>>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>>> and the >>>>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>>>> ct.sym >>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>> independently. >>>>>>>>>>> >>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>> Alan >>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>> matter >>>>>>>>>>> before. >>>>>>>>>>> >>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jan >>>>>>>>>> >>>>>>>> >>>>> >> From semyon.sadetsky at oracle.com Wed Jun 3 08:38:57 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Wed, 03 Jun 2015 11:38:57 +0300 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <556EBAC7.9080009@oracle.com> References: <556DCB7F.2020104@oracle.com> <556EBAC7.9080009@oracle.com> Message-ID: <556EBD21.6090805@oracle.com> On 6/3/2015 11:28 AM, Magnus Ihse Bursie wrote: > On 2015-06-02 17:27, Semyon Sadetsky wrote: >> Hi, >> >> I'm trying to build jdk9 under the current Solaris 11.2 version. >> Which version of the Solaris Studio should be installed for that? The >> readme-builds states: >> ... >> At a minimum, the Studio 12 Update 1 Compilers (containing version >> 5.10 of the C and C++ compilers) is required, including specific >> patches. >> ... >> Currently there are 3 versions currently available for downloading: >> >> Oracle Solaris Studio 12.2 >> Oracle Solaris Studio 12.3 >> Oracle Solaris Studio 12.4 >> >> I tried all 3 and only with 12.3 I do no receive build warnings about >> wrong compiler version, >> but my build constantly fails with 12.3 with the next message: >> >> Compiling 246 files for jdk.jdi >> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", >> line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line >> 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >> ld: fatal: file >> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: >> not an ELF object >> gmake[3]: *** >> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] >> Error 2 >> gmake[3]: *** Waiting for unfinished jobs.... >> gmake[2]: *** [java.base-libs] Error 1 >> >> Even --disable-warnings-as-errors option does not save the build from >> failure. > That's because the warning does not cause the build failure. Read the > logs again. :-) > > The real error here is "libjvm.so: not an ELF object" which causes the > linking to fail for libverify.so. The warning from libjava is just a > red herring. > > Your hotspot build is broken. Try > "make clean-hotspot" > "make hotspot" > and see if you spot any errors. Otherwise you'd probably just left the > build in a bad state. > > /Magnus Thank you. In reality it was even worse when I add the option disabling warnings as errors the VM hangs in the middle of the build and those messages I got after restarting it and running the incremental build. This scenario was reproduced 2 times with clean build. So, my next attempt is a clean install with devkits. --Semyon > >> Could you send me the software list with the versions that should be >> installed on a clean Solaris 11.2 instance to have the build running >> smoothly? >> >> Thank you, >> --Semyon >> >> >> > From magnus.ihse.bursie at oracle.com Wed Jun 3 12:33:02 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 03 Jun 2015 14:33:02 +0200 Subject: RFR: JDK-8081692 Configure should verify that -fstack-protector is valid Message-ID: <556EF3FE.6030203@oracle.com> Not all versions of gcc support -fstack-protector. We should check that it is accepted as an argument before adding it to the flags. Bug: https://bugs.openjdk.java.net/browse/JDK-8081692 WebRev inline: diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 --- a/common/autoconf/flags.m4 +++ b/common/autoconf/flags.m4 @@ -338,14 +338,16 @@ # no adjustment ;; slowdebug ) - # Add runtime stack smashing and undefined behavior checks - CFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param ssp-buffer-size=1" - CXXFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param ssp-buffer-size=1" + # Add runtime stack smashing and undefined behavior checks. + # Not all versions of gcc support -fstack-protector + STACK_PROTECTOR_CFLAG="-fstack-protector-all" + FLAGS_COMPILER_CHECK_ARGUMENTS([$STACK_PROTECTOR_CFLAG], [], [STACK_PROTECTOR_CFLAG=""]) + + CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param ssp-buffer-size=1" + CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param ssp-buffer-size=1" ;; esac fi - AC_SUBST(CFLAGS_DEBUG_OPTIONS) - AC_SUBST(CXXFLAGS_DEBUG_OPTIONS) # Optimization levels if test "x$TOOLCHAIN_TYPE" = xsolstudio; then The AC_SUBST removal is just a bit of cleanup, we didn't use the *_DEBUG_OPTIONS in the spec files, just later on when constructing JDK_CFLAGS. /Magnus From erik.joelsson at oracle.com Wed Jun 3 13:12:37 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 03 Jun 2015 15:12:37 +0200 Subject: RFR: JDK-8081692 Configure should verify that -fstack-protector is valid In-Reply-To: <556EF3FE.6030203@oracle.com> References: <556EF3FE.6030203@oracle.com> Message-ID: <556EFD45.6090201@oracle.com> Looks good to me. /Erik On 2015-06-03 14:33, Magnus Ihse Bursie wrote: > Not all versions of gcc support -fstack-protector. We should check > that it is accepted as an argument before adding it to the flags. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081692 > WebRev inline: > > diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -338,14 +338,16 @@ > # no adjustment > ;; > slowdebug ) > - # Add runtime stack smashing and undefined behavior checks > - CFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param > ssp-buffer-size=1" > - CXXFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param > ssp-buffer-size=1" > + # Add runtime stack smashing and undefined behavior checks. > + # Not all versions of gcc support -fstack-protector > + STACK_PROTECTOR_CFLAG="-fstack-protector-all" > + FLAGS_COMPILER_CHECK_ARGUMENTS([$STACK_PROTECTOR_CFLAG], [], > [STACK_PROTECTOR_CFLAG=""]) > + > + CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param > ssp-buffer-size=1" > + CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param > ssp-buffer-size=1" > ;; > esac > fi > - AC_SUBST(CFLAGS_DEBUG_OPTIONS) > - AC_SUBST(CXXFLAGS_DEBUG_OPTIONS) > > # Optimization levels > if test "x$TOOLCHAIN_TYPE" = xsolstudio; then > > The AC_SUBST removal is just a bit of cleanup, we didn't use the > *_DEBUG_OPTIONS in the spec files, just later on when constructing > JDK_CFLAGS. > > /Magnus > From tim.bell at oracle.com Wed Jun 3 14:30:27 2015 From: tim.bell at oracle.com (Tim Bell) Date: Wed, 03 Jun 2015 07:30:27 -0700 Subject: RFR: JDK-8081692 Configure should verify that -fstack-protector is valid In-Reply-To: <556EFD45.6090201@oracle.com> References: <556EF3FE.6030203@oracle.com> <556EFD45.6090201@oracle.com> Message-ID: <556F0F83.9050809@oracle.com> Magnus: Looks good to me as well. Tim On 06/03/15 06:12, Erik Joelsson wrote: > Looks good to me. > > /Erik > > On 2015-06-03 14:33, Magnus Ihse Bursie wrote: >> Not all versions of gcc support -fstack-protector. We should check >> that it is accepted as an argument before adding it to the flags. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8081692 >> WebRev inline: >> >> diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 >> --- a/common/autoconf/flags.m4 >> +++ b/common/autoconf/flags.m4 >> @@ -338,14 +338,16 @@ >> # no adjustment >> ;; >> slowdebug ) >> - # Add runtime stack smashing and undefined behavior checks >> - CFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param >> ssp-buffer-size=1" >> - CXXFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param >> ssp-buffer-size=1" >> + # Add runtime stack smashing and undefined behavior checks. >> + # Not all versions of gcc support -fstack-protector >> + STACK_PROTECTOR_CFLAG="-fstack-protector-all" >> + FLAGS_COMPILER_CHECK_ARGUMENTS([$STACK_PROTECTOR_CFLAG], [], >> [STACK_PROTECTOR_CFLAG=""]) >> + >> + CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param >> ssp-buffer-size=1" >> + CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param >> ssp-buffer-size=1" >> ;; >> esac >> fi >> - AC_SUBST(CFLAGS_DEBUG_OPTIONS) >> - AC_SUBST(CXXFLAGS_DEBUG_OPTIONS) >> >> # Optimization levels >> if test "x$TOOLCHAIN_TYPE" = xsolstudio; then >> >> The AC_SUBST removal is just a bit of cleanup, we didn't use the >> *_DEBUG_OPTIONS in the spec files, just later on when constructing >> JDK_CFLAGS. >> >> /Magnus >> > From daniel.smith at oracle.com Wed Jun 3 17:14:03 2015 From: daniel.smith at oracle.com (Dan Smith) Date: Wed, 3 Jun 2015 11:14:03 -0600 Subject: dist-clean won't delete log files Message-ID: My understanding is that given a properly configured 'dist-clean' will behave as noted: rm -r build sh configure make dist-clean find build -mindepth 1 # no output However, instead I get 3 files: build/macosx-x86_64-normal-server-release build/macosx-x86_64-normal-server-release/build.log build/macosx-x86_64-normal-server-release/configure.log Probably just a matter of tweaking the list of files that dist-clean will delete? ?Dan From valerie.peng at oracle.com Wed Jun 3 17:27:16 2015 From: valerie.peng at oracle.com (Valerie (Yu-Ching) Peng) Date: Wed, 03 Jun 2015 10:27:16 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <556CED19.5050700@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> Message-ID: <556F38F4.4070109@oracle.com> Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. There are other discussions ongoing and we should be able to reach a decision in a day or two. Will update the list again. Thanks, Valerie On 06/01/15 16:39, Magnus Ihse Bursie wrote: > On 2015-05-29 00:10, Valerie Peng wrote: >> >> Please find comments in line... >> >> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>> Valerie, >>> >>> Did you see my comment yesterday? >>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>> >> Yes, we exchanged emails after this above one. I will follow up your >> latest one later today. >> >>> >>> Since you have reverted the java.security to keep the classname, to >>> avoid causing merge conflict to jimage refresh, let?s remove the >>> META-INF files in the first push and the build change. >>> >>> The security providers will be loaded via the fallback mechanism >>> (i.e. ProviderLoader.legacyLoad method). You should keep the >>> ProviderLoader.load method to take the provider name instead of >>> classname. >> Sure, I can remove the META-INF files so the providers are loaded >> through the legacyLoad(). >> Hmm, the ProviderLoader.load() method is used by java.security file >> provider loading. Since the current list still uses class name, it >> should take class name when checking for matches while iterating >> through the list returned by ServiceLoader. >> This way, when changes are sync'ed into Jake, no extra change >> required and the providers will be loaded through >> ProviderLoader.load() automatically with the current list. >> >>> I?ll file a bug to follow up to change java.security to list the >>> provider name. This will wait after the jimage refresh goes into >>> jdk9/dev >> Ok. >> Thanks, >> Valerie > > I'm not sure I followed completely here were this landed. Does this > mean that there's currently no need for a build system code review on > http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a > new webrev will be posted instead? > > /Magnus > > > >>> . >>> >>> Mandy >>> >>>> On May 27, 2015, at 3:29 PM, Valerie Peng >>>> wrote: >>>> >>>> Hi, build experts, >>>> >>>> Can you please review the make file related change, i.e. the new >>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>> >>>> This is for merging the java.security.Provider file from various >>>> providers and use the (merged) result for the final image build. >>>> >>>> The rest of source code changes are reviewed by my team already. >>>> Thanks, >>>> Valerie >>>> (Java Security Team) > From magnus.ihse.bursie at oracle.com Wed Jun 3 19:41:03 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 03 Jun 2015 21:41:03 +0200 Subject: dist-clean won't delete log files In-Reply-To: References: Message-ID: <556F584F.5050400@oracle.com> On 2015-06-03 19:14, Dan Smith wrote: > My understanding is that given a properly configured 'dist-clean' will behave as noted: > > rm -r build > sh configure > make dist-clean > find build -mindepth 1 > # no output > > However, instead I get 3 files: > build/macosx-x86_64-normal-server-release > build/macosx-x86_64-normal-server-release/build.log > build/macosx-x86_64-normal-server-release/configure.log > > Probably just a matter of tweaking the list of files that dist-clean will delete? Yep, since we take a conservative approach and only delete known files, this list tend to not be up to date at all times. Thank you for pointing it out! I've opened https://bugs.openjdk.java.net/browse/JDK-8081858 to track this. /Magnus From jonathan.gibbons at oracle.com Wed Jun 3 21:44:40 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 Jun 2015 14:44:40 -0700 Subject: Request for guidance on fixing JDK-8075571: Support tier1 and tier2 make targets In-Reply-To: <556E9618.600@oracle.com> References: <556E0C43.1010204@oracle.com> <556E1E5A.9080304@oracle.com> <556E9618.600@oracle.com> Message-ID: <556F7548.3080103@oracle.com> Joe, These lines in langtools/test/TEST.groups look like they belong, with appropriate tweaking, in langtools/test/Makefile 37 # Support for invoking tiered testing via the Makefile 38 #langtools_tier1 = :tier1 39 #langtools_tier2 = :tier2 40 #langtools_tier3 = :tier3 Or more specifically, there are no updates in langtools/test/Makefile to tie the test targets from test/Makefile into test groups. You probably want to add tier1 tier2 tier3 to this line in langtools/test/Makefile jtreg apt javac javadoc javah javap jdeps tier1 tier2 tier3: $(JPRT_CLEAN) jtreg-tests $(JPRT_ARCHIVE_BUNDLE) jtreg-summary @echo "Testing completed successfully" And add some macros to set the TESTDIRS for each of tier* all: JTREG_TESTDIRS = . jtreg: JTREG_TESTDIRS = . tier1: JTREG_TESTDIRS = :tier1 tier2: JTREG_TESTDIRS = :tier2 tier3: JTREG_TESTDIRS = :tier3 And, at some point, we should try and rationalize the various */test/Makefile. -- Jon On 06/02/2015 10:52 PM, joe darcy wrote: > Thanks for the pointers Jon. > > A not-quite-finished version of this work is up at > > http://cr.openjdk.java.net/~darcy/8075571.0/ > > The nashorn test makefile is copied from the jaxp one with > s/jaxp/nashorn/g. > > While I'm at it, I think it is worthwhile to add support nominal > support for tier 3 tests since there are at least some tier 3 tests > we'll want to add in the future. > > The top-level filtering of the langtools targets isn't quite working > as desired; a colon to indicate a test group is not getting passed > along. Some different filtering of the langtools arguments is needed? > > Thanks, > > -Joe > > > On 6/2/2015 2:21 PM, Jonathan Gibbons wrote: >> Joe, >> >> The magic you need to manipulate is lines 54-71 (approx) in >> test/Makefile. >> >> # Default test target (core) >> default: jdk_core langtools_jtreg jaxp_all >> >> # All testing >> all: jdk_all langtools_all jaxp_all >> >> # Test targets >> langtools_% : >> @$(NO_STOPPING)$(call SUBDIR_TEST, $(LANGTOOLS_DIR), >> JT_JAVA=$(PRODUCT_HOME) JTREG_HOME=$(JT_HOME) TEST="$(subst >> langtools_,,$@)" $(subst langtools_,,$@)) >> >> jdk_% core_%s svc_%: >> @$(NO_STOPPING)$(call SUBDIR_TEST, $(JDK_DIR), TEST="$@" $@) >> >> jaxp_%: >> @$(NO_STOPPING)$(call SUBDIR_TEST, $(JAXP_DIR), TEST="$@" $@) >> >> hotspot_%: >> @$(NO_STOPPING)$(call SUBDIR_TEST, $(HOTSPOT_DIR), TEST="$@" $@) >> >> >> These lines set up how test targets are mapped into individual >> targets in the individual repos. Note the pattern-matching rules >> for langtools_%, jdk_%, jaxp_%, hotspot% >> >> To add a new top level :tier1 target, I would copy the "all" target >> and add something like >> >> tier1: jdk_tier1 langtools_tier1 jaxp_tier1 >> >> (i.e. delegating to all repos that support a :tier1 test target). >> >> You will want to add a tier1 target into langtools/test/Makefile for >> this to work, because the langtools_% target strips off the >> "langtools_" prefix >> For other repos, make sure there is a jdk-tier1 target, jaxp-tier1 >> target, etc, since no prefix stripping is done on those targets. >> >> You might want to consider whether to (or not to) run the test >> targets in parallel. Depending how the individual repo test targets >> are set up, you could easily swamp your machine if you run too many >> invocations of jtreg in parallel. >> >> -- Jon >> >> >> >> >> >> On 06/02/2015 01:04 PM, joe darcy wrote: >>> Hello makefile gurus, >>> >>> To provide the next level of support to the tiered testing policy >>> [1], I'd like to get some advice on how best to tackle >>> >>> JDK-8075571: Support tier1 and tier2 make targets >>> >>> From the bug, currently one can invoke test groups like so: >>> >>> make test-only TEST=jdk_lang >>> >>> That this, this above make command will run the tests in the >>> ":jdk_lang" test group. By applying the simple edit >>> >>> diff -r df4d75f58f15 test/Makefile >>> --- a/test/Makefile Thu May 28 11:31:40 2015 -0700 >>> +++ b/test/Makefile Tue Jun 02 13:00:06 2015 -0700 >>> @@ -263,7 +263,7 @@ >>> >>> # ------------------------------------------------------------------ >>> >>> -jdk_% core_% svc_%: >>> +jdk_% core_% svc_% tier%: >>> $(ECHO) "Running tests: $@" >>> for each in $@; do \ >>> $(MAKE) -j 1 TEST_SELECTION=":$$each" UNIQUE_DIR=$$each >>> jtreg_tests; \ >>> >>> to the test/Makefile, I was hoping >>> >>> make test-only TEST=tier1 >>> >>> would in turn be able to run the ":tier1" test group. But alas, that >>> does not occur and I don't see what is (not) happening for that >>> omission to take place. >>> >>> Thanks, >>> >>> -Joe >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001991.html >> > From peter.brunet at oracle.com Thu Jun 4 01:43:39 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 03 Jun 2015 20:43:39 -0500 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FA621.4000108@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> Message-ID: <556FAD4B.4000700@oracle.com> Cross posting to build-dev for possible insight regarding Jon's last paragraph below. On 6/3/15 8:13 PM, Jonathan Gibbons wrote: > > On 06/03/2015 04:27 PM, Pete Brunet wrote: >> Hi, As part of my test I need to build a simple DLL and then load it >> from my test class. Can jtreg build the DLL or will I need to create it >> and include it in my test directory? -Pete > > jtreg cannot directly compile native code. In theory, you could do it > in a shell script, but that immediately becomes a rats nest of "which > platform, and where do I find the compilers?" > > If you are talking about native code and tests in OpenJDK > repositories, then it is not acceptable to stash binaries in OpenJDK > repositories. But, there is an infrastructure in place for an OpenJDK > build to build native libraries to be made available to test code. > Perhaps someone else on this list can explain how that works. > > -- Jon From peter.brunet at oracle.com Thu Jun 4 02:33:01 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 03 Jun 2015 21:33:01 -0500 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FAD4B.4000700@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> Message-ID: <556FB8DD.2030309@oracle.com> On 6/3/15 8:43 PM, Pete Brunet wrote: > Cross posting to build-dev for possible insight regarding Jon's last > paragraph below. > > On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>> Hi, As part of my test I need to build a simple DLL and then load it >>> from my test class. Can jtreg build the DLL or will I need to create it >>> and include it in my test directory? -Pete >> jtreg cannot directly compile native code. In theory, you could do it >> in a shell script, but that immediately becomes a rats nest of "which >> platform, and where do I find the compilers?" Is there a way to only run the test if running on Win? The DLL will be used as part of a test of a platform independent feature. Would only running on Win be acceptable? Is "where to I find the compilers" still an issue in a Win only case? >> >> If you are talking about native code and tests in OpenJDK >> repositories, then it is not acceptable to stash binaries in OpenJDK >> repositories. But, there is an infrastructure in place for an OpenJDK >> build to build native libraries to be made available to test code. >> Perhaps someone else on this list can explain how that works. >> >> -- Jon From david.holmes at oracle.com Thu Jun 4 05:10:06 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Jun 2015 15:10:06 +1000 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FAD4B.4000700@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> Message-ID: <556FDDAE.9010309@oracle.com> Peter, On 4/06/2015 11:43 AM, Pete Brunet wrote: > Cross posting to build-dev for possible insight regarding Jon's last > paragraph below. See jdk/make/test/JtregNative.gmk and other references to test-image. David > On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >> >> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>> Hi, As part of my test I need to build a simple DLL and then load it >>> from my test class. Can jtreg build the DLL or will I need to create it >>> and include it in my test directory? -Pete >> >> jtreg cannot directly compile native code. In theory, you could do it >> in a shell script, but that immediately becomes a rats nest of "which >> platform, and where do I find the compilers?" >> >> If you are talking about native code and tests in OpenJDK >> repositories, then it is not acceptable to stash binaries in OpenJDK >> repositories. But, there is an infrastructure in place for an OpenJDK >> build to build native libraries to be made available to test code. >> Perhaps someone else on this list can explain how that works. >> >> -- Jon > From david.holmes at oracle.com Thu Jun 4 05:13:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Jun 2015 15:13:14 +1000 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FB8DD.2030309@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> <556FB8DD.2030309@oracle.com> Message-ID: <556FDE6A.3050403@oracle.com> On 4/06/2015 12:33 PM, Pete Brunet wrote: > > On 6/3/15 8:43 PM, Pete Brunet wrote: >> Cross posting to build-dev for possible insight regarding Jon's last >> paragraph below. >> >> On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >>> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>>> Hi, As part of my test I need to build a simple DLL and then load it >>>> from my test class. Can jtreg build the DLL or will I need to create it >>>> and include it in my test directory? -Pete >>> jtreg cannot directly compile native code. In theory, you could do it >>> in a shell script, but that immediately becomes a rats nest of "which >>> platform, and where do I find the compilers?" > Is there a way to only run the test if running on Win? The DLL will be @requires os.family == windows Or something like that. David ----- > used as part of a test of a platform independent feature. Would only > running on Win be acceptable? Is "where to I find the compilers" still > an issue in a Win only case? >>> >>> If you are talking about native code and tests in OpenJDK >>> repositories, then it is not acceptable to stash binaries in OpenJDK >>> repositories. But, there is an infrastructure in place for an OpenJDK >>> build to build native libraries to be made available to test code. >>> Perhaps someone else on this list can explain how that works. >>> >>> -- Jon > From david.holmes at oracle.com Thu Jun 4 05:41:40 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Jun 2015 15:41:40 +1000 Subject: RFR: JDK-8081692 Configure should verify that -fstack-protector is valid In-Reply-To: <556EF3FE.6030203@oracle.com> References: <556EF3FE.6030203@oracle.com> Message-ID: <556FE514.50104@oracle.com> Magnus, You missed the hotspot side of this: ./solaris/makefiles/gcc.make: DEBUG_CFLAGS += -fstack-protector-all --param ssp-buffer-size=1 ./bsd/makefiles/gcc.make: DEBUG_CFLAGS += -fstack-protector-all --param ssp-buffer-size=1 ./linux/makefiles/gcc.make: DEBUG_CFLAGS += -fstack-protector-all --param ssp-buffer-size=1 David On 3/06/2015 10:33 PM, Magnus Ihse Bursie wrote: > Not all versions of gcc support -fstack-protector. We should check that > it is accepted as an argument before adding it to the flags. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8081692 > WebRev inline: > > diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 > --- a/common/autoconf/flags.m4 > +++ b/common/autoconf/flags.m4 > @@ -338,14 +338,16 @@ > # no adjustment > ;; > slowdebug ) > - # Add runtime stack smashing and undefined behavior checks > - CFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param > ssp-buffer-size=1" > - CXXFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param > ssp-buffer-size=1" > + # Add runtime stack smashing and undefined behavior checks. > + # Not all versions of gcc support -fstack-protector > + STACK_PROTECTOR_CFLAG="-fstack-protector-all" > + FLAGS_COMPILER_CHECK_ARGUMENTS([$STACK_PROTECTOR_CFLAG], [], > [STACK_PROTECTOR_CFLAG=""]) > + > + CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param > ssp-buffer-size=1" > + CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param > ssp-buffer-size=1" > ;; > esac > fi > - AC_SUBST(CFLAGS_DEBUG_OPTIONS) > - AC_SUBST(CXXFLAGS_DEBUG_OPTIONS) > > # Optimization levels > if test "x$TOOLCHAIN_TYPE" = xsolstudio; then > > The AC_SUBST removal is just a bit of cleanup, we didn't use the > *_DEBUG_OPTIONS in the spec files, just later on when constructing > JDK_CFLAGS. > > /Magnus > From staffan.larsen at oracle.com Thu Jun 4 08:18:49 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 4 Jun 2015 10:18:49 +0200 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FDDAE.9010309@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> <556FDDAE.9010309@oracle.com> Message-ID: > On 4 jun 2015, at 07:10, David Holmes wrote: > > Peter, > > On 4/06/2015 11:43 AM, Pete Brunet wrote: >> Cross posting to build-dev for possible insight regarding Jon's last >> paragraph below. > > See jdk/make/test/JtregNative.gmk and other references to test-image. There are example tests in jdk/test/native_sanity - take a look at those. /Staffan > > David > >> On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >>> >>> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>>> Hi, As part of my test I need to build a simple DLL and then load it >>>> from my test class. Can jtreg build the DLL or will I need to create it >>>> and include it in my test directory? -Pete >>> >>> jtreg cannot directly compile native code. In theory, you could do it >>> in a shell script, but that immediately becomes a rats nest of "which >>> platform, and where do I find the compilers?" >>> >>> If you are talking about native code and tests in OpenJDK >>> repositories, then it is not acceptable to stash binaries in OpenJDK >>> repositories. But, there is an infrastructure in place for an OpenJDK >>> build to build native libraries to be made available to test code. >>> Perhaps someone else on this list can explain how that works. >>> >>> -- Jon >> From staffan.larsen at oracle.com Thu Jun 4 08:20:17 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 4 Jun 2015 10:20:17 +0200 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FB8DD.2030309@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> <556FB8DD.2030309@oracle.com> Message-ID: <4E6AB5A1-1167-4603-B348-BAEB6AB43E0D@oracle.com> > On 4 jun 2015, at 04:33, Pete Brunet wrote: > > > On 6/3/15 8:43 PM, Pete Brunet wrote: >> Cross posting to build-dev for possible insight regarding Jon's last >> paragraph below. >> >> On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >>> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>>> Hi, As part of my test I need to build a simple DLL and then load it >>>> from my test class. Can jtreg build the DLL or will I need to create it >>>> and include it in my test directory? -Pete >>> jtreg cannot directly compile native code. In theory, you could do it >>> in a shell script, but that immediately becomes a rats nest of "which >>> platform, and where do I find the compilers?" > Is there a way to only run the test if running on Win? The DLL will be > used as part of a test of a platform independent feature. Would only > running on Win be acceptable? Is "where to I find the compilers" still > an issue in a Win only case? Yes - most test machines don?t have compilers on them. All compilation has to be done as part of the build. >>> >>> If you are talking about native code and tests in OpenJDK >>> repositories, then it is not acceptable to stash binaries in OpenJDK >>> repositories. But, there is an infrastructure in place for an OpenJDK >>> build to build native libraries to be made available to test code. >>> Perhaps someone else on this list can explain how that works. >>> >>> -- Jon > From magnus.ihse.bursie at oracle.com Thu Jun 4 12:38:50 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 04 Jun 2015 14:38:50 +0200 Subject: RFR: JDK-8081692 Configure should verify that -fstack-protector is valid In-Reply-To: <556FE514.50104@oracle.com> References: <556EF3FE.6030203@oracle.com> <556FE514.50104@oracle.com> Message-ID: <557046DA.8080308@oracle.com> On 2015-06-04 07:41, David Holmes wrote: > Magnus, > > You missed the hotspot side of this: > > ./solaris/makefiles/gcc.make: DEBUG_CFLAGS += -fstack-protector-all > --param ssp-buffer-size=1 > ./bsd/makefiles/gcc.make: DEBUG_CFLAGS += -fstack-protector-all > --param ssp-buffer-size=1 > ./linux/makefiles/gcc.make: DEBUG_CFLAGS += -fstack-protector-all > --param ssp-buffer-size=1 I'm not actually sure how to do this in hotspot. We have no access to the FLAGS_COMPILER_CHECK_ARGUMENTS configure argument. Should I move the definition of the DEBUG_CFLAGS from the hotspot makefiles into configure, and pass e.g. HOTSPOT_DEBUG_CFLAGS into hotspot-spec.gmk? Would that seem like a good idea to you? /Magnus (I'm soooo longing for the build-infra hotspot replacement...) > > David > > On 3/06/2015 10:33 PM, Magnus Ihse Bursie wrote: >> Not all versions of gcc support -fstack-protector. We should check that >> it is accepted as an argument before adding it to the flags. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8081692 >> WebRev inline: >> >> diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 >> --- a/common/autoconf/flags.m4 >> +++ b/common/autoconf/flags.m4 >> @@ -338,14 +338,16 @@ >> # no adjustment >> ;; >> slowdebug ) >> - # Add runtime stack smashing and undefined behavior checks >> - CFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param >> ssp-buffer-size=1" >> - CXXFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param >> ssp-buffer-size=1" >> + # Add runtime stack smashing and undefined behavior checks. >> + # Not all versions of gcc support -fstack-protector >> + STACK_PROTECTOR_CFLAG="-fstack-protector-all" >> + FLAGS_COMPILER_CHECK_ARGUMENTS([$STACK_PROTECTOR_CFLAG], [], >> [STACK_PROTECTOR_CFLAG=""]) >> + >> + CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param >> ssp-buffer-size=1" >> + CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param >> ssp-buffer-size=1" >> ;; >> esac >> fi >> - AC_SUBST(CFLAGS_DEBUG_OPTIONS) >> - AC_SUBST(CXXFLAGS_DEBUG_OPTIONS) >> >> # Optimization levels >> if test "x$TOOLCHAIN_TYPE" = xsolstudio; then >> >> The AC_SUBST removal is just a bit of cleanup, we didn't use the >> *_DEBUG_OPTIONS in the spec files, just later on when constructing >> JDK_CFLAGS. >> >> /Magnus >> From denisl at openscg.com Thu Jun 4 19:20:03 2015 From: denisl at openscg.com (Lussier, Denis) Date: Thu, 4 Jun 2015 15:20:03 -0400 Subject: need to build a DLL for an openjdk test In-Reply-To: References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> <556FDDAE.9010309@oracle.com> Message-ID: In my personal JDK6/7 experience from a couple years back, the Windows OpenJDK build environment is an order of magnitude trickier to work thru than the Linux one. You need outdated versions of lots of tools, utilities, environments, compilers and operating systems to get it all right (a single binary that runs on old & new Windows versions with just a simple non-root install with no rebooting). In the end you get something that works darn well (although there were still rough edges in the area of Swings Fonts and Sound a couple years back). Not suer if the Oracle propietary binaries still use non GPL components in these areas on Windows. --Luss On Thu, Jun 4, 2015 at 4:18 AM, Staffan Larsen wrote: > > > On 4 jun 2015, at 07:10, David Holmes wrote: > > > > Peter, > > > > On 4/06/2015 11:43 AM, Pete Brunet wrote: > >> Cross posting to build-dev for possible insight regarding Jon's last > >> paragraph below. > > > > See jdk/make/test/JtregNative.gmk and other references to test-image. > > There are example tests in jdk/test/native_sanity - take a look at those. > > /Staffan > > > > > David > > > >> On 6/3/15 8:13 PM, Jonathan Gibbons wrote: > >>> > >>> On 06/03/2015 04:27 PM, Pete Brunet wrote: > >>>> Hi, As part of my test I need to build a simple DLL and then load it > >>>> from my test class. Can jtreg build the DLL or will I need to create > it > >>>> and include it in my test directory? -Pete > >>> > >>> jtreg cannot directly compile native code. In theory, you could do it > >>> in a shell script, but that immediately becomes a rats nest of "which > >>> platform, and where do I find the compilers?" > >>> > >>> If you are talking about native code and tests in OpenJDK > >>> repositories, then it is not acceptable to stash binaries in OpenJDK > >>> repositories. But, there is an infrastructure in place for an OpenJDK > >>> build to build native libraries to be made available to test code. > >>> Perhaps someone else on this list can explain how that works. > >>> > >>> -- Jon > >> > > From magnus.ihse.bursie at oracle.com Thu Jun 4 20:31:01 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 04 Jun 2015 22:31:01 +0200 Subject: need to build a DLL for an openjdk test In-Reply-To: References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> <556FDDAE.9010309@oracle.com> Message-ID: <5570B585.3080402@oracle.com> On 2015-06-04 21:20, Lussier, Denis wrote: > In my personal JDK6/7 experience from a couple years back, the Windows > OpenJDK build environment is an order of magnitude trickier to work thru > than the Linux one. You need outdated versions of lots of tools, > utilities, environments, compilers and operating systems to get it all > right (a single binary that runs on old & new Windows versions with just a > simple non-root install with no rebooting). I'm not really sure how this comment ties in with the rest of the discussion, but I just wanted to enlighten you on the fact that much have changed since then. Ever since JDK8, the new build system based on configure is in place, which greatly simplifies building, even on Windows. True, it's often somewhat more tricky to setup a working build environment on Windows, but the difference is not that great. If you have a basic cygwin and Microsofts build toolchain installed, then configure will guide you through the process of getting the rest of the build requirements. /Magnus From valerie.peng at oracle.com Thu Jun 4 21:58:57 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Thu, 04 Jun 2015 14:58:57 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <556F38F4.4070109@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> Message-ID: <5570CA21.7070309@oracle.com> Build experts, Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. Thanks, Valerie On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: > > Correct, if the makefile related changes are removed then no need for > build team to review 7191662 webrev anymore. > There are other discussions ongoing and we should be able to reach a > decision in a day or two. > Will update the list again. > Thanks, > Valerie > > On 06/01/15 16:39, Magnus Ihse Bursie wrote: >> On 2015-05-29 00:10, Valerie Peng wrote: >>> >>> Please find comments in line... >>> >>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>> Valerie, >>>> >>>> Did you see my comment yesterday? >>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>> >>> Yes, we exchanged emails after this above one. I will follow up your >>> latest one later today. >>> >>>> >>>> Since you have reverted the java.security to keep the classname, to >>>> avoid causing merge conflict to jimage refresh, let?s remove the >>>> META-INF files in the first push and the build change. >>>> >>>> The security providers will be loaded via the fallback mechanism >>>> (i.e. ProviderLoader.legacyLoad method). You should keep the >>>> ProviderLoader.load method to take the provider name instead of >>>> classname. >>> Sure, I can remove the META-INF files so the providers are loaded >>> through the legacyLoad(). >>> Hmm, the ProviderLoader.load() method is used by java.security file >>> provider loading. Since the current list still uses class name, it >>> should take class name when checking for matches while iterating >>> through the list returned by ServiceLoader. >>> This way, when changes are sync'ed into Jake, no extra change >>> required and the providers will be loaded through >>> ProviderLoader.load() automatically with the current list. >>> >>>> I?ll file a bug to follow up to change java.security to list the >>>> provider name. This will wait after the jimage refresh goes into >>>> jdk9/dev >>> Ok. >>> Thanks, >>> Valerie >> >> I'm not sure I followed completely here were this landed. Does this >> mean that there's currently no need for a build system code review on >> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a >> new webrev will be posted instead? >> >> /Magnus >> >> >> >>>> . >>>> >>>> Mandy >>>> >>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>> Peng wrote: >>>>> >>>>> Hi, build experts, >>>>> >>>>> Can you please review the make file related change, i.e. the new >>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>> >>>>> This is for merging the java.security.Provider file from various >>>>> providers and use the (merged) result for the final image build. >>>>> >>>>> The rest of source code changes are reviewed by my team already. >>>>> Thanks, >>>>> Valerie >>>>> (Java Security Team) >> > From david.holmes at oracle.com Fri Jun 5 06:36:54 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Jun 2015 16:36:54 +1000 Subject: RFR: JDK-8081692 Configure should verify that -fstack-protector is valid In-Reply-To: <557046DA.8080308@oracle.com> References: <556EF3FE.6030203@oracle.com> <556FE514.50104@oracle.com> <557046DA.8080308@oracle.com> Message-ID: <55714386.5060605@oracle.com> On 4/06/2015 10:38 PM, Magnus Ihse Bursie wrote: > On 2015-06-04 07:41, David Holmes wrote: >> Magnus, >> >> You missed the hotspot side of this: >> >> ./solaris/makefiles/gcc.make: DEBUG_CFLAGS += -fstack-protector-all >> --param ssp-buffer-size=1 >> ./bsd/makefiles/gcc.make: DEBUG_CFLAGS += -fstack-protector-all >> --param ssp-buffer-size=1 >> ./linux/makefiles/gcc.make: DEBUG_CFLAGS += -fstack-protector-all >> --param ssp-buffer-size=1 > > I'm not actually sure how to do this in hotspot. We have no access to > the FLAGS_COMPILER_CHECK_ARGUMENTS configure argument. > > Should I move the definition of the DEBUG_CFLAGS from the hotspot > makefiles into configure, and pass e.g. HOTSPOT_DEBUG_CFLAGS into > hotspot-spec.gmk? Would that seem like a good idea to you? I guess I was expecting a SUPPORTS_STACK_PROTECTOR variable that could be exported to spec.gmk. BTW in this: CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param ssp-buffer-size=1" the --param ssp-buffer-size is only meaningful when using -fstack-protector[-all]. It doesn't produce any warnings though so I assume it is harmless. Thanks, David > /Magnus > (I'm soooo longing for the build-infra hotspot replacement...) > >> >> David >> >> On 3/06/2015 10:33 PM, Magnus Ihse Bursie wrote: >>> Not all versions of gcc support -fstack-protector. We should check that >>> it is accepted as an argument before adding it to the flags. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8081692 >>> WebRev inline: >>> >>> diff --git a/common/autoconf/flags.m4 b/common/autoconf/flags.m4 >>> --- a/common/autoconf/flags.m4 >>> +++ b/common/autoconf/flags.m4 >>> @@ -338,14 +338,16 @@ >>> # no adjustment >>> ;; >>> slowdebug ) >>> - # Add runtime stack smashing and undefined behavior checks >>> - CFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param >>> ssp-buffer-size=1" >>> - CXXFLAGS_DEBUG_OPTIONS="-fstack-protector-all --param >>> ssp-buffer-size=1" >>> + # Add runtime stack smashing and undefined behavior checks. >>> + # Not all versions of gcc support -fstack-protector >>> + STACK_PROTECTOR_CFLAG="-fstack-protector-all" >>> + FLAGS_COMPILER_CHECK_ARGUMENTS([$STACK_PROTECTOR_CFLAG], [], >>> [STACK_PROTECTOR_CFLAG=""]) >>> + >>> + CFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param >>> ssp-buffer-size=1" >>> + CXXFLAGS_DEBUG_OPTIONS="$STACK_PROTECTOR_CFLAG --param >>> ssp-buffer-size=1" >>> ;; >>> esac >>> fi >>> - AC_SUBST(CFLAGS_DEBUG_OPTIONS) >>> - AC_SUBST(CXXFLAGS_DEBUG_OPTIONS) >>> >>> # Optimization levels >>> if test "x$TOOLCHAIN_TYPE" = xsolstudio; then >>> >>> The AC_SUBST removal is just a bit of cleanup, we didn't use the >>> *_DEBUG_OPTIONS in the spec files, just later on when constructing >>> JDK_CFLAGS. >>> >>> /Magnus >>> > From manasthakur17 at gmail.com Fri Jun 5 07:12:02 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Fri, 5 Jun 2015 12:42:02 +0530 Subject: OpenJDK 8u45 on Yosemite Message-ID: <229B60BE-F829-473C-9B5C-A73A860E967D@gmail.com> Hi all I had posted about problems with building openjdk8 on Mac OS X Yosemite last year. I am still unable to do the same. I did the following based on some posts tot he list in January: 1. bash configure ?with-tools-dir=?/Applications/Xcode4/Xcode.app/Contents/Developer/usr/bin/? 2. Applied the following patch to saproc.make: - SALIBS = -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation + SALIBS = -isysroot /Applications/Xcode4/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation Now, the error shown is the following: error: unable to open executable ?libjvm.dylib' What all should I do for a successful build? Regards, Manas From erik.joelsson at oracle.com Fri Jun 5 07:21:22 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 05 Jun 2015 09:21:22 +0200 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <5570CA21.7070309@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> Message-ID: <55714DF2.7090100@oracle.com> Hello Valerie, The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. /Erik On 2015-06-04 23:58, Valerie Peng wrote: > Build experts, > > Can you please review the make file related change, i.e. the new file > make/gensrc/Gensrc-java.naming.gmk, in the following webrev: > http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 > > This is for merging the java.security.Provider file from various > providers and use the (merged) result for the final image build. > > Thanks, > Valerie > > On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >> >> Correct, if the makefile related changes are removed then no need for >> build team to review 7191662 webrev anymore. >> There are other discussions ongoing and we should be able to reach a >> decision in a day or two. >> Will update the list again. >> Thanks, >> Valerie >> >> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>> On 2015-05-29 00:10, Valerie Peng wrote: >>>> >>>> Please find comments in line... >>>> >>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>> Valerie, >>>>> >>>>> Did you see my comment yesterday? >>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>> >>>> Yes, we exchanged emails after this above one. I will follow up >>>> your latest one later today. >>>> >>>>> >>>>> Since you have reverted the java.security to keep the classname, >>>>> to avoid causing merge conflict to jimage refresh, let?s remove >>>>> the META-INF files in the first push and the build change. >>>>> >>>>> The security providers will be loaded via the fallback mechanism >>>>> (i.e. ProviderLoader.legacyLoad method). You should keep the >>>>> ProviderLoader.load method to take the provider name instead of >>>>> classname. >>>> Sure, I can remove the META-INF files so the providers are loaded >>>> through the legacyLoad(). >>>> Hmm, the ProviderLoader.load() method is used by java.security file >>>> provider loading. Since the current list still uses class name, it >>>> should take class name when checking for matches while iterating >>>> through the list returned by ServiceLoader. >>>> This way, when changes are sync'ed into Jake, no extra change >>>> required and the providers will be loaded through >>>> ProviderLoader.load() automatically with the current list. >>>> >>>>> I?ll file a bug to follow up to change java.security to list the >>>>> provider name. This will wait after the jimage refresh goes into >>>>> jdk9/dev >>>> Ok. >>>> Thanks, >>>> Valerie >>> >>> I'm not sure I followed completely here were this landed. Does this >>> mean that there's currently no need for a build system code review >>> on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that >>> a new webrev will be posted instead? >>> >>> /Magnus >>> >>> >>> >>>>> . >>>>> >>>>> Mandy >>>>> >>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>> Peng wrote: >>>>>> >>>>>> Hi, build experts, >>>>>> >>>>>> Can you please review the make file related change, i.e. the new >>>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>> >>>>>> This is for merging the java.security.Provider file from various >>>>>> providers and use the (merged) result for the final image build. >>>>>> >>>>>> The rest of source code changes are reviewed by my team already. >>>>>> Thanks, >>>>>> Valerie >>>>>> (Java Security Team) >>> >> From semyon.sadetsky at oracle.com Fri Jun 5 08:47:18 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 05 Jun 2015 11:47:18 +0300 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <556EBD21.6090805@oracle.com> References: <556DCB7F.2020104@oracle.com> <556EBAC7.9080009@oracle.com> <556EBD21.6090805@oracle.com> Message-ID: <55716216.5080008@oracle.com> Hi, I have installed the devkit on clean Solaris 11.2 instance but configure fails because compiler cannot find the includes path: c -o conftest conftest.c >&5 "conftest.c", line 9: cannot find include file: "conftest.c", line 13: undefined symbol: FILE though devkit & sysroot path was detected by configure. Any reasons why? I did not not install normal solaris studio only the devkit. Thank you. --Semyon On 6/3/2015 11:38 AM, Semyon Sadetsky wrote: > > On 6/3/2015 11:28 AM, Magnus Ihse Bursie wrote: >> On 2015-06-02 17:27, Semyon Sadetsky wrote: >>> Hi, >>> >>> I'm trying to build jdk9 under the current Solaris 11.2 version. >>> Which version of the Solaris Studio should be installed for that? >>> The readme-builds states: >>> ... >>> At a minimum, the Studio 12 Update 1 Compilers (containing version >>> 5.10 of the C and C++ compilers) is required, including specific >>> patches. >>> ... >>> Currently there are 3 versions currently available for downloading: >>> >>> Oracle Solaris Studio 12.2 >>> Oracle Solaris Studio 12.3 >>> Oracle Solaris Studio 12.4 >>> >>> I tried all 3 and only with 12.3 I do no receive build warnings >>> about wrong compiler version, >>> but my build constantly fails with 12.3 with the next message: >>> >>> Compiling 246 files for jdk.jdi >>> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", >>> line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", >>> line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>> ld: fatal: file >>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: >>> not an ELF object >>> gmake[3]: *** >>> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] >>> Error 2 >>> gmake[3]: *** Waiting for unfinished jobs.... >>> gmake[2]: *** [java.base-libs] Error 1 >>> >>> Even --disable-warnings-as-errors option does not save the build >>> from failure. >> That's because the warning does not cause the build failure. Read the >> logs again. :-) >> >> The real error here is "libjvm.so: not an ELF object" which causes >> the linking to fail for libverify.so. The warning from libjava is >> just a red herring. >> >> Your hotspot build is broken. Try >> "make clean-hotspot" >> "make hotspot" >> and see if you spot any errors. Otherwise you'd probably just left >> the build in a bad state. >> >> /Magnus > Thank you. In reality it was even worse when I add the option > disabling warnings as errors the VM hangs in the middle of the build > and those messages I got after restarting it and running the > incremental build. This scenario was reproduced 2 times with clean > build. So, my next attempt is a clean install with devkits. > > --Semyon > >> >>> Could you send me the software list with the versions that should be >>> installed on a clean Solaris 11.2 instance to have the build running >>> smoothly? >>> >>> Thank you, >>> --Semyon >>> >>> >>> >> > From magnus.ihse.bursie at oracle.com Fri Jun 5 13:05:59 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 5 Jun 2015 15:05:59 +0200 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <55716216.5080008@oracle.com> References: <556DCB7F.2020104@oracle.com> <556EBAC7.9080009@oracle.com> <556EBD21.6090805@oracle.com> <55716216.5080008@oracle.com> Message-ID: <4DB63F84-887E-4A08-A437-85E9D71CBF63@oracle.com> Did you use the --with-devkit option? /Magnus > 5 jun 2015 kl. 10:47 skrev Semyon Sadetsky : > > Hi, > > I have installed the devkit on clean Solaris 11.2 instance but configure fails because compiler cannot find the includes path: > c -o conftest conftest.c >&5 > "conftest.c", line 9: cannot find include file: > "conftest.c", line 13: undefined symbol: FILE > > though devkit & sysroot path was detected by configure. > Any reasons why? > I did not not install normal solaris studio only the devkit. > > Thank you. > --Semyon > > >> On 6/3/2015 11:38 AM, Semyon Sadetsky wrote: >> >>> On 6/3/2015 11:28 AM, Magnus Ihse Bursie wrote: >>>> On 2015-06-02 17:27, Semyon Sadetsky wrote: >>>> Hi, >>>> >>>> I'm trying to build jdk9 under the current Solaris 11.2 version. >>>> Which version of the Solaris Studio should be installed for that? The readme-builds states: >>>> ... >>>> At a minimum, the Studio 12 Update 1 Compilers (containing version 5.10 of the C and C++ compilers) is required, including specific patches. >>>> ... >>>> Currently there are 3 versions currently available for downloading: >>>> >>>> Oracle Solaris Studio 12.2 >>>> Oracle Solaris Studio 12.3 >>>> Oracle Solaris Studio 12.4 >>>> >>>> I tried all 3 and only with 12.3 I do no receive build warnings about wrong compiler version, >>>> but my build constantly fails with 12.3 with the next message: >>>> >>>> Compiling 246 files for jdk.jdi >>>> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>> ld: fatal: file /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: not an ELF object >>>> gmake[3]: *** [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] Error 2 >>>> gmake[3]: *** Waiting for unfinished jobs.... >>>> gmake[2]: *** [java.base-libs] Error 1 >>>> >>>> Even --disable-warnings-as-errors option does not save the build from failure. >>> That's because the warning does not cause the build failure. Read the logs again. :-) >>> >>> The real error here is "libjvm.so: not an ELF object" which causes the linking to fail for libverify.so. The warning from libjava is just a red herring. >>> >>> Your hotspot build is broken. Try >>> "make clean-hotspot" >>> "make hotspot" >>> and see if you spot any errors. Otherwise you'd probably just left the build in a bad state. >>> >>> /Magnus >> Thank you. In reality it was even worse when I add the option disabling warnings as errors the VM hangs in the middle of the build and those messages I got after restarting it and running the incremental build. This scenario was reproduced 2 times with clean build. So, my next attempt is a clean install with devkits. >> >> --Semyon >> >>> >>>> Could you send me the software list with the versions that should be installed on a clean Solaris 11.2 instance to have the build running smoothly? >>>> >>>> Thank you, >>>> --Semyon > From magnus.ihse.bursie at oracle.com Fri Jun 5 14:07:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 05 Jun 2015 16:07:20 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) Message-ID: <5571AD18.7080701@oracle.com> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 [1] http://openjdk.java.net/jeps/223 From erik.joelsson at oracle.com Fri Jun 5 14:09:26 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 05 Jun 2015 16:09:26 +0200 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <4DB63F84-887E-4A08-A437-85E9D71CBF63@oracle.com> References: <556DCB7F.2020104@oracle.com> <556EBAC7.9080009@oracle.com> <556EBD21.6090805@oracle.com> <55716216.5080008@oracle.com> <4DB63F84-887E-4A08-A437-85E9D71CBF63@oracle.com> Message-ID: <5571AD96.3040304@oracle.com> Actually, we might have issues in configure if the standard headers aren't available on the system. At least I have not tested that scenario and I can imagine that our SYSROOT_CFLAGS aren't always used in the configure tests. This is of course a bug, but a workaround would be to have the system headers installed on the system. They won't be used during the actual build. /Erik On 2015-06-05 15:05, Magnus Ihse Bursie wrote: > Did you use the --with-devkit option? > > /Magnus > >> 5 jun 2015 kl. 10:47 skrev Semyon Sadetsky : >> >> Hi, >> >> I have installed the devkit on clean Solaris 11.2 instance but configure fails because compiler cannot find the includes path: >> c -o conftest conftest.c >&5 >> "conftest.c", line 9: cannot find include file: >> "conftest.c", line 13: undefined symbol: FILE >> >> though devkit & sysroot path was detected by configure. >> Any reasons why? >> I did not not install normal solaris studio only the devkit. >> >> Thank you. >> --Semyon >> >> >>> On 6/3/2015 11:38 AM, Semyon Sadetsky wrote: >>> >>>> On 6/3/2015 11:28 AM, Magnus Ihse Bursie wrote: >>>>> On 2015-06-02 17:27, Semyon Sadetsky wrote: >>>>> Hi, >>>>> >>>>> I'm trying to build jdk9 under the current Solaris 11.2 version. >>>>> Which version of the Solaris Studio should be installed for that? The readme-builds states: >>>>> ... >>>>> At a minimum, the Studio 12 Update 1 Compilers (containing version 5.10 of the C and C++ compilers) is required, including specific patches. >>>>> ... >>>>> Currently there are 3 versions currently available for downloading: >>>>> >>>>> Oracle Solaris Studio 12.2 >>>>> Oracle Solaris Studio 12.3 >>>>> Oracle Solaris Studio 12.4 >>>>> >>>>> I tried all 3 and only with 12.3 I do no receive build warnings about wrong compiler version, >>>>> but my build constantly fails with 12.3 with the next message: >>>>> >>>>> Compiling 246 files for jdk.jdi >>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>> ld: fatal: file /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: not an ELF object >>>>> gmake[3]: *** [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] Error 2 >>>>> gmake[3]: *** Waiting for unfinished jobs.... >>>>> gmake[2]: *** [java.base-libs] Error 1 >>>>> >>>>> Even --disable-warnings-as-errors option does not save the build from failure. >>>> That's because the warning does not cause the build failure. Read the logs again. :-) >>>> >>>> The real error here is "libjvm.so: not an ELF object" which causes the linking to fail for libverify.so. The warning from libjava is just a red herring. >>>> >>>> Your hotspot build is broken. Try >>>> "make clean-hotspot" >>>> "make hotspot" >>>> and see if you spot any errors. Otherwise you'd probably just left the build in a bad state. >>>> >>>> /Magnus >>> Thank you. In reality it was even worse when I add the option disabling warnings as errors the VM hangs in the middle of the build and those messages I got after restarting it and running the incremental build. This scenario was reproduced 2 times with clean build. So, my next attempt is a clean install with devkits. >>> >>> --Semyon >>> >>>>> Could you send me the software list with the versions that should be installed on a clean Solaris 11.2 instance to have the build running smoothly? >>>>> >>>>> Thank you, >>>>> --Semyon From semyon.sadetsky at oracle.com Fri Jun 5 14:14:06 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 05 Jun 2015 17:14:06 +0300 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <4DB63F84-887E-4A08-A437-85E9D71CBF63@oracle.com> References: <556DCB7F.2020104@oracle.com> <556EBAC7.9080009@oracle.com> <556EBD21.6090805@oracle.com> <55716216.5080008@oracle.com> <4DB63F84-887E-4A08-A437-85E9D71CBF63@oracle.com> Message-ID: <5571AEAE.2000902@oracle.com> Shure: ./configure --with-devkit=/export/home/oracle/devkit/SS12u4-Solaris11u1/ --enable-debug --Semyon On 6/5/2015 4:05 PM, Magnus Ihse Bursie wrote: > Did you use the --with-devkit option? > > /Magnus > >> 5 jun 2015 kl. 10:47 skrev Semyon Sadetsky : >> >> Hi, >> >> I have installed the devkit on clean Solaris 11.2 instance but configure fails because compiler cannot find the includes path: >> c -o conftest conftest.c >&5 >> "conftest.c", line 9: cannot find include file: >> "conftest.c", line 13: undefined symbol: FILE >> >> though devkit & sysroot path was detected by configure. >> Any reasons why? >> I did not not install normal solaris studio only the devkit. >> >> Thank you. >> --Semyon >> >> >>> On 6/3/2015 11:38 AM, Semyon Sadetsky wrote: >>> >>>> On 6/3/2015 11:28 AM, Magnus Ihse Bursie wrote: >>>>> On 2015-06-02 17:27, Semyon Sadetsky wrote: >>>>> Hi, >>>>> >>>>> I'm trying to build jdk9 under the current Solaris 11.2 version. >>>>> Which version of the Solaris Studio should be installed for that? The readme-builds states: >>>>> ... >>>>> At a minimum, the Studio 12 Update 1 Compilers (containing version 5.10 of the C and C++ compilers) is required, including specific patches. >>>>> ... >>>>> Currently there are 3 versions currently available for downloading: >>>>> >>>>> Oracle Solaris Studio 12.2 >>>>> Oracle Solaris Studio 12.3 >>>>> Oracle Solaris Studio 12.4 >>>>> >>>>> I tried all 3 and only with 12.3 I do no receive build warnings about wrong compiler version, >>>>> but my build constantly fails with 12.3 with the next message: >>>>> >>>>> Compiling 246 files for jdk.jdi >>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>> ld: fatal: file /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: not an ELF object >>>>> gmake[3]: *** [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] Error 2 >>>>> gmake[3]: *** Waiting for unfinished jobs.... >>>>> gmake[2]: *** [java.base-libs] Error 1 >>>>> >>>>> Even --disable-warnings-as-errors option does not save the build from failure. >>>> That's because the warning does not cause the build failure. Read the logs again. :-) >>>> >>>> The real error here is "libjvm.so: not an ELF object" which causes the linking to fail for libverify.so. The warning from libjava is just a red herring. >>>> >>>> Your hotspot build is broken. Try >>>> "make clean-hotspot" >>>> "make hotspot" >>>> and see if you spot any errors. Otherwise you'd probably just left the build in a bad state. >>>> >>>> /Magnus >>> Thank you. In reality it was even worse when I add the option disabling warnings as errors the VM hangs in the middle of the build and those messages I got after restarting it and running the incremental build. This scenario was reproduced 2 times with clean build. So, my next attempt is a clean install with devkits. >>> >>> --Semyon >>> >>>>> Could you send me the software list with the versions that should be installed on a clean Solaris 11.2 instance to have the build running smoothly? >>>>> >>>>> Thank you, >>>>> --Semyon From semyon.sadetsky at oracle.com Fri Jun 5 14:18:27 2015 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Fri, 05 Jun 2015 17:18:27 +0300 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <5571AD96.3040304@oracle.com> References: <556DCB7F.2020104@oracle.com> <556EBAC7.9080009@oracle.com> <556EBD21.6090805@oracle.com> <55716216.5080008@oracle.com> <4DB63F84-887E-4A08-A437-85E9D71CBF63@oracle.com> <5571AD96.3040304@oracle.com> Message-ID: <5571AFB3.7050009@oracle.com> How can I install them, just copy from sysroot/usr? Or it is possible to skip conftest? --Semyon On 6/5/2015 5:09 PM, Erik Joelsson wrote: > Actually, we might have issues in configure if the standard headers > aren't available on the system. At least I have not tested that > scenario and I can imagine that our SYSROOT_CFLAGS aren't always used > in the configure tests. This is of course a bug, but a workaround > would be to have the system headers installed on the system. They > won't be used during the actual build. > > /Erik > > On 2015-06-05 15:05, Magnus Ihse Bursie wrote: >> Did you use the --with-devkit option? >> >> /Magnus >> >>> 5 jun 2015 kl. 10:47 skrev Semyon Sadetsky >>> : >>> >>> Hi, >>> >>> I have installed the devkit on clean Solaris 11.2 instance but >>> configure fails because compiler cannot find the includes path: >>> c -o conftest conftest.c >&5 >>> "conftest.c", line 9: cannot find include file: >>> "conftest.c", line 13: undefined symbol: FILE >>> >>> though devkit & sysroot path was detected by configure. >>> Any reasons why? >>> I did not not install normal solaris studio only the devkit. >>> >>> Thank you. >>> --Semyon >>> >>> >>>> On 6/3/2015 11:38 AM, Semyon Sadetsky wrote: >>>> >>>>> On 6/3/2015 11:28 AM, Magnus Ihse Bursie wrote: >>>>>> On 2015-06-02 17:27, Semyon Sadetsky wrote: >>>>>> Hi, >>>>>> >>>>>> I'm trying to build jdk9 under the current Solaris 11.2 version. >>>>>> Which version of the Solaris Studio should be installed for that? >>>>>> The readme-builds states: >>>>>> ... >>>>>> At a minimum, the Studio 12 Update 1 Compilers (containing >>>>>> version 5.10 of the C and C++ compilers) is required, including >>>>>> specific patches. >>>>>> ... >>>>>> Currently there are 3 versions currently available for downloading: >>>>>> >>>>>> Oracle Solaris Studio 12.2 >>>>>> Oracle Solaris Studio 12.3 >>>>>> Oracle Solaris Studio 12.4 >>>>>> >>>>>> I tried all 3 and only with 12.3 I do no receive build warnings >>>>>> about wrong compiler version, >>>>>> but my build constantly fails with 12.3 with the next message: >>>>>> >>>>>> Compiling 246 files for jdk.jdi >>>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", >>>>>> line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", >>>>>> line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>>> ld: fatal: file >>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: >>>>>> not an ELF object >>>>>> gmake[3]: *** >>>>>> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] >>>>>> Error 2 >>>>>> gmake[3]: *** Waiting for unfinished jobs.... >>>>>> gmake[2]: *** [java.base-libs] Error 1 >>>>>> >>>>>> Even --disable-warnings-as-errors option does not save the build >>>>>> from failure. >>>>> That's because the warning does not cause the build failure. Read >>>>> the logs again. :-) >>>>> >>>>> The real error here is "libjvm.so: not an ELF object" which causes >>>>> the linking to fail for libverify.so. The warning from libjava is >>>>> just a red herring. >>>>> >>>>> Your hotspot build is broken. Try >>>>> "make clean-hotspot" >>>>> "make hotspot" >>>>> and see if you spot any errors. Otherwise you'd probably just left >>>>> the build in a bad state. >>>>> >>>>> /Magnus >>>> Thank you. In reality it was even worse when I add the option >>>> disabling warnings as errors the VM hangs in the middle of the >>>> build and those messages I got after restarting it and running the >>>> incremental build. This scenario was reproduced 2 times with clean >>>> build. So, my next attempt is a clean install with devkits. >>>> >>>> --Semyon >>>> >>>>>> Could you send me the software list with the versions that should >>>>>> be installed on a clean Solaris 11.2 instance to have the build >>>>>> running smoothly? >>>>>> >>>>>> Thank you, >>>>>> --Semyon > From tim.bell at oracle.com Fri Jun 5 14:30:49 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 05 Jun 2015 07:30:49 -0700 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <5571AFB3.7050009@oracle.com> References: <556DCB7F.2020104@oracle.com> <556EBAC7.9080009@oracle.com> <556EBD21.6090805@oracle.com> <55716216.5080008@oracle.com> <4DB63F84-887E-4A08-A437-85E9D71CBF63@oracle.com> <5571AD96.3040304@oracle.com> <5571AFB3.7050009@oracle.com> Message-ID: <5571B299.1080100@oracle.com> Hi I would not recommend copying files off some other system. The last time I started with a brand-new minimal Solaris 11.x install, I needed to add: sudo pkg install gnu-tar system/header system/picl x11/library/libx11 x11/library/libxrender x11/library/libxext x11/library/libxtst x11/library/toolkit/libxt x11/library/libxi developer/assembler print/cups library/print/cups-libs Some of these packages are required for building OpenJDK, but not for closed Oracle product builds. (CUPS, for example) I am planning to set up a new Solaris 11.1 system later today - will check and send a follow-up if I discover more packages to install. Tim On 06/05/15 07:18, Semyon Sadetsky wrote: > How can I install them, just copy from sysroot/usr? Or it is possible > to skip conftest? > > --Semyon > > On 6/5/2015 5:09 PM, Erik Joelsson wrote: >> Actually, we might have issues in configure if the standard headers >> aren't available on the system. At least I have not tested that >> scenario and I can imagine that our SYSROOT_CFLAGS aren't always used >> in the configure tests. This is of course a bug, but a workaround >> would be to have the system headers installed on the system. They >> won't be used during the actual build. >> >> /Erik >> >> On 2015-06-05 15:05, Magnus Ihse Bursie wrote: >>> Did you use the --with-devkit option? >>> >>> /Magnus >>> >>>> 5 jun 2015 kl. 10:47 skrev Semyon Sadetsky >>>> : >>>> >>>> Hi, >>>> >>>> I have installed the devkit on clean Solaris 11.2 instance but >>>> configure fails because compiler cannot find the includes path: >>>> c -o conftest conftest.c >&5 >>>> "conftest.c", line 9: cannot find include file: >>>> "conftest.c", line 13: undefined symbol: FILE >>>> >>>> though devkit & sysroot path was detected by configure. >>>> Any reasons why? >>>> I did not not install normal solaris studio only the devkit. >>>> >>>> Thank you. >>>> --Semyon >>>> >>>> >>>>> On 6/3/2015 11:38 AM, Semyon Sadetsky wrote: >>>>> >>>>>> On 6/3/2015 11:28 AM, Magnus Ihse Bursie wrote: >>>>>>> On 2015-06-02 17:27, Semyon Sadetsky wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I'm trying to build jdk9 under the current Solaris 11.2 version. >>>>>>> Which version of the Solaris Studio should be installed for >>>>>>> that? The readme-builds states: >>>>>>> ... >>>>>>> At a minimum, the Studio 12 Update 1 Compilers (containing >>>>>>> version 5.10 of the C and C++ compilers) is required, including >>>>>>> specific patches. >>>>>>> ... >>>>>>> Currently there are 3 versions currently available for downloading: >>>>>>> >>>>>>> Oracle Solaris Studio 12.2 >>>>>>> Oracle Solaris Studio 12.3 >>>>>>> Oracle Solaris Studio 12.4 >>>>>>> >>>>>>> I tried all 3 and only with 12.3 I do no receive build warnings >>>>>>> about wrong compiler version, >>>>>>> but my build constantly fails with 12.3 with the next message: >>>>>>> >>>>>>> Compiling 246 files for jdk.jdi >>>>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line >>>>>>> 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", >>>>>>> line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>>>> ld: fatal: file >>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: >>>>>>> not an ELF object >>>>>>> gmake[3]: *** >>>>>>> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] >>>>>>> Error 2 >>>>>>> gmake[3]: *** Waiting for unfinished jobs.... >>>>>>> gmake[2]: *** [java.base-libs] Error 1 >>>>>>> >>>>>>> Even --disable-warnings-as-errors option does not save the build >>>>>>> from failure. >>>>>> That's because the warning does not cause the build failure. Read >>>>>> the logs again. :-) >>>>>> >>>>>> The real error here is "libjvm.so: not an ELF object" which >>>>>> causes the linking to fail for libverify.so. The warning from >>>>>> libjava is just a red herring. >>>>>> >>>>>> Your hotspot build is broken. Try >>>>>> "make clean-hotspot" >>>>>> "make hotspot" >>>>>> and see if you spot any errors. Otherwise you'd probably just >>>>>> left the build in a bad state. >>>>>> >>>>>> /Magnus >>>>> Thank you. In reality it was even worse when I add the option >>>>> disabling warnings as errors the VM hangs in the middle of the >>>>> build and those messages I got after restarting it and running the >>>>> incremental build. This scenario was reproduced 2 times with clean >>>>> build. So, my next attempt is a clean install with devkits. >>>>> >>>>> --Semyon >>>>> >>>>>>> Could you send me the software list with the versions that >>>>>>> should be installed on a clean Solaris 11.2 instance to have the >>>>>>> build running smoothly? >>>>>>> >>>>>>> Thank you, >>>>>>> --Semyon >> > From philip.race at oracle.com Fri Jun 5 15:38:24 2015 From: philip.race at oracle.com (Phil Race) Date: Fri, 05 Jun 2015 08:38:24 -0700 Subject: official compiler for Solaris jdk9 build? In-Reply-To: <5571B299.1080100@oracle.com> References: <556DCB7F.2020104@oracle.com> <556EBAC7.9080009@oracle.com> <556EBD21.6090805@oracle.com> <55716216.5080008@oracle.com> <4DB63F84-887E-4A08-A437-85E9D71CBF63@oracle.com> <5571AD96.3040304@oracle.com> <5571AFB3.7050009@oracle.com> <5571B299.1080100@oracle.com> Message-ID: <5571C270.1070506@oracle.com> On 06/05/2015 07:30 AM, Tim Bell wrote: > Hi > > I would not recommend copying files off some other system. > > The last time I started with a brand-new minimal Solaris 11.x install, > I needed to add: > > sudo pkg install gnu-tar system/header system/picl x11/library/libx11 > x11/library/libxrender x11/library/libxext x11/library/libxtst > x11/library/toolkit/libxt x11/library/libxi developer/assembler > print/cups library/print/cups-libs > > Some of these packages are required for building OpenJDK, but not for > closed Oracle product builds. (CUPS, for example) That does not sound right. There is no difference between Oracle JDK and OpenJDK regarding CUPS. In other words there is no "closed" printing code. There is an internal server hosting some of the required cups header files and perhaps you mean that internal builds can just point to those, but that is just a convenience and not anything to do with Oracle JDK. -phil. > > I am planning to set up a new Solaris 11.1 system later today - will > check and send a follow-up if I discover more packages to install. > > Tim > > > On 06/05/15 07:18, Semyon Sadetsky wrote: >> How can I install them, just copy from sysroot/usr? Or it is possible >> to skip conftest? >> >> --Semyon >> >> On 6/5/2015 5:09 PM, Erik Joelsson wrote: >>> Actually, we might have issues in configure if the standard headers >>> aren't available on the system. At least I have not tested that >>> scenario and I can imagine that our SYSROOT_CFLAGS aren't always >>> used in the configure tests. This is of course a bug, but a >>> workaround would be to have the system headers installed on the >>> system. They won't be used during the actual build. >>> >>> /Erik >>> >>> On 2015-06-05 15:05, Magnus Ihse Bursie wrote: >>>> Did you use the --with-devkit option? >>>> >>>> /Magnus >>>> >>>>> 5 jun 2015 kl. 10:47 skrev Semyon Sadetsky >>>>> : >>>>> >>>>> Hi, >>>>> >>>>> I have installed the devkit on clean Solaris 11.2 instance but >>>>> configure fails because compiler cannot find the includes path: >>>>> c -o conftest conftest.c >&5 >>>>> "conftest.c", line 9: cannot find include file: >>>>> "conftest.c", line 13: undefined symbol: FILE >>>>> >>>>> though devkit & sysroot path was detected by configure. >>>>> Any reasons why? >>>>> I did not not install normal solaris studio only the devkit. >>>>> >>>>> Thank you. >>>>> --Semyon >>>>> >>>>> >>>>>> On 6/3/2015 11:38 AM, Semyon Sadetsky wrote: >>>>>> >>>>>>> On 6/3/2015 11:28 AM, Magnus Ihse Bursie wrote: >>>>>>>> On 2015-06-02 17:27, Semyon Sadetsky wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm trying to build jdk9 under the current Solaris 11.2 version. >>>>>>>> Which version of the Solaris Studio should be installed for >>>>>>>> that? The readme-builds states: >>>>>>>> ... >>>>>>>> At a minimum, the Studio 12 Update 1 Compilers (containing >>>>>>>> version 5.10 of the C and C++ compilers) is required, including >>>>>>>> specific patches. >>>>>>>> ... >>>>>>>> Currently there are 3 versions currently available for >>>>>>>> downloading: >>>>>>>> >>>>>>>> Oracle Solaris Studio 12.2 >>>>>>>> Oracle Solaris Studio 12.3 >>>>>>>> Oracle Solaris Studio 12.4 >>>>>>>> >>>>>>>> I tried all 3 and only with 12.3 I do no receive build warnings >>>>>>>> about wrong compiler version, >>>>>>>> but my build constantly fails with 12.3 with the next message: >>>>>>>> >>>>>>>> Compiling 246 files for jdk.jdi >>>>>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", >>>>>>>> line 384: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>>>>> "/jdk9/client/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", >>>>>>>> line 496: warning: statement not reached (E_STATEMENT_NOT_REACHED) >>>>>>>> ld: fatal: file >>>>>>>> /jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/server/libjvm.so: >>>>>>>> not an ELF object >>>>>>>> gmake[3]: *** >>>>>>>> [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/modules_libs/java.base/amd64/libverify.so] >>>>>>>> Error 2 >>>>>>>> gmake[3]: *** Waiting for unfinished jobs.... >>>>>>>> gmake[2]: *** [java.base-libs] Error 1 >>>>>>>> >>>>>>>> Even --disable-warnings-as-errors option does not save the >>>>>>>> build from failure. >>>>>>> That's because the warning does not cause the build failure. >>>>>>> Read the logs again. :-) >>>>>>> >>>>>>> The real error here is "libjvm.so: not an ELF object" which >>>>>>> causes the linking to fail for libverify.so. The warning from >>>>>>> libjava is just a red herring. >>>>>>> >>>>>>> Your hotspot build is broken. Try >>>>>>> "make clean-hotspot" >>>>>>> "make hotspot" >>>>>>> and see if you spot any errors. Otherwise you'd probably just >>>>>>> left the build in a bad state. >>>>>>> >>>>>>> /Magnus >>>>>> Thank you. In reality it was even worse when I add the option >>>>>> disabling warnings as errors the VM hangs in the middle of the >>>>>> build and those messages I got after restarting it and running >>>>>> the incremental build. This scenario was reproduced 2 times with >>>>>> clean build. So, my next attempt is a clean install with devkits. >>>>>> >>>>>> --Semyon >>>>>> >>>>>>>> Could you send me the software list with the versions that >>>>>>>> should be installed on a clean Solaris 11.2 instance to have >>>>>>>> the build running smoothly? >>>>>>>> >>>>>>>> Thank you, >>>>>>>> --Semyon >>> >> > From valerie.peng at oracle.com Fri Jun 5 23:32:51 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Fri, 05 Jun 2015 16:32:51 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <55714DF2.7090100@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> Message-ID: <557231A3.4040403@oracle.com> I don't know image builder well enough to answer your question. Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. Thanks, Valerie On 6/5/2015 12:21 AM, Erik Joelsson wrote: > Hello Valerie, > > The merging seems ok, but I thought there was non determinism in the > image builder regarding which provider would get picked up. Is that > resolved or do you really need to override all of those providers with > your generated file in gensrc? I can assist in writing that makefile > logic if needed. > > /Erik > > On 2015-06-04 23:58, Valerie Peng wrote: >> Build experts, >> >> Can you please review the make file related change, i.e. the new file >> make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >> http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >> >> This is for merging the java.security.Provider file from various >> providers and use the (merged) result for the final image build. >> >> Thanks, >> Valerie >> >> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>> >>> Correct, if the makefile related changes are removed then no need >>> for build team to review 7191662 webrev anymore. >>> There are other discussions ongoing and we should be able to reach a >>> decision in a day or two. >>> Will update the list again. >>> Thanks, >>> Valerie >>> >>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>> >>>>> Please find comments in line... >>>>> >>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>> Valerie, >>>>>> >>>>>> Did you see my comment yesterday? >>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>> >>>>> Yes, we exchanged emails after this above one. I will follow up >>>>> your latest one later today. >>>>> >>>>>> >>>>>> Since you have reverted the java.security to keep the classname, >>>>>> to avoid causing merge conflict to jimage refresh, let?s remove >>>>>> the META-INF files in the first push and the build change. >>>>>> >>>>>> The security providers will be loaded via the fallback mechanism >>>>>> (i.e. ProviderLoader.legacyLoad method). You should keep the >>>>>> ProviderLoader.load method to take the provider name instead of >>>>>> classname. >>>>> Sure, I can remove the META-INF files so the providers are loaded >>>>> through the legacyLoad(). >>>>> Hmm, the ProviderLoader.load() method is used by java.security >>>>> file provider loading. Since the current list still uses class >>>>> name, it should take class name when checking for matches while >>>>> iterating through the list returned by ServiceLoader. >>>>> This way, when changes are sync'ed into Jake, no extra change >>>>> required and the providers will be loaded through >>>>> ProviderLoader.load() automatically with the current list. >>>>> >>>>>> I?ll file a bug to follow up to change java.security to list the >>>>>> provider name. This will wait after the jimage refresh goes into >>>>>> jdk9/dev >>>>> Ok. >>>>> Thanks, >>>>> Valerie >>>> >>>> I'm not sure I followed completely here were this landed. Does this >>>> mean that there's currently no need for a build system code review >>>> on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and >>>> that a new webrev will be posted instead? >>>> >>>> /Magnus >>>> >>>> >>>> >>>>>> . >>>>>> >>>>>> Mandy >>>>>> >>>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>>> Peng wrote: >>>>>>> >>>>>>> Hi, build experts, >>>>>>> >>>>>>> Can you please review the make file related change, i.e. the new >>>>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>> >>>>>>> This is for merging the java.security.Provider file from various >>>>>>> providers and use the (merged) result for the final image build. >>>>>>> >>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> (Java Security Team) >>>> >>> > From mandy.chung at oracle.com Sat Jun 6 05:43:18 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 5 Jun 2015 22:43:18 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557231A3.4040403@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> Message-ID: <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> > On Jun 5, 2015, at 4:32 PM, Valerie Peng wrote: > > > I don't know image builder well enough to answer your question. The current implementation of the image builder sorts the modules by their name that are mapped to the same class loader. That explains why java.naming is the first one containing META-INF/services/java.security.Provider in your current list. There is no guarantee in what particular order a module is processed first. I don?t know if the jimage refresh work will change the ordering either. Since this is temporary, I?m okay if you want to depend on the image build implementation as long as you have a test to catch it and verify java.naming/META-INF/services/java.security.Provider file content. The existing security tests may also catch it but I think it?s not obvious to indicate that the security tests fail because of the issue of the merged service configuration file. Please also hold off until the image refresh change goes into jdk9/dev so that you can verify if your build change still works. If you want to push earlier, another alternative we discussed earlier is to separate the META-INF/services file and make change and java.security to keep using classname. That can be pushed that in a second phase with a proper image builder support. Mandy > Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. > > Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. > Thanks, > Valerie > > On 6/5/2015 12:21 AM, Erik Joelsson wrote: >> Hello Valerie, >> >> The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. >> >> /Erik >> >> On 2015-06-04 23:58, Valerie Peng wrote: >>> Build experts, >>> >>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>> >>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>> >>> Thanks, >>> Valerie >>> >>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>> >>>> Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. >>>> There are other discussions ongoing and we should be able to reach a decision in a day or two. >>>> Will update the list again. >>>> Thanks, >>>> Valerie >>>> >>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>> >>>>>> Please find comments in line... >>>>>> >>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>> Valerie, >>>>>>> >>>>>>> Did you see my comment yesterday? >>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>> Yes, we exchanged emails after this above one. I will follow up your latest one later today. >>>>>> >>>>>>> >>>>>>> Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. >>>>>>> >>>>>>> The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. >>>>>> Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). >>>>>> Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. >>>>>> This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. >>>>>> >>>>>>> I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev >>>>>> Ok. >>>>>> Thanks, >>>>>> Valerie >>>>> >>>>> I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>>>> . >>>>>>> >>>>>>> Mandy >>>>>>> >>>>>>>> On May 27, 2015, at 3:29 PM, Valerie Peng wrote: >>>>>>>> >>>>>>>> Hi, build experts, >>>>>>>> >>>>>>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>> >>>>>>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>>>>>> >>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>>> (Java Security Team) >>>>> >>>> >> From erik.joelsson at oracle.com Mon Jun 8 09:05:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 08 Jun 2015 11:05:02 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <55755ABE.9010000@oracle.com> Hello, Looks pretty good. Found some typos: jdk_util.c: 99: specia_update_version jdk-version.m4: 31: assing 124, 132: --with--version-pre-base has a dash too many? I see this pattern consistently used though, am I missing something? /Erik On 2015-06-05 16:07, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > [1] http://openjdk.java.net/jeps/223 > From Alan.Bateman at oracle.com Mon Jun 8 09:34:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Jun 2015 10:34:12 +0100 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <55756194.3080506@oracle.com> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 I looked through the code changes, skipping most of the make files :-) Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". The webrev shows a change to this comment in jvm.h: "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." I think this comment can be removed because those JVM_* functions were removed some time ago. Otherwise looks okay to me. -Alan. From magnus.ihse.bursie at oracle.com Mon Jun 8 12:37:01 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 8 Jun 2015 14:37:01 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55756194.3080506@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> Message-ID: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> > 8 jun 2015 kl. 11:34 skrev Alan Bateman : > >> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: >> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". >> >> This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. >> >> The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. >> >> This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 >> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > I looked through the code changes, skipping most of the make files :-) > > Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? > > Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". > > The webrev shows a change to this comment in jvm.h: > "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." > I think this comment can be removed because those JVM_* functions were removed some time ago. > > Otherwise looks okay to me. The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. Are you ok with addressing these concerns at such a later time? /Magnus > > -Alan. From sundararajan.athijegannathan at oracle.com Mon Jun 8 12:55:17 2015 From: sundararajan.athijegannathan at oracle.com (A. Sundararajan) Date: Mon, 08 Jun 2015 18:25:17 +0530 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> Message-ID: <557590B5.8090906@oracle.com> +1 on Nashorn changes. -Sundar On Monday 08 June 2015 06:07 PM, Magnus Ihse Bursie wrote: >> 8 jun 2015 kl. 11:34 skrev Alan Bateman : >> >>> On 05/06/2015 15:07, Magnus Ihse Bursie wrote: >>> This review request covers the main part of the work for JEP-223, the new version string format [1]. Basically, we'll call this release Java "9", instead of Java "1.9.0". >>> >>> This patch is a folding of all work that has been done so far in the branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly covers build changes, with some code changes in hotspot, jdk, nashorn and langtools that either are corresponding changes in the product code due to the compiler define flags changing from the build, or follow-up changes to handle the new format. >>> >>> The JEP-223 work is not finished by this patch. In fact, there are known issues remaining even after this patch, typically by code that reads the "java.version" property and tries to parse it. However, this patch is not directly destined for jdk9/dev, but will go into the special verona/stage forest. As for all patches destined for verona/stage it will be code reviewed as if going to jdk9/dev. Once in verona/stage it will bide its time, and it will be complemented with follow-up patches to address remaining issues. When all such issues are resolved and JEP-223 is fully implemented, all changes will be pushed at once (without further code reviews) into jdk9/dev. >>> >>> This patch has been contributed by Magnus Ihse Bursie, Kumar Srinivasan and Alejandro Murillo. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 >>> WebRev: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> I looked through the code changes, skipping most of the make files :-) >> >> Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? >> >> Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info stricture? Related, there seems to be a typo in the comment in jdk_util.c where it has "specia_update_version". >> >> The webrev shows a change to this comment in jvm.h: >> "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." >> I think this comment can be removed because those JVM_* functions were removed some time ago. >> >> Otherwise looks okay to me. > The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. > > Are you ok with addressing these concerns at such a later time? > > /Magnus > >> -Alan. From Alan.Bateman at oracle.com Mon Jun 8 20:41:09 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 08 Jun 2015 21:41:09 +0100 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> References: <5571AD18.7080701@oracle.com> <55756194.3080506@oracle.com> <1136B10A-72A2-421D-8333-1943353F662C@oracle.com> Message-ID: <5575FDE5.5020002@oracle.com> On 08/06/2015 13:37, Magnus Ihse Bursie wrote: > : > The API functions in Version.java and jvm.h are not finished. The specification in the JEP talks about a java.util.Version, that I presume will replace the sun.misc.Version, and that will fully implement an API to access the version string and all it's parts, according to the JEP definition. Also, the native interface will have to be changed to accommodate a version number with an arbitrarily number of dot separated parts. These changes will be done later on in the verona/stage forest. > > Are you ok with addressing these concerns at such a later time? > Sure, esp. since my comments are indeed in the area that isn't complete in this webrev. -Alan From naoto.sato at oracle.com Mon Jun 8 20:58:31 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 08 Jun 2015 13:58:31 -0700 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) Message-ID: <557601F7.5060209@oracle.com> Hello, Please review the proposed changes for 8008577[1], the implementation of the JEP-252[2]. The proposed changes are located at: http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ Here are the very high level summary of changes: - Now the default locale provider order is CLDR,JRE,SPI. - The CLDR data is upgraded from 21.0.1 to 27.0.0 - According the CLDR upgrade, the converter tool and the runtime are now capable of "alias" and "parentLocales" tags. - Regression tests that are specific to the existing JRE locale data are now run specifically with "JRE,SPI" providers. I would like the build group to review the build changes mainly with the CLDR changes, and i18n group for the rest. Naoto -- [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 From daniel.daugherty at oracle.com Mon Jun 8 23:31:20 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Mon, 08 Jun 2015 17:31:20 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5571AD18.7080701@oracle.com> References: <5571AD18.7080701@oracle.com> Message-ID: <557625C8.5050200@oracle.com> > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 General comment: Not all copyright years were updated. General comment: It looks like support for the 'patch' value is not completely implemented through all the Makefiles. I didn't audit for this, but it's just my impression. common/autoconf/configure.ac No comments. common/autoconf/flags.m4 No comments. common/autoconf/generated-configure.sh There are multiple Copyright notices in this file. Why? L4076: # Verify that a given string represent a valid version number, and assing it to L4077: # a variable. Fixed two typos and reformat a bit: # Verify that a given string represents a valid version number, and # assigning it to a variable. L20186-20189: indent for the block is off L20256-20259: indent for the block is off L20262: as_fn_error $? "--with--version-string must have a value" "$LINENO" 5 The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20275: # Unspecified numerical fields is interpreted as 0. Grammar: 'is interpreted' -> 'are interpreted' L20286: as_fn_error $? "Version string contains + but both 'BUILD' and 'OPT' is missing" "$LINENO" 5 Grammar: 'is missing' -> 'are missing' L20292: as_fn_error $? "--with--version-string fails to parse The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20297-L20302: indent for the block is off L20307: as_fn_error $? "--with--version-pre-base must have a value" "$LINENO" 5 L20315: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-pre-base value... L20316: $as_echo "$as_me: WARNING: --with--version-pre-base value... The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20327-20332: indent for the block is off L20337: as_fn_error $? "--with--version-pre-debuglevel must have... L20345: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-pre-debuglevel value... L20346: $as_echo "$as_me: WARNING: --with--version-pre-debuglevel value The '--with--version...' part doesn't match previous usages where '--with-version...' is used L20361-20366: indent for the block is off L20371: as_fn_error $? "--with--version-opt must have... L20379: { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: --with--version-opt value L20380: $as_echo "$as_me: WARNING: --with--version-opt value has been The '--with--version...' part doesn't match previous usages where '--with-version...' is used At this point, I'm going to stop pointing out the '--with-version...' and '--with--version...' differences; don't know which usage is right. L20388-L20388: indent is off by one L20388: username=`$ECHO "$USER" | $TR -d -c '[a-z][A-Z][0-9]'` This assumes that the "USER" variable is set. Should there be a check for "" and perhaps use "no_user_specified" or something like that? Perhaps the build setup always makes sure that "USER" is set to something. Don't know. L20395-L20400: indent for the block is off L20413-L20431: indent of all blocks in this range are off L20444-L20449: indent for the block is off L20457-L20475: indent of all blocks in this range are off L20486-L20491: indent for the block is off L20504-L20522: indent of all blocks in this range are off L20533-L20538: indent for the block is off L20551-L20569: indent of all blocks in this range are off L20580-L20585: indent for the block is off L20598-L20616: indent of all blocks in this range are off common/autoconf/help.m4 No comments. common/autoconf/jdk-options.m4 Don't know why the 'elliptic curve crypto implementation' support is relocated as part of this changeset, but ... No comments. common/autoconf/spec.gmk.in No comments. common/autoconf/version-numbers No comments. common/nb_native/nbproject/configurations.xml No comments. make/Images.gmk No comments. make/Install.gmk No comments. make/Javadoc.gmk Did you mean to remove the 'clean' target? make/JrtfsJar.gmk No comments. make/MacBundles.gmk No comments. make/jprt.properties No comments. hotspot/make/Makefile No comments. hotspot/make/aix/Makefile No comments. hotspot/make/aix/makefiles/buildtree.make No comments. hotspot/make/aix/makefiles/defs.make No comments. hotspot/make/aix/makefiles/vm.make No comments. hotspot/make/bsd/Makefile No comments. hotspot/make/bsd/makefiles/buildtree.make No comments. hotspot/make/bsd/makefiles/defs.make No comments. hotspot/make/bsd/makefiles/vm.make No comments. hotspot/make/defs.make No comments. hotspot/make/jdk_version No comments. hotspot/make/linux/Makefile No comments. hotspot/make/linux/makefiles/buildtree.make No comments. hotspot/make/linux/makefiles/defs.make No comments. hotspot/make/linux/makefiles/vm.make No comments. hotspot/make/solaris/Makefile No comments. hotspot/make/solaris/makefiles/buildtree.make No comments. hotspot/make/solaris/makefiles/defs.make No comments. hotspot/make/solaris/makefiles/sparcWorks.make No comments. hotspot/make/solaris/makefiles/vm.make No comments. hotspot/make/windows/build.make No comments. hotspot/make/windows/makefiles/compile.make No changes in the frames view. Update: udiff view shows a blank line deleted at the end of the file. hotspot/make/windows/makefiles/debug.make No comments. hotspot/make/windows/makefiles/defs.make No comments. hotspot/make/windows/makefiles/fastdebug.make No comments. hotspot/make/windows/makefiles/product.make No comments. hotspot/make/windows/makefiles/vm.make No comments. hotspot/make/windows/projectfiles/common/Makefile No comments. hotspot/src/share/vm/prims/jvm.h No comments. hotspot/src/share/vm/runtime/arguments.cpp No comments. hotspot/src/share/vm/runtime/java.cpp L661: void JDK_Version::fully_initialize( L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t update) { L663: // This is only called when current is less than 1.6 and we've gotten Since you're ripping out vestigial version support, I think this function can go away since this is version 9 and newer. Don't really know for sure, but based on that comment... hotspot/src/share/vm/runtime/java.hpp No comments. hotspot/src/share/vm/runtime/vmStructs.cpp L1240: please make the 'int' parameter align like the rest. hotspot/src/share/vm/runtime/vm_version.cpp L84: void Abstract_VM_Version::initialize() { L85: // FIXME: Initialization can probably be removed now. I agree, but that would entail also removing the _initialized and the uses of it... Follow on bug fix? hotspot/src/share/vm/runtime/vm_version.hpp No comments. hotspot/test/runtime/6981737/Test6981737.java No comments. jdk/make/CompileDemos.gmk No comments. jdk/make/data/mainmanifest/manifest.mf No comments. jdk/make/gensrc/GensrcMisc.gmk No comments. jdk/make/launcher/Launcher-jdk.accessibility.gmk No comments. jdk/make/launcher/Launcher-jdk.pack200.gmk No comments. jdk/make/launcher/LauncherCommon.gmk No comments. jdk/make/lib/CoreLibraries.gmk No comments. jdk/src/java.base/share/classes/sun/misc/Version.java.template L149: * Returns the security version of the running JVM if it's 1.6 or newer This JavaDoc update is wrong, but it might not be important if sun.misc.Version class is going away. jdk/src/java.base/share/native/include/jvm.h No comments. jdk/src/java.base/share/native/launcher/defines.h No comments. jdk/src/java.base/share/native/launcher/main.c No comments. jdk/src/java.base/share/native/libjava/System.c No comments. jdk/src/java.base/share/native/libjava/Version.c No comments. jdk/src/java.base/share/native/libjava/jdk_util.c No comments. jdk/src/java.base/windows/native/common/version.rc No comments. jdk/src/java.desktop/windows/native/libawt/windows/awt.rc No comments. jdk/src/jdk.accessibility/windows/native/common/AccessBridgeStatusWindow.RC No comments. jdk/test/sun/misc/Version/Version.java No comments. langtools/make/gensrc/GensrcCommon.gmk No comments. langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java old L171: case "1.9": new L171: case "9": Should this logic support both versions? Will dropping "1.9" here prevent a pre-version changeset JVM from being dropped into a JDK for triage purposes? Granted we don't often triage 'javac' with different JVMs, but... langtools/test/tools/javac/options/modes/InfoOptsTest.java No comments. langtools/test/tools/javac/options/modes/SourceTargetTest.java No comments. nashorn/make/BuildNashorn.gmk No comments. nashorn/make/build.xml No comments. nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/Version.java No comments. common/autoconf/jdk-version.m4 No comments. nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties.template nashorn/src/jdk.scripting.nashorn/share/classes/jdk/nashorn/internal/runtime/resources/version.properties-template No comments. common/bin/test_builds.sh hotspot/make/jdk6_hotspot_distro No comments. Dan On 6/5/15 8:07 AM, Magnus Ihse Bursie wrote: > This review request covers the main part of the work for JEP-223, the > new version string format [1]. Basically, we'll call this release Java > "9", instead of Java "1.9.0". > > This patch is a folding of all work that has been done so far in the > branch JEP-223-branch in jdk9/sandbox. As you can see, it mostly > covers build changes, with some code changes in hotspot, jdk, nashorn > and langtools that either are corresponding changes in the product > code due to the compiler define flags changing from the build, or > follow-up changes to handle the new format. > > The JEP-223 work is not finished by this patch. In fact, there are > known issues remaining even after this patch, typically by code that > reads the "java.version" property and tries to parse it. However, this > patch is not directly destined for jdk9/dev, but will go into the > special verona/stage forest. As for all patches destined for > verona/stage it will be code reviewed as if going to jdk9/dev. Once in > verona/stage it will bide its time, and it will be complemented with > follow-up patches to address remaining issues. When all such issues > are resolved and JEP-223 is fully implemented, all changes will be > pushed at once (without further code reviews) into jdk9/dev. > > This patch has been contributed by Magnus Ihse Bursie, Kumar > Srinivasan and Alejandro Murillo. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8085822 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > [1] http://openjdk.java.net/jeps/223 > From valerie.peng at oracle.com Mon Jun 8 23:44:56 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 08 Jun 2015 16:44:56 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> Message-ID: <557628F8.8000001@oracle.com> What is the bug id for the image refresh change? Just so I can keep a watch and hold my changes for the time being. My webrev has a new regression test which compares the list of providers found by ServiceLoader and Security.getProviders() call. So, if the META-INF/services/java.security.Provider file content is not correct, the new test would fail and it's a clear indication that ServiceLoader can't find one or more of the providers. Thanks, Valerie On 6/5/2015 10:43 PM, Mandy Chung wrote: >> On Jun 5, 2015, at 4:32 PM, Valerie Peng wrote: >> >> >> I don't know image builder well enough to answer your question. > The current implementation of the image builder sorts the modules by their name that are mapped to the same class loader. That explains why java.naming is the first one containing META-INF/services/java.security.Provider in your current list. > > There is no guarantee in what particular order a module is processed first. I don?t know if the jimage refresh work will change the ordering either. Since this is temporary, I?m okay if you want to depend on the image build implementation as long as you have a test to catch it and verify java.naming/META-INF/services/java.security.Provider file content. The existing security tests may also catch it but I think it?s not obvious to indicate that the security tests fail because of the issue of the merged service configuration file. > > Please also hold off until the image refresh change goes into jdk9/dev so that you can verify if your build change still works. > > If you want to push earlier, another alternative we discussed earlier is to separate the META-INF/services file and make change and java.security to keep using classname. That can be pushed that in a second phase with a proper image builder support. > > Mandy > >> Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. >> >> Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. >> Thanks, >> Valerie >> >> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>> Hello Valerie, >>> >>> The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. >>> >>> /Erik >>> >>> On 2015-06-04 23:58, Valerie Peng wrote: >>>> Build experts, >>>> >>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>> >>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>> >>>> Thanks, >>>> Valerie >>>> >>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>> Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. >>>>> There are other discussions ongoing and we should be able to reach a decision in a day or two. >>>>> Will update the list again. >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>> Please find comments in line... >>>>>>> >>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>> Valerie, >>>>>>>> >>>>>>>> Did you see my comment yesterday? >>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>> Yes, we exchanged emails after this above one. I will follow up your latest one later today. >>>>>>> >>>>>>>> Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. >>>>>>>> >>>>>>>> The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. >>>>>>> Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). >>>>>>> Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. >>>>>>> This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. >>>>>>> >>>>>>>> I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev >>>>>>> Ok. >>>>>>> Thanks, >>>>>>> Valerie >>>>>> I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? >>>>>> >>>>>> /Magnus >>>>>> >>>>>> >>>>>> >>>>>>>> . >>>>>>>> >>>>>>>> Mandy >>>>>>>> >>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie Peng wrote: >>>>>>>>> >>>>>>>>> Hi, build experts, >>>>>>>>> >>>>>>>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>> >>>>>>>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>>>>>>> >>>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>>> (Java Security Team) From mandy.chung at oracle.com Mon Jun 8 23:53:50 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 08 Jun 2015 16:53:50 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557628F8.8000001@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> Message-ID: <55762B0E.4090407@oracle.com> JDK-8066492 Mandy On 06/08/2015 04:44 PM, Valerie Peng wrote: > > What is the bug id for the image refresh change? Just so I can keep a > watch and hold my changes for the time being. > > My webrev has a new regression test which compares the list of > providers found by ServiceLoader and Security.getProviders() call. So, > if the META-INF/services/java.security.Provider file content is not > correct, the new test would fail and it's a clear indication that > ServiceLoader can't find one or more of the providers. > > Thanks, > Valerie > > On 6/5/2015 10:43 PM, Mandy Chung wrote: >>> On Jun 5, 2015, at 4:32 PM, Valerie Peng >>> wrote: >>> >>> >>> I don't know image builder well enough to answer your question. >> The current implementation of the image builder sorts the modules by >> their name that are mapped to the same class loader. That explains >> why java.naming is the first one containing >> META-INF/services/java.security.Provider in your current list. >> >> There is no guarantee in what particular order a module is processed >> first. I don?t know if the jimage refresh work will change the >> ordering either. Since this is temporary, I?m okay if you want to >> depend on the image build implementation as long as you have a test >> to catch it and verify >> java.naming/META-INF/services/java.security.Provider file content. >> The existing security tests may also catch it but I think it?s not >> obvious to indicate that the security tests fail because of the issue >> of the merged service configuration file. >> >> Please also hold off until the image refresh change goes into >> jdk9/dev so that you can verify if your build change still works. >> >> If you want to push earlier, another alternative we discussed earlier >> is to separate the META-INF/services file and make change and >> java.security to keep using classname. That can be pushed that in a >> second phase with a proper image builder support. >> >> Mandy >> >>> Based on my own experiment, it seems to pick up the one from >>> java.naming when duplication occurs, so that's why I saved the >>> merged result to there and named the Gensrc makefile with >>> java.naming. The result build work fine. >>> >>> Does this explain what I am trying to do here? If you have better >>> ways to get this done, I am certainly open to that idea. >>> Thanks, >>> Valerie >>> >>> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>>> Hello Valerie, >>>> >>>> The merging seems ok, but I thought there was non determinism in >>>> the image builder regarding which provider would get picked up. Is >>>> that resolved or do you really need to override all of those >>>> providers with your generated file in gensrc? I can assist in >>>> writing that makefile logic if needed. >>>> >>>> /Erik >>>> >>>> On 2015-06-04 23:58, Valerie Peng wrote: >>>>> Build experts, >>>>> >>>>> Can you please review the make file related change, i.e. the new >>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>>> >>>>> This is for merging the java.security.Provider file from various >>>>> providers and use the (merged) result for the final image build. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>>> Correct, if the makefile related changes are removed then no need >>>>>> for build team to review 7191662 webrev anymore. >>>>>> There are other discussions ongoing and we should be able to >>>>>> reach a decision in a day or two. >>>>>> Will update the list again. >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>>> Please find comments in line... >>>>>>>> >>>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>>> Valerie, >>>>>>>>> >>>>>>>>> Did you see my comment yesterday? >>>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>>>> >>>>>>>> Yes, we exchanged emails after this above one. I will follow up >>>>>>>> your latest one later today. >>>>>>>> >>>>>>>>> Since you have reverted the java.security to keep the >>>>>>>>> classname, to avoid causing merge conflict to jimage refresh, >>>>>>>>> let?s remove the META-INF files in the first push and the >>>>>>>>> build change. >>>>>>>>> >>>>>>>>> The security providers will be loaded via the fallback >>>>>>>>> mechanism (i.e. ProviderLoader.legacyLoad method). You should >>>>>>>>> keep the ProviderLoader.load method to take the provider name >>>>>>>>> instead of classname. >>>>>>>> Sure, I can remove the META-INF files so the providers are >>>>>>>> loaded through the legacyLoad(). >>>>>>>> Hmm, the ProviderLoader.load() method is used by java.security >>>>>>>> file provider loading. Since the current list still uses class >>>>>>>> name, it should take class name when checking for matches while >>>>>>>> iterating through the list returned by ServiceLoader. >>>>>>>> This way, when changes are sync'ed into Jake, no extra change >>>>>>>> required and the providers will be loaded through >>>>>>>> ProviderLoader.load() automatically with the current list. >>>>>>>> >>>>>>>>> I?ll file a bug to follow up to change java.security to list >>>>>>>>> the provider name. This will wait after the jimage refresh >>>>>>>>> goes into jdk9/dev >>>>>>>> Ok. >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>> I'm not sure I followed completely here were this landed. Does >>>>>>> this mean that there's currently no need for a build system code >>>>>>> review on >>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and >>>>>>> that a new webrev will be posted instead? >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>>>>>> Peng wrote: >>>>>>>>>> >>>>>>>>>> Hi, build experts, >>>>>>>>>> >>>>>>>>>> Can you please review the make file related change, i.e. the >>>>>>>>>> new file make/gensrc/Gensrc-java.naming.gmk, in the following >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>>> >>>>>>>>>> This is for merging the java.security.Provider file from >>>>>>>>>> various providers and use the (merged) result for the final >>>>>>>>>> image build. >>>>>>>>>> >>>>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> (Java Security Team) From jan.lahoda at oracle.com Tue Jun 9 04:57:58 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Tue, 09 Jun 2015 06:57:58 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <55767256.3030802@oracle.com> On 9.6.2015 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > > old L171: case "1.9": > new L171: case "9": > Should this logic support both versions? Will dropping > "1.9" here prevent a pre-version changeset JVM from > being dropped into a JDK for triage purposes? > > Granted we don't often triage 'javac' with different JVMs, but... > +1 on keeping both "1.9" and "9" here. javac can be used independently on the rest of JDK to some extent, so support for running it on older builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 javac should be prepared for the new version scheme in advance.) Jan From erik.joelsson at oracle.com Tue Jun 9 07:59:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 09 Jun 2015 09:59:41 +0200 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <557601F7.5060209@oracle.com> References: <557601F7.5060209@oracle.com> Message-ID: <55769CED.7000400@oracle.com> Hello Naoto, Build changes look good to me. /Erik On 2015-06-08 22:58, Naoto Sato wrote: > Hello, > > Please review the proposed changes for 8008577[1], the implementation > of the JEP-252[2]. The proposed changes are located at: > > http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ > > Here are the very high level summary of changes: > > - Now the default locale provider order is CLDR,JRE,SPI. > - The CLDR data is upgraded from 21.0.1 to 27.0.0 > - According the CLDR upgrade, the converter tool and the runtime are > now capable of "alias" and "parentLocales" tags. > - Regression tests that are specific to the existing JRE locale data > are now run specifically with "JRE,SPI" providers. > > I would like the build group to review the build changes mainly with > the CLDR changes, and i18n group for the rest. > > Naoto > -- > [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 > [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 From magnus.ihse.bursie at oracle.com Tue Jun 9 13:12:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:12:19 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <5576E633.9050503@oracle.com> Hi Daniel, Thank you for your thorough review! On 2015-06-09 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > > General comment: Not all copyright years were updated. > General comment: It looks like support for the 'patch' value is not > completely > implemented through all the Makefiles. I didn't audit for this, > but it's > just my impression. You are basically correct. The makefiles all propagate the patch value where needed, but the actual source code changes in hotspot and jdk ignores the patch field as of now. This will be corrected in a later add-on patch, submitted by someone from the jdk and/or hotspot team rather than the build team. > > common/autoconf/generated-configure.sh > There are multiple Copyright notices in this file. Why? Oh dear, you've reviewed the generated file. :-& I'm really impressed by your effort! However, the generated-configure.sh file is automatically created by the autoconf framework from the rest of the files in common/autoconf/*, so we cannot direcly modify it's contents - only indirectly. The reason it's checked in, is that otherwise every user would need to generate it before being able to run configure. In build reviews, we usually either revert changes to generated-configure.sh before posting a review to hide it (and re-generate it before pushing), or we just ignore it during reviews. I should have done that, or pointed out that it was not needed nor possible to review when I cross-posted. I'm sorry. > > L4076: # Verify that a given string represent a valid version > number, and assing it to > L4077: # a variable. > Fixed two typos and reformat a bit: > # Verify that a given string represents a valid version > number, and > # assigning it to a variable. I'll put that fix in the source .m4 file instead. Thanks. > > L20262: as_fn_error $? "--with--version-string must have a > value" "$LINENO" 5 > The '--with--version...' part doesn't match previous usages where > '--with-version...' is used Yes, you're right. Erik pointed it out as well. It's a typo in the error message. It's all over the place due to copied code. I'll fix it in the source .m4 file. (As a side note, I have a half-finished follow-up patch that will reduce the amount of code duplication, but it requires some framework changes so it'll have to be a separate thing.) > > L20275: # Unspecified numerical fields is interpreted as 0. > Grammar: 'is interpreted' -> 'are interpreted' > > L20286: as_fn_error $? "Version string contains + but both > 'BUILD' and 'OPT' is missing" "$LINENO" 5 > Grammar: 'is missing' -> 'are missing' Those darn English plural forms! Why can't you all do as we sensible Swedes and get rid of them? ;-) (I'll fix) > > L20388: username=`$ECHO "$USER" | $TR -d -c '[a-z][A-Z][0-9]'` > This assumes that the "USER" variable is set. Should there > be a check for "" and perhaps use "no_user_specified" or > something like that? Perhaps the build setup always makes > sure that "USER" is set to something. Don't know. Hm. I think the worst thing that'll happen is that the username part of the opt string gets empty. This part is basically copied right off the old build, where we have relied on the $USER variable being present for all the time with no problems, so I think it's quite safe to assume. > > common/autoconf/jdk-options.m4 > Don't know why the 'elliptic curve crypto implementation' support > is relocated as part of this changeset, but ... It was incorrectly placed not at the top indentation level, but in the middle of the function definition where the old versioning code were handled. (Which, mostly by chance, happens to work in autoconf, but is really bad style). > make/Javadoc.gmk > Did you mean to remove the 'clean' target? Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, that's just some dead code. > > hotspot/make/windows/makefiles/compile.make > No changes in the frames view. > Update: udiff view shows a blank line deleted at the end of the file. That's probably the result of some change going forth and then back again during development. But then again, removing extra blank linkes is not a bad thing. (jcheck unfortunately does not enforce any style checks for make files :-( so they tend to detoriate over time.) > > hotspot/src/share/vm/runtime/java.cpp > L661: void JDK_Version::fully_initialize( > L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t > update) { > L663: // This is only called when current is less than 1.6 and > we've gotten > > Since you're ripping out vestigial version support, I think this > function can go away since this is version 9 and newer. Don't > really > know for sure, but based on that comment... It probably can, yes. This and other core changes to the actual .cpp/.java files will be addressed in a follow-up patch. > > hotspot/src/share/vm/runtime/java.hpp > No comments. > > hotspot/src/share/vm/runtime/vmStructs.cpp > L1240: please make the 'int' parameter align like the rest. Are you okay with defering such a change to a follow-up patch? It's likely the entire struct will need changes to be able to handle a theoretically arbitrarily long version number. > > hotspot/src/share/vm/runtime/vm_version.cpp > L84: void Abstract_VM_Version::initialize() { > L85: // FIXME: Initialization can probably be removed now. > I agree, but that would entail also removing the > _initialized and the uses of it... Follow on bug fix? Definitely follow on. > jdk/src/java.base/share/classes/sun/misc/Version.java.template > L149: * Returns the security version of the running JVM if > it's 1.6 or newer > This JavaDoc update is wrong, but it might not be important > if sun.misc.Version class is going away. I'm not sure if it's going to be replaced by, or just complemented by java.util.Version, but in any case it will need a follow-up patch to clean up this and other issues. > langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java > > old L171: case "1.9": > new L171: case "9": > Should this logic support both versions? Will dropping > "1.9" here prevent a pre-version changeset JVM from > being dropped into a JDK for triage purposes? > > Granted we don't often triage 'javac' with different JVMs, but... I'll defer that question to Kumar, who wrote that piece of code. My guess is that when Hotspot express was dropped, the ability to use a JVM from another JDK release bit rotteded away. /Magnus From daniel.daugherty at oracle.com Tue Jun 9 13:20:27 2015 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 09 Jun 2015 07:20:27 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E633.9050503@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> Message-ID: <5576E81B.8050703@oracle.com> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: > Hi Daniel, > > Thank you for your thorough review! This was my (failing) attempt at a "fast pass" review... :-) > > On 2015-06-09 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> >> General comment: Not all copyright years were updated. >> General comment: It looks like support for the 'patch' value is not >> completely >> implemented through all the Makefiles. I didn't audit for this, >> but it's >> just my impression. > > You are basically correct. The makefiles all propagate the patch value > where needed, but the actual source code changes in hotspot and jdk > ignores the patch field as of now. This will be corrected in a later > add-on patch, submitted by someone from the jdk and/or hotspot team > rather than the build team. > >> >> common/autoconf/generated-configure.sh >> There are multiple Copyright notices in this file. Why? > Oh dear, you've reviewed the generated file. :-& I'm really impressed > by your effort! Ahhh... now that you say it... it sounds familiar... I may have made this same mistake before. I'll try to remember next time. > However, the generated-configure.sh file is automatically created by > the autoconf framework from the rest of the files in > common/autoconf/*, so we cannot direcly modify it's contents - only > indirectly. The reason it's checked in, is that otherwise every user > would need to generate it before being able to run configure. In build > reviews, we usually either revert changes to generated-configure.sh > before posting a review to hide it (and re-generate it before > pushing), or we just ignore it during reviews. I should have done > that, or pointed out that it was not needed nor possible to review > when I cross-posted. I'm sorry. > >> >> L4076: # Verify that a given string represent a valid version >> number, and assing it to >> L4077: # a variable. >> Fixed two typos and reformat a bit: >> # Verify that a given string represents a valid version >> number, and >> # assigning it to a variable. > I'll put that fix in the source .m4 file instead. Thanks. >> >> L20262: as_fn_error $? "--with--version-string must have a >> value" "$LINENO" 5 >> The '--with--version...' part doesn't match previous usages >> where >> '--with-version...' is used > Yes, you're right. Erik pointed it out as well. It's a typo in the > error message. It's all over the place due to copied code. I'll fix it > in the source .m4 file. > > (As a side note, I have a half-finished follow-up patch that will > reduce the amount of code duplication, but it requires some framework > changes so it'll have to be a separate thing.) > >> >> L20275: # Unspecified numerical fields is interpreted as 0. >> Grammar: 'is interpreted' -> 'are interpreted' >> >> L20286: as_fn_error $? "Version string contains + but >> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >> Grammar: 'is missing' -> 'are missing' > Those darn English plural forms! Why can't you all do as we sensible > Swedes and get rid of them? ;-) > > (I'll fix) > >> >> L20388: username=`$ECHO "$USER" | $TR -d -c >> '[a-z][A-Z][0-9]'` >> This assumes that the "USER" variable is set. Should there >> be a check for "" and perhaps use "no_user_specified" or >> something like that? Perhaps the build setup always makes >> sure that "USER" is set to something. Don't know. > Hm. I think the worst thing that'll happen is that the username part > of the opt string gets empty. This part is basically copied right off > the old build, where we have relied on the $USER variable being > present for all the time with no problems, so I think it's quite safe > to assume. >> >> common/autoconf/jdk-options.m4 >> Don't know why the 'elliptic curve crypto implementation' support >> is relocated as part of this changeset, but ... > It was incorrectly placed not at the top indentation level, but in the > middle of the function definition where the old versioning code were > handled. (Which, mostly by chance, happens to work in autoconf, but is > really bad style). > >> make/Javadoc.gmk >> Did you mean to remove the 'clean' target? > Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, > that's just some dead code. > >> >> hotspot/make/windows/makefiles/compile.make >> No changes in the frames view. >> Update: udiff view shows a blank line deleted at the end of the >> file. > > That's probably the result of some change going forth and then back > again during development. But then again, removing extra blank linkes > is not a bad thing. (jcheck unfortunately does not enforce any style > checks for make files :-( so they tend to detoriate over time.) > >> >> hotspot/src/share/vm/runtime/java.cpp >> L661: void JDK_Version::fully_initialize( >> L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t >> update) { >> L663: // This is only called when current is less than 1.6 and >> we've gotten >> >> Since you're ripping out vestigial version support, I think this >> function can go away since this is version 9 and newer. Don't >> really >> know for sure, but based on that comment... > It probably can, yes. This and other core changes to the actual > .cpp/.java files will be addressed in a follow-up patch. >> >> hotspot/src/share/vm/runtime/java.hpp >> No comments. >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> L1240: please make the 'int' parameter align like the rest. > Are you okay with defering such a change to a follow-up patch? Yes. > It's likely the entire struct will need changes to be able to handle a > theoretically arbitrarily long version number. > >> >> hotspot/src/share/vm/runtime/vm_version.cpp >> L84: void Abstract_VM_Version::initialize() { >> L85: // FIXME: Initialization can probably be removed now. >> I agree, but that would entail also removing the >> _initialized and the uses of it... Follow on bug fix? > Definitely follow on. > >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> L149: * Returns the security version of the running JVM if >> it's 1.6 or newer >> This JavaDoc update is wrong, but it might not be important >> if sun.misc.Version class is going away. > I'm not sure if it's going to be replaced by, or just complemented by > java.util.Version, but in any case it will need a follow-up patch to > clean up this and other issues. >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... > I'll defer that question to Kumar, who wrote that piece of code. My > guess is that when Hotspot express was dropped, the ability to use a > JVM from another JDK release bit rotteded away. > > /Magnus Dan From magnus.ihse.bursie at oracle.com Tue Jun 9 13:36:55 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:36:55 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E983.5020902@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E983.5020902@oracle.com> Message-ID: <5576EBF7.40607@oracle.com> On 2015-06-09 15:26, Claes Redestad wrote: > On 2015-06-09 15:12, Magnus Ihse Bursie wrote: >>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>> >>> old L171: case "1.9": >>> new L171: case "9": >>> Should this logic support both versions? Will dropping >>> "1.9" here prevent a pre-version changeset JVM from >>> being dropped into a JDK for triage purposes? >>> >>> Granted we don't often triage 'javac' with different JVMs, >>> but... >> I'll defer that question to Kumar, who wrote that piece of code. My >> guess is that when Hotspot express was dropped, the ability to use a >> JVM from another JDK release bit rotteded away. >> >> /Magnus > > While we know there's no guarantee that swapping in an older VM will > work, in the face of a regression in a promoted build we still > routinely (automatically, even) swap out the VM with a recent VM to > get a rough estimate of whether the regression was caused by a HotSpot > or JDK/tools change, mostly since this currently saves us time in > narrowing down the changes to bisect over/investigate. So, there's at > least some value in not intentionally breaking build-to-build > backwards compatibility, but we don't expect it to always work and > wouldn't make much fuss about it breaking. If an extra case "1.9" is > all it takes to make it work with last week's VM, however... Actually, I think I messed up a bit there. I believe the real question here was not about mixing different versions of Hotspot and the JDK, but mixing different versions of javac and the JDK. I think. :) /Magnus From magnus.ihse.bursie at oracle.com Tue Jun 9 13:52:20 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Tue, 09 Jun 2015 15:52:20 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E81B.8050703@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> Message-ID: <5576EF94.3010500@oracle.com> Here's an updated webrev, which fixes the typos that were pointed out by reviewers: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ And here's a (much simpler) delta webrev which shows just these changes: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ /Magnus On 2015-06-09 15:20, Daniel D. Daugherty wrote: > On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >> Hi Daniel, >> >> Thank you for your thorough review! > > This was my (failing) attempt at a "fast pass" review... :-) > > >> >> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>> > >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>> >>> >>> General comment: Not all copyright years were updated. >>> General comment: It looks like support for the 'patch' value is not >>> completely >>> implemented through all the Makefiles. I didn't audit for this, >>> but it's >>> just my impression. >> >> You are basically correct. The makefiles all propagate the patch >> value where needed, but the actual source code changes in hotspot and >> jdk ignores the patch field as of now. This will be corrected in a >> later add-on patch, submitted by someone from the jdk and/or hotspot >> team rather than the build team. >> >>> >>> common/autoconf/generated-configure.sh >>> There are multiple Copyright notices in this file. Why? >> Oh dear, you've reviewed the generated file. :-& I'm really impressed >> by your effort! > > Ahhh... now that you say it... it sounds familiar... I may have > made this same mistake before. I'll try to remember next time. > > >> However, the generated-configure.sh file is automatically created by >> the autoconf framework from the rest of the files in >> common/autoconf/*, so we cannot direcly modify it's contents - only >> indirectly. The reason it's checked in, is that otherwise every user >> would need to generate it before being able to run configure. In >> build reviews, we usually either revert changes to >> generated-configure.sh before posting a review to hide it (and >> re-generate it before pushing), or we just ignore it during reviews. >> I should have done that, or pointed out that it was not needed nor >> possible to review when I cross-posted. I'm sorry. >> >>> >>> L4076: # Verify that a given string represent a valid version >>> number, and assing it to >>> L4077: # a variable. >>> Fixed two typos and reformat a bit: >>> # Verify that a given string represents a valid version >>> number, and >>> # assigning it to a variable. >> I'll put that fix in the source .m4 file instead. Thanks. >>> >>> L20262: as_fn_error $? "--with--version-string must have a >>> value" "$LINENO" 5 >>> The '--with--version...' part doesn't match previous usages >>> where >>> '--with-version...' is used >> Yes, you're right. Erik pointed it out as well. It's a typo in the >> error message. It's all over the place due to copied code. I'll fix >> it in the source .m4 file. >> >> (As a side note, I have a half-finished follow-up patch that will >> reduce the amount of code duplication, but it requires some framework >> changes so it'll have to be a separate thing.) >> >>> >>> L20275: # Unspecified numerical fields is interpreted as 0. >>> Grammar: 'is interpreted' -> 'are interpreted' >>> >>> L20286: as_fn_error $? "Version string contains + but >>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>> Grammar: 'is missing' -> 'are missing' >> Those darn English plural forms! Why can't you all do as we sensible >> Swedes and get rid of them? ;-) >> >> (I'll fix) >> >>> >>> L20388: username=`$ECHO "$USER" | $TR -d -c >>> '[a-z][A-Z][0-9]'` >>> This assumes that the "USER" variable is set. Should there >>> be a check for "" and perhaps use "no_user_specified" or >>> something like that? Perhaps the build setup always makes >>> sure that "USER" is set to something. Don't know. >> Hm. I think the worst thing that'll happen is that the username part >> of the opt string gets empty. This part is basically copied right off >> the old build, where we have relied on the $USER variable being >> present for all the time with no problems, so I think it's quite safe >> to assume. >>> >>> common/autoconf/jdk-options.m4 >>> Don't know why the 'elliptic curve crypto implementation' support >>> is relocated as part of this changeset, but ... >> It was incorrectly placed not at the top indentation level, but in >> the middle of the function definition where the old versioning code >> were handled. (Which, mostly by chance, happens to work in autoconf, >> but is really bad style). >> >>> make/Javadoc.gmk >>> Did you mean to remove the 'clean' target? >> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >> that's just some dead code. >> >>> >>> hotspot/make/windows/makefiles/compile.make >>> No changes in the frames view. >>> Update: udiff view shows a blank line deleted at the end of the >>> file. >> >> That's probably the result of some change going forth and then back >> again during development. But then again, removing extra blank linkes >> is not a bad thing. (jcheck unfortunately does not enforce any style >> checks for make files :-( so they tend to detoriate over time.) >> >>> >>> hotspot/src/share/vm/runtime/java.cpp >>> L661: void JDK_Version::fully_initialize( >>> L662: uint8_t major, uint8_t minor, uint8_t security, >>> uint8_t update) { >>> L663: // This is only called when current is less than 1.6 and >>> we've gotten >>> >>> Since you're ripping out vestigial version support, I think >>> this >>> function can go away since this is version 9 and newer. >>> Don't really >>> know for sure, but based on that comment... >> It probably can, yes. This and other core changes to the actual >> .cpp/.java files will be addressed in a follow-up patch. >>> >>> hotspot/src/share/vm/runtime/java.hpp >>> No comments. >>> >>> hotspot/src/share/vm/runtime/vmStructs.cpp >>> L1240: please make the 'int' parameter align like the rest. >> Are you okay with defering such a change to a follow-up patch? > > Yes. > > >> It's likely the entire struct will need changes to be able to handle >> a theoretically arbitrarily long version number. >> >>> >>> hotspot/src/share/vm/runtime/vm_version.cpp >>> L84: void Abstract_VM_Version::initialize() { >>> L85: // FIXME: Initialization can probably be removed now. >>> I agree, but that would entail also removing the >>> _initialized and the uses of it... Follow on bug fix? >> Definitely follow on. >> >>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>> L149: * Returns the security version of the running JVM if >>> it's 1.6 or newer >>> This JavaDoc update is wrong, but it might not be important >>> if sun.misc.Version class is going away. >> I'm not sure if it's going to be replaced by, or just complemented by >> java.util.Version, but in any case it will need a follow-up patch to >> clean up this and other issues. >>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>> >>> old L171: case "1.9": >>> new L171: case "9": >>> Should this logic support both versions? Will dropping >>> "1.9" here prevent a pre-version changeset JVM from >>> being dropped into a JDK for triage purposes? >>> >>> Granted we don't often triage 'javac' with different JVMs, >>> but... >> I'll defer that question to Kumar, who wrote that piece of code. My >> guess is that when Hotspot express was dropped, the ability to use a >> JVM from another JDK release bit rotteded away. >> >> /Magnus > > Dan From kumar.x.srinivasan at oracle.com Tue Jun 9 14:25:45 2015 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Tue, 09 Jun 2015 07:25:45 -0700 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55767256.3030802@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <55767256.3030802@oracle.com> Message-ID: <5576F769.3060002@oracle.com> On 6/8/2015 9:57 PM, Jan Lahoda wrote: > On 9.6.2015 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... >> > > +1 on keeping both "1.9" and "9" here. javac can be used independently > on the rest of JDK to some extent, so support for running it on older > builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 > javac should be prepared for the new version scheme in advance.) Yes, I think for the most part langtools seems to be working in the sandbox repo, with these changes, the remaining work is to align the version and fullversion of langtools/test to be compliant to the JDK version. Kumar > > Jan From naoto.sato at oracle.com Tue Jun 9 16:56:59 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 09 Jun 2015 09:56:59 -0700 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <55769CED.7000400@oracle.com> References: <557601F7.5060209@oracle.com> <55769CED.7000400@oracle.com> Message-ID: <55771ADB.6040502@oracle.com> Thank you for the quick review, Erik! Naoto On 6/9/15 12:59 AM, Erik Joelsson wrote: > Hello Naoto, > > Build changes look good to me. > > /Erik > > On 2015-06-08 22:58, Naoto Sato wrote: >> Hello, >> >> Please review the proposed changes for 8008577[1], the implementation >> of the JEP-252[2]. The proposed changes are located at: >> >> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >> >> Here are the very high level summary of changes: >> >> - Now the default locale provider order is CLDR,JRE,SPI. >> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >> - According the CLDR upgrade, the converter tool and the runtime are >> now capable of "alias" and "parentLocales" tags. >> - Regression tests that are specific to the existing JRE locale data >> are now run specifically with "JRE,SPI" providers. >> >> I would like the build group to review the build changes mainly with >> the CLDR changes, and i18n group for the rest. >> >> Naoto >> -- >> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 > From mikhail.cherkasov at oracle.com Tue Jun 9 20:20:02 2015 From: mikhail.cherkasov at oracle.com (mikhail cherkasov) Date: Tue, 09 Jun 2015 23:20:02 +0300 Subject: Building openjdk 8 on Mac OS X In-Reply-To: References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> <5F78A0ED-DCE6-410D-9471-0732784DCD56@oracle.com> Message-ID: <55774A72.4070708@oracle.com> Hi Denis, I applied you instruction, but I still have an error during configuration: configure:21029: /usr/bin/gcc --version >&5 i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. couldn't understand kern.osversion `14.1.0' .... configure:21131: error: C compiler cannot create executables I also attached config.log. Do you still can build jdk on macosx 10.10 ? Can you advise how to fix build in my environment? Thanks, Mikhail. On 11/26/2014 4:30 PM, Denis Fokin wrote: > Hi guys, > > good news. I am able to build open jdk8 on Yosemite (thanks to Anton Tarasov for his script to build on 10.9) > > Steps: > > 1. Download and save in some secure place Xcode4.6 > 2. Make a link form Xcode.4 lipo to /usr/bin/lipo > 3. Set MACOSX_DEPLOYMENT_TARGET enviroment variable to 10.8 > 4. Execute configure like this > > sh configure --with-freetype=/Volumes/HD-PATU3/tools/freetype-2.4.0/ --with-extra-cflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-extra-cxxflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/ > > Thank you, > Denis. > > > >> On 12 Nov 2014, at 20:29, David DeHaven wrote: >> >> >> Not 8, 9... >> >> -DrD- >> >>> Hi Wang >>> >>> You were able to compile openjdk8 on Yosemite!! Can you please look into the error faced by me (first post in the thread; posted below as well) and figure out the problem(s)? >>> >>> Regards, >>> Manas >>> >>> >>> >>>> Yes, I can compile the whole mess on Yosemite/Xcode 6.1. There was an issue with FreeType when building OpenJDK, but it looks like that's been resolved now. >>>> >>>> -DrD- >>>> >>> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp >>> Making signal interposition lib... >>> couldn't understand kern.osversion `14.0.0' >>> warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file >>> warning: no debug symbols in executable (-arch x86_64) >>> Making SA debugger back-end... >>> couldn't understand kern.osversion `14.0.0' >>> In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, >>> from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, >>> from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, >>> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >>> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? >>> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? >>> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, >>> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >>> /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? >>> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp >>> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, >>> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >>> /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? >>> make[8]: *** [libsaproc.dylib] Error 1 >>> make[8]: *** Waiting for unfinished jobs.... >>> make[7]: *** [the_vm] Error 2 >>> make[6]: *** [product] Error 2 >>> make[5]: *** [generic_build2] Error 2 >>> make[4]: *** [product] Error 2 >>> make[3]: *** [all_product_universal] Error 2 >>> make[2]: *** [universal_product] Error 2 >>> make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 >>> make: *** [hotspot-only] Error 2 >>> -------------- next part -------------- This file contains any messages produced by compilers while running configure, to aid debugging if configure makes a mistake. It was created by OpenJDK configure jdk8, which was generated by GNU Autoconf 2.69. Invocation command line was $ ./common/autoconf/configure --enable-option-checking=fatal --with-extra-cflags=-isysroot /Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks --with-extra-cxxflags=-isysroot /Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks --with-boot-jdk=/Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home ## --------- ## ## Platform. ## ## --------- ## hostname = dhcp-stpetersburg-2fl-10-162-81-100.ru.oracle.com uname -m = x86_64 uname -r = 14.1.0 uname -s = Darwin uname -v = Darwin Kernel Version 14.1.0: Mon Dec 22 23:10:38 PST 2014; root:xnu-2782.10.72~2/RELEASE_X86_64 /usr/bin/uname -p = i386 /bin/uname -X = unknown /bin/arch = unknown /usr/bin/arch -k = unknown /usr/convex/getsysinfo = unknown /usr/bin/hostinfo = Mach kernel version: Darwin Kernel Version 14.1.0: Mon Dec 22 23:10:38 PST 2014; root:xnu-2782.10.72~2/RELEASE_X86_64 Kernel configured for up to 4 processors. 2 processors are physically available. 4 processors are logically available. Processor type: x86_64h (Intel x86-64h Haswell) Processors active: 0 1 2 3 Primary memory available: 16.00 gigabytes Default processor set: 243 tasks, 1020 threads, 4 processors Load average: 2.85, Mach factor: 1.54 /bin/machine = unknown /usr/bin/oslevel = unknown /bin/universe = unknown PATH: /Users/mcherkas/bin PATH: /usr/local/bin PATH: /usr/bin PATH: /bin PATH: /usr/sbin PATH: /sbin ## ----------- ## ## Core tests. ## ## ----------- ## configure:4174: Configuration created at Tue Jun 9 23:21:56 MSK 2015. configure:4176: configure script generated at timestamp 1433258489. configure:4193: checking for basename configure:4211: found /usr/bin/basename configure:4223: result: /usr/bin/basename configure:4252: checking for bash configure:4282: result: /bin/bash configure:4311: checking for cat configure:4329: found /bin/cat configure:4341: result: /bin/cat configure:4370: checking for chmod configure:4388: found /bin/chmod configure:4400: result: /bin/chmod configure:4429: checking for cmp configure:4447: found /usr/bin/cmp configure:4459: result: /usr/bin/cmp configure:4488: checking for comm configure:4506: found /usr/bin/comm configure:4518: result: /usr/bin/comm configure:4547: checking for cp configure:4565: found /bin/cp configure:4577: result: /bin/cp configure:4606: checking for cpio configure:4624: found /usr/bin/cpio configure:4636: result: /usr/bin/cpio configure:4665: checking for cut configure:4683: found /usr/bin/cut configure:4695: result: /usr/bin/cut configure:4724: checking for date configure:4742: found /bin/date configure:4754: result: /bin/date configure:4783: checking for gdiff configure:4816: result: no configure:4783: checking for diff configure:4801: found /usr/bin/diff configure:4813: result: /usr/bin/diff configure:4842: checking for dirname configure:4860: found /usr/bin/dirname configure:4872: result: /usr/bin/dirname configure:4901: checking for echo configure:4919: found /bin/echo configure:4931: result: /bin/echo configure:4960: checking for expr configure:4978: found /bin/expr configure:4990: result: /bin/expr configure:5019: checking for file configure:5037: found /usr/bin/file configure:5049: result: /usr/bin/file configure:5078: checking for find configure:5096: found /usr/bin/find configure:5108: result: /usr/bin/find configure:5137: checking for head configure:5155: found /usr/bin/head configure:5167: result: /usr/bin/head configure:5196: checking for ln configure:5214: found /bin/ln configure:5226: result: /bin/ln configure:5255: checking for ls configure:5273: found /bin/ls configure:5285: result: /bin/ls configure:5314: checking for mkdir configure:5332: found /bin/mkdir configure:5344: result: /bin/mkdir configure:5373: checking for mktemp configure:5391: found /usr/bin/mktemp configure:5403: result: /usr/bin/mktemp configure:5432: checking for mv configure:5450: found /bin/mv configure:5462: result: /bin/mv configure:5491: checking for printf configure:5509: found /usr/bin/printf configure:5521: result: /usr/bin/printf configure:5550: checking for rm configure:5568: found /bin/rm configure:5580: result: /bin/rm configure:5609: checking for sh configure:5627: found /bin/sh configure:5639: result: /bin/sh configure:5668: checking for sort configure:5686: found /usr/bin/sort configure:5698: result: /usr/bin/sort configure:5727: checking for tail configure:5745: found /usr/bin/tail configure:5757: result: /usr/bin/tail configure:5786: checking for tar configure:5804: found /usr/bin/tar configure:5816: result: /usr/bin/tar configure:5845: checking for tee configure:5863: found /usr/bin/tee configure:5875: result: /usr/bin/tee configure:5904: checking for touch configure:5922: found /usr/bin/touch configure:5934: result: /usr/bin/touch configure:5963: checking for tr configure:5981: found /usr/bin/tr configure:5993: result: /usr/bin/tr configure:6022: checking for uname configure:6040: found /usr/bin/uname configure:6052: result: /usr/bin/uname configure:6081: checking for uniq configure:6099: found /usr/bin/uniq configure:6111: result: /usr/bin/uniq configure:6140: checking for wc configure:6158: found /usr/bin/wc configure:6170: result: /usr/bin/wc configure:6199: checking for which configure:6217: found /usr/bin/which configure:6229: result: /usr/bin/which configure:6258: checking for xargs configure:6276: found /usr/bin/xargs configure:6288: result: /usr/bin/xargs configure:6318: checking for gawk configure:6348: result: no configure:6318: checking for mawk configure:6348: result: no configure:6318: checking for nawk configure:6348: result: no configure:6318: checking for awk configure:6334: found /usr/bin/awk configure:6345: result: awk configure:6368: checking for grep that handles long lines and -e configure:6426: result: /usr/bin/grep configure:6443: checking for egrep configure:6505: result: /usr/bin/grep -E configure:6522: checking for fgrep configure:6584: result: /usr/bin/grep -F configure:6601: checking for a sed that does not truncate output configure:6665: result: /usr/bin/sed configure:6687: checking for nawk configure:6720: result: no configure:6687: checking for gawk configure:6720: result: no configure:6687: checking for awk configure:6705: found /usr/bin/awk configure:6717: result: /usr/bin/awk configure:6751: checking for cygpath configure:6784: result: no configure:6791: checking for readlink configure:6809: found /usr/bin/readlink configure:6821: result: /usr/bin/readlink configure:6831: checking for df configure:6849: found /bin/df configure:6861: result: /bin/df configure:6871: checking for SetFile configure:6889: found /usr/bin/SetFile configure:6901: result: /usr/bin/SetFile configure:6917: checking build system type configure:6931: result: x86_64-apple-darwin14.1.0 configure:6951: checking host system type configure:6964: result: x86_64-apple-darwin14.1.0 configure:6984: checking target system type configure:6997: result: x86_64-apple-darwin14.1.0 configure:7175: checking openjdk-build os-cpu configure:7177: result: macosx-x86_64 configure:7312: checking openjdk-target os-cpu configure:7314: result: macosx-x86_64 configure:7364: checking compilation type configure:7366: result: native configure:8075: checking for presence of closed sources configure:8082: result: yes configure:8085: checking if closed source is suppressed (openjdk-only) configure:8088: result: no configure:8125: checking which variant of the JDK to build configure:8156: result: normal configure:8166: checking which interpreter of the JVM to build configure:8187: result: template configure:8204: checking which variants of the JVM to build configure:8223: result: server configure:8298: checking which debug level to use configure:8322: result: release configure:8735: checking what configuration name to use configure:8737: result: macosx-x86_64-normal-server-release configure:8904: checking for apt-get configure:8934: result: no configure:8904: checking for yum configure:8934: result: no configure:8904: checking for port configure:8934: result: no configure:8904: checking for pkgutil configure:8920: found /usr/sbin/pkgutil configure:8931: result: pkgutil configure:9269: checking for gmake configure:9302: result: no configure:9623: checking for make configure:9641: found /usr/bin/make configure:9653: result: /usr/bin/make configure:9668: Testing potential make at /usr/bin/make, found using make in PATH configure:9936: Resolving FOUND_MAKE (as /usr/bin/make) failed, using /usr/bin/make directly. configure:10695: Using GNU make 3.81 (or later) at /usr/bin/make (version: GNU Make 3.81) configure:10701: checking if find supports -delete configure:10717: result: yes configure:10731: checking for unzip configure:10749: found /usr/bin/unzip configure:10761: result: /usr/bin/unzip configure:10790: checking for zip configure:10808: found /usr/bin/zip configure:10820: result: /usr/bin/zip configure:10849: checking for ldd configure:10882: result: no configure:10897: checking for readelf configure:10930: result: no configure:10897: checking for greadelf configure:10930: result: no configure:10940: checking for hg configure:10958: found /usr/local/bin/hg configure:10970: result: /usr/local/bin/hg configure:10980: checking for stat configure:10998: found /usr/bin/stat configure:11010: result: /usr/bin/stat configure:11020: checking for time configure:11038: found /usr/bin/time configure:11050: result: /usr/bin/time configure:11135: checking for dsymutil configure:11153: found /usr/bin/dsymutil configure:11165: result: /usr/bin/dsymutil configure:11194: checking for xattr configure:11212: found /usr/bin/xattr configure:11224: result: /usr/bin/xattr configure:11250: checking for codesign configure:11268: found /usr/bin/codesign configure:11280: result: /usr/bin/codesign configure:11290: checking if openjdk_codesign certificate is present openjdk_codesign: no identity found configure:11297: result: no configure:11357: checking for pkg-config configure:11390: result: no configure:11530: checking for 7z configure:11560: result: no configure:11530: checking for unzip configure:11546: found /usr/bin/unzip configure:11557: result: unzip configure:11576: checking for wget configure:11606: result: no configure:11576: checking for lftp configure:11606: result: no configure:11576: checking for ftp configure:11592: found /usr/bin/ftp configure:11603: result: ftp configure:11630: checking headful support configure:11654: result: include support for both headful and headless configure:11873: Found potential Boot JDK using configure arguments configure:12036: checking for Boot JDK configure:12038: result: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home configure:12040: checking Boot JDK version configure:12043: result: java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) configure:16506: checking for java in Boot JDK configure:16516: result: ok configure:16520: checking for javac in Boot JDK configure:16530: result: ok configure:16534: checking for javah in Boot JDK configure:16544: result: ok configure:16548: checking for javap in Boot JDK configure:16558: result: ok configure:16562: checking for jar in Boot JDK configure:16572: result: ok configure:16576: checking for rmic in Boot JDK configure:16586: result: ok configure:16590: checking for native2ascii in Boot JDK configure:16600: result: ok configure:16623: checking flags for boot jdk java command Check if jvm arg is ok: -XX:-PrintVMOptions -XX:-UnlockDiagnosticVMOptions -XX:-LogVMOutput Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -XX:-PrintVMOptions -XX:-UnlockDiagnosticVMOptions -XX:-LogVMOutput -version Arg failed: Error: VM option 'LogVMOutput' is diagnostic and must be enabled via -XX:+UnlockDiagnosticVMOptions. Error: Could not create the Java Virtual Machine. Error: A fatal exception has occurred. Program will exit. Check if jvm arg is ok: Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -version configure:16660: result: configure:16668: checking flags for boot jdk java command for big workloads Check if jvm arg is ok: -Xms64M Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -Xms64M -version Check if jvm arg is ok: -Xmx1600M Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -Xmx1600M -version Check if jvm arg is ok: -XX:ThreadStackSize=1536 Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -XX:ThreadStackSize=1536 -version Check if jvm arg is ok: -XX:PermSize=32m Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -XX:PermSize=32m -version Arg failed: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option PermSize=32m; support was removed in 8.0 java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) Check if jvm arg is ok: -XX:MaxPermSize=160m Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -XX:MaxPermSize=160m -version Arg failed: Java HotSpot(TM) 64-Bit Server VM warning: ignoring option MaxPermSize=160m; support was removed in 8.0 java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) configure:16762: result: -Xms64M -Xmx1600M -XX:ThreadStackSize=1536 configure:16769: checking flags for boot jdk java command for small workloads Check if jvm arg is ok: -XX:+UseSerialGC Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -XX:+UseSerialGC -version Check if jvm arg is ok: -Xms32M Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -Xms32M -version Check if jvm arg is ok: -Xmx512M Command: /Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/bin/java -Xmx512M -version configure:16819: result: -XX:+UseSerialGC -Xms32M -Xmx512M configure:17187: checking for jtreg configure:17189: result: no configure:19793: checking Determining if we need to set DEVELOPER_DIR configure:19808: result: no configure:19815: checking for xcodebuild configure:19833: found /usr/bin/xcodebuild configure:19845: result: /usr/bin/xcodebuild configure:19876: checking Determining Xcode SDK path configure:19881: result: /Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk configure:19993: checking for gcc configure:20011: found /usr/bin/gcc configure:20023: result: /usr/bin/gcc configure:20306: Resolving CC (as /usr/bin/gcc) failed, using /usr/bin/gcc directly. configure:20340: checking resolved symbolic links for CC configure:20390: result: /usr/bin/gcc configure:20393: checking if CC is disguised ccache configure:20832: result: no, keeping CC configure:20903: Using C compiler version (located at /usr/bin/gcc) configure:21020: checking for C compiler version configure:21029: /usr/bin/gcc --version >&5 i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. couldn't understand kern.osversion `14.1.0' configure:21040: $? = 0 configure:21029: /usr/bin/gcc -v >&5 couldn't understand kern.osversion `14.1.0' Using built-in specs. Target: i686-apple-darwin11 Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1 Thread model: posix gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) configure:21040: $? = 0 configure:21029: /usr/bin/gcc -V >&5 llvm-gcc-4.2: argument to `-V' is missing configure:21040: $? = 1 configure:21029: /usr/bin/gcc -qversion >&5 couldn't understand kern.osversion `14.1.0' i686-apple-darwin11-llvm-gcc-4.2: no input files configure:21040: $? = 1 configure:21060: checking whether the C compiler works configure:21082: /usr/bin/gcc conftest.c >&5 couldn't understand kern.osversion `14.1.0' ld: library not found for -lcrt1.o collect2: ld returned 1 exit status configure:21086: $? = 1 configure:21124: result: no configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "OpenJDK" | #define PACKAGE_TARNAME "openjdk" | #define PACKAGE_VERSION "jdk8" | #define PACKAGE_STRING "OpenJDK jdk8" | #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" | #define PACKAGE_URL "http://openjdk.java.net" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:21129: error: in `/Users/mcherkas/ws/jdk8/jdk8u-dev': configure:21131: error: C compiler cannot create executables See `config.log' for more details ## ---------------- ## ## Cache variables. ## ## ---------------- ## ac_cv_build=x86_64-apple-darwin14.1.0 ac_cv_env_ALSA_CFLAGS_set= ac_cv_env_ALSA_CFLAGS_value= ac_cv_env_ALSA_LIBS_set= ac_cv_env_ALSA_LIBS_value= ac_cv_env_CCC_set= ac_cv_env_CCC_value= ac_cv_env_CC_set= ac_cv_env_CC_value= ac_cv_env_CFLAGS_set= ac_cv_env_CFLAGS_value= ac_cv_env_CPPFLAGS_set= ac_cv_env_CPPFLAGS_value= ac_cv_env_CPP_set= ac_cv_env_CPP_value= ac_cv_env_CXXCPP_set= ac_cv_env_CXXCPP_value= ac_cv_env_CXXFLAGS_set= ac_cv_env_CXXFLAGS_value= ac_cv_env_CXX_set= ac_cv_env_CXX_value= ac_cv_env_FREETYPE_CFLAGS_set= ac_cv_env_FREETYPE_CFLAGS_value= ac_cv_env_FREETYPE_LIBS_set= ac_cv_env_FREETYPE_LIBS_value= ac_cv_env_LDFLAGS_set= ac_cv_env_LDFLAGS_value= ac_cv_env_LIBFFI_CFLAGS_set= ac_cv_env_LIBFFI_CFLAGS_value= ac_cv_env_LIBFFI_LIBS_set= ac_cv_env_LIBFFI_LIBS_value= ac_cv_env_LIBS_set= ac_cv_env_LIBS_value= ac_cv_env_OBJCFLAGS_set= ac_cv_env_OBJCFLAGS_value= ac_cv_env_OBJC_set= ac_cv_env_OBJC_value= ac_cv_env_PKG_CONFIG_set= ac_cv_env_PKG_CONFIG_value= ac_cv_env_XMKMF_set= ac_cv_env_XMKMF_value= ac_cv_env_build_alias_set= ac_cv_env_build_alias_value= ac_cv_env_host_alias_set= ac_cv_env_host_alias_value= ac_cv_env_target_alias_set= ac_cv_env_target_alias_value= ac_cv_host=x86_64-apple-darwin14.1.0 ac_cv_path_BASENAME=/usr/bin/basename ac_cv_path_BASH=/bin/bash ac_cv_path_CAT=/bin/cat ac_cv_path_CHECK_MAKE=/usr/bin/make ac_cv_path_CHMOD=/bin/chmod ac_cv_path_CMP=/usr/bin/cmp ac_cv_path_CODESIGN=/usr/bin/codesign ac_cv_path_COMM=/usr/bin/comm ac_cv_path_CP=/bin/cp ac_cv_path_CPIO=/usr/bin/cpio ac_cv_path_CUT=/usr/bin/cut ac_cv_path_DATE=/bin/date ac_cv_path_DF=/bin/df ac_cv_path_DIFF=/usr/bin/diff ac_cv_path_DIRNAME=/usr/bin/dirname ac_cv_path_DSYMUTIL=/usr/bin/dsymutil ac_cv_path_ECHO=/bin/echo ac_cv_path_EGREP='/usr/bin/grep -E' ac_cv_path_EXPR=/bin/expr ac_cv_path_FGREP='/usr/bin/grep -F' ac_cv_path_FILE=/usr/bin/file ac_cv_path_FIND=/usr/bin/find ac_cv_path_GREP=/usr/bin/grep ac_cv_path_HEAD=/usr/bin/head ac_cv_path_HG=/usr/local/bin/hg ac_cv_path_LN=/bin/ln ac_cv_path_LS=/bin/ls ac_cv_path_MKDIR=/bin/mkdir ac_cv_path_MKTEMP=/usr/bin/mktemp ac_cv_path_MV=/bin/mv ac_cv_path_NAWK=/usr/bin/awk ac_cv_path_POTENTIAL_CC=/usr/bin/gcc ac_cv_path_PRINTF=/usr/bin/printf ac_cv_path_READLINK=/usr/bin/readlink ac_cv_path_RM=/bin/rm ac_cv_path_SED=/usr/bin/sed ac_cv_path_SETFILE=/usr/bin/SetFile ac_cv_path_SH=/bin/sh ac_cv_path_SORT=/usr/bin/sort ac_cv_path_STAT=/usr/bin/stat ac_cv_path_TAIL=/usr/bin/tail ac_cv_path_TAR=/usr/bin/tar ac_cv_path_TEE=/usr/bin/tee ac_cv_path_TIME=/usr/bin/time ac_cv_path_TOUCH=/usr/bin/touch ac_cv_path_TR=/usr/bin/tr ac_cv_path_UNAME=/usr/bin/uname ac_cv_path_UNIQ=/usr/bin/uniq ac_cv_path_UNZIP=/usr/bin/unzip ac_cv_path_WC=/usr/bin/wc ac_cv_path_WHICH=/usr/bin/which ac_cv_path_XARGS=/usr/bin/xargs ac_cv_path_XATTR=/usr/bin/xattr ac_cv_path_XCODEBUILD=/usr/bin/xcodebuild ac_cv_path_ZIP=/usr/bin/zip ac_cv_prog_AWK=awk ac_cv_prog_BDEPS_FTP=ftp ac_cv_prog_BDEPS_UNZIP=unzip ac_cv_prog_PKGHANDLER=pkgutil ac_cv_target=x86_64-apple-darwin14.1.0 ## ----------------- ## ## Output variables. ## ## ----------------- ## ADD_SRC_ROOT='' ALSA_CFLAGS='' ALSA_LIBS='' ANT='' ANT_EXE='' ANT_HOME='' AR='' ARFLAGS='' AR_OUT_OPTION='rcs$(SPACE)' AS='' AWK='awk' BASENAME='/usr/bin/basename' BASH='/bin/bash' BDEPS_FTP='ftp' BDEPS_UNZIP='unzip' BOOT_JDK='/Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home' BOOT_JDK_SOURCETARGET='-source 7 -target 7' BOOT_RTJAR='/Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/jre/lib/rt.jar' BOOT_TOOLSJAR='/Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home/lib/tools.jar' BSDIFF_DIR='' BUILD_CC='' BUILD_CRYPTO='' BUILD_CXX='' BUILD_DEPLOY='' BUILD_HEADLESS='BUILD_HEADLESS:=true' BUILD_HEADLESS_ONLY='' BUILD_HOTSPOT='true' BUILD_INSTALL='' BUILD_LD='' BUILD_LOG='$(OUTPUT_ROOT)/build.log' BUILD_LOG_PREVIOUS='$(OUTPUT_ROOT)/build.log.old' BUILD_LOG_WRAPPER='$(BASH) $(SRC_ROOT)/common/bin/logger.sh $(BUILD_LOG)' BUILD_OUTPUT='/Users/mcherkas/ws/jdk8/jdk8u-dev/build/macosx-x86_64-normal-server-release' BUILD_VARIANT_RELEASE='' BUNDLE_DATE='' CACERTS_FILE='/Users/mcherkas/ws/jdk8/jdk8u-dev/jdk/src/share/lib/security/cacerts' CAT='/bin/cat' CC='/usr/bin/gcc' CCACHE='' CCSS_SIGNING_CREDFILE='' CCSS_SIGNING_DIR='' CCSS_SIGNING_GLOBAL_UID='' CCSS_SIGNING_SCRIPT='' CCSS_SIGNING_USER='' CCSS_SIGNING_VERSION='' CC_OUT_OPTION='-o$(SPACE)' CFLAGS='' CFLAGS_DEBUG_SYMBOLS='' CFLAGS_JDKEXE='' CFLAGS_JDKLIB='' CHECK_GMAKE='' CHECK_MAKE='/usr/bin/make' CHECK_TOOLSDIR_GMAKE='' CHECK_TOOLSDIR_MAKE='' CHMOD='/bin/chmod' CMP='/usr/bin/cmp' CODESIGN='' COMM='/usr/bin/comm' COMPANY_NAME='N/A' COMPILER_NAME='C' COMPILER_PATH='' COMPILER_SUPPORTS_TARGET_BITS_FLAG='' COMPILER_TARGET_BITS_FLAG='' COMPILER_TYPE='' COMPILE_TYPE='native' COMPRESS_JARS='false' CONFIGURE_COMMAND_LINE='--with-extra-cflags=-isysroot /Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks --with-extra-cxxflags=-isysroot /Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks --with-boot-jdk=/Users/mcherkas/ws/jdk8/jdk1.8.0_45.jdk/Contents/Home' CONF_NAME='macosx-x86_64-normal-server-release' COOKED_BUILD_NUMBER='0' COOKED_JDK_UPDATE_VERSION='0' COPYRIGHT_YEAR='2015' CORBA_TOPDIR='/Users/mcherkas/ws/jdk8/jdk8u-dev/corba' CP='/bin/cp' CPIO='/usr/bin/cpio' CPP='' CPPFLAGS='' CSCRIPT='' CUPS_CFLAGS='' CUSTOM_MAKE_DIR='' CUT='/usr/bin/cut' CXX='' CXXCPP='' CXXFLAGS='' CXXFLAGS_DEBUG_SYMBOLS='' CXXFLAGS_JDKEXE='' CXXFLAGS_JDKLIB='' CXX_FLAG_DEPS='' CXX_FLAG_REORDER='' CXX_O_FLAG_HI='' CXX_O_FLAG_HIGHEST='' CXX_O_FLAG_NONE='' CXX_O_FLAG_NORM='' CYGPATH='' CYGWIN_LINK='' C_FLAG_DEPS='' C_FLAG_REORDER='' C_O_FLAG_HI='' C_O_FLAG_HIGHEST='' C_O_FLAG_NONE='' C_O_FLAG_NORM='' DATE='/bin/date' DATE_WHEN_CONFIGURED='Tue Jun 9 23:21:56 MSK 2015' DEBUG_CLASSFILES='false' DEBUG_LEVEL='release' DEFINE_CROSS_COMPILE_ARCH='' DEFS='' DEPLOY_SPEC='' DEPLOY_TOPDIR='' DEVTOOLS_PATH='' DF='/bin/df' DIFF='/usr/bin/diff' DIRNAME='/usr/bin/dirname' DISABLE_COMMERCIAL_FEATURES='' DSYMUTIL='/usr/bin/dsymutil' DUMPBIN='' ECHO='/bin/echo' ECHO_C='' ECHO_N='-n' ECHO_T='' EGREP='/usr/bin/grep -E' ENABLE_DEBUG_SYMBOLS='' ENABLE_INTREE_EC='' ENABLE_JFR='' ENABLE_SJAVAC='' EXEEXT='' EXE_OUT_OPTION='-o$(SPACE)' EXE_SUFFIX='' EXPR='/bin/expr' EXT_LIBS_PATH='' FASTDEBUG='false' FGREP='/usr/bin/grep -F' FILE='/usr/bin/file' FIND='/usr/bin/find' FIND_DELETE='-delete' FIXPATH='' FREETYPE_BUNDLE_LIB_PATH='' FREETYPE_CFLAGS='' FREETYPE_LIBS='' GENERATE_JDKBYTECODE_EXTRA_FLAGS='' GLOBAL_LDFLAGS_SUFFIX='' GNM='' GREP='/usr/bin/grep' HEAD='/usr/bin/head' HG='/usr/local/bin/hg' HOTSPOT_CXX='' HOTSPOT_DIST='/Users/mcherkas/ws/jdk8/jdk8u-dev/build/macosx-x86_64-normal-server-release/hotspot/dist' HOTSPOT_LD='' HOTSPOT_MAKE_ARGS='' HOTSPOT_MT='' HOTSPOT_RC='' HOTSPOT_TOPDIR='/Users/mcherkas/ws/jdk8/jdk8u-dev/hotspot' INCLUDE_SA='true' INSTALL_SPEC='' INSTALL_TOPDIR='' IS_GNU_TIME='no' JAVAC_CHECK='' JAVAC_FLAGS='' JAVAFX_ZIP_DIR='' JAVASE_EMBEDDED='' JAVA_CHECK='' JAVA_FLAGS=' ' JAVA_FLAGS_BIG=' -Xms64M -Xmx1600M -XX:ThreadStackSize=1536' JAVA_FLAGS_SMALL=' -XX:+UseSerialGC -Xms32M -Xmx512M' JAXP_TOPDIR='/Users/mcherkas/ws/jdk8/jdk8u-dev/jaxp' JAXWS_TOPDIR='/Users/mcherkas/ws/jdk8/jdk8u-dev/jaxws' JDK_BUILD_NUMBER='b00' JDK_DEBUG_IMAGE_DIR='' JDK_MAJOR_VERSION='1' JDK_MICRO_VERSION='0' JDK_MINOR_VERSION='8' JDK_MKTG_UNDERSCORE_VERSION='' JDK_MKTG_VERSION='' JDK_RC_PLATFORM_NAME='Platform' JDK_TOPDIR='/Users/mcherkas/ws/jdk8/jdk8u-dev/jdk' JDK_UNDERSCORE_VERSION='' JDK_UPDATE_VERSION='' JDK_VARIANT='normal' JDK_VERSION='1.8.0' JMC_ZIP_DIR='' JOBS='' JTREGEXE='' JT_HOME='' JUNIT_DIR='' JVM_INTERPRETER='template' JVM_VARIANTS=',server,' JVM_VARIANT_CLIENT='false' JVM_VARIANT_CORE='false' JVM_VARIANT_KERNEL='false' JVM_VARIANT_MINIMAL1='false' JVM_VARIANT_SERVER='true' JVM_VARIANT_ZERO='false' JVM_VARIANT_ZEROSHARK='false' LANGTOOLS_TOPDIR='/Users/mcherkas/ws/jdk8/jdk8u-dev/langtools' LAUNCHER_NAME='openjdk' LD='' LDCXX='' LDD='true' LDEXE='' LDEXECXX='' LDFLAGS='' LDFLAGS_CXX_JDK='' LDFLAGS_JDKEXE='' LDFLAGS_JDKEXE_SUFFIX='' LDFLAGS_JDKLIB='' LDFLAGS_JDKLIB_SUFFIX='' LD_OUT_OPTION='-o$(SPACE)' LEGACY_EXTRA_CFLAGS='' LEGACY_EXTRA_CXXFLAGS='' LEGACY_EXTRA_LDFLAGS='' LIBCXX='' LIBDL='' LIBFFI_CFLAGS='' LIBFFI_LIBS='' LIBM='' LIBOBJS='' LIBRARY_PREFIX='' LIBS='' LIBZIP_CAN_USE_MMAP='' LLVM_CFLAGS='' LLVM_CONFIG='' LLVM_LDFLAGS='' LLVM_LIBS='' LN='/bin/ln' LP64='LP64:=' LS='/bin/ls' LTLIBOBJS='' LZMA_EXE='' MACOSX_BUNDLE_ID_BASE='net.java.openjdk' MACOSX_BUNDLE_NAME_BASE='OpenJDK' MACOSX_UNIVERSAL='false' MACOSX_VERSION_MIN='' MAKE='/usr/bin/make' MCS='' MEMORY_SIZE='' MIDL='' MILESTONE='internal' MINIMIZE_RAM_USAGE='' MKDIR='/bin/mkdir' MKTEMP='/usr/bin/mktemp' MOZILLA_HEADERS='' MSICERT='' MSITRAN='' MSVCR_DLL='' MT='' MV='/bin/mv' NASHORN_TOPDIR='/Users/mcherkas/ws/jdk8/jdk8u-dev/nashorn' NAWK='/usr/bin/awk' NM='' NUM_CORES='' OBJC='' OBJCFLAGS='' OBJCOPY='' OBJDUMP='' OBJEXT='' OBJ_SUFFIX='' OPENJDK_BUILD_AUTOCONF_NAME='x86_64-apple-darwin14.1.0' OPENJDK_BUILD_CPU='x86_64' OPENJDK_BUILD_CPU_ARCH='x86' OPENJDK_BUILD_CPU_BITS='64' OPENJDK_BUILD_CPU_ENDIAN='little' OPENJDK_BUILD_OS='macosx' OPENJDK_BUILD_OS_API='posix' OPENJDK_TARGET_AUTOCONF_NAME='x86_64-apple-darwin14.1.0' OPENJDK_TARGET_CPU='x86_64' OPENJDK_TARGET_CPU_ARCH='x86' OPENJDK_TARGET_CPU_BITS='64' OPENJDK_TARGET_CPU_ENDIAN='little' OPENJDK_TARGET_CPU_ISADIR='' OPENJDK_TARGET_CPU_JLI_CFLAGS='-DLIBARCHNAME='\''"x86_64"'\''' OPENJDK_TARGET_CPU_LEGACY='x86_64' OPENJDK_TARGET_CPU_LEGACY_LIB='amd64' OPENJDK_TARGET_CPU_LIBDIR='' OPENJDK_TARGET_CPU_OSARCH='x86_64' OPENJDK_TARGET_OS='macosx' OPENJDK_TARGET_OS_API='posix' OPENJDK_TARGET_OS_API_DIR='solaris' OPENJDK_TARGET_OS_EXPORT_DIR='macosx' OPENWIN_HOME='' OS_VERSION_MAJOR='14' OS_VERSION_MICRO='0' OS_VERSION_MINOR='1' OTOOL='' OUTPUT_ROOT='/Users/mcherkas/ws/jdk8/jdk8u-dev/build/macosx-x86_64-normal-server-release' OVERRIDE_SRC_ROOT='' PACKAGE_BUGREPORT='build-dev at openjdk.java.net' PACKAGE_NAME='OpenJDK' PACKAGE_PATH='' PACKAGE_STRING='OpenJDK jdk8' PACKAGE_TARNAME='openjdk' PACKAGE_URL='http://openjdk.java.net' PACKAGE_VERSION='jdk8' PATH_SEP=':' PATH_SEPARATOR=':' PKGHANDLER='pkgutil' PKG_CONFIG='' PLUGIN_CC='' POST_MCS_CMD='' POST_STRIP_CMD='' POTENTIAL_CC='/usr/bin/gcc' POTENTIAL_CXX='' PRINTF='/usr/bin/printf' PRODUCT_NAME='OpenJDK' PRODUCT_SUFFIX='Runtime Environment' PROPER_COMPILER_CC='' PROPER_COMPILER_CXX='' RC='' RC_FLAGS='' READELF='' READLINK='' REBASE='' REQUIRED_OS_NAME='Darwin' REQUIRED_OS_VERSION='11.2' RM='/bin/rm -f' SALIB_NAME='' SDKPATH='/Applications/Xcode 2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk' SED='/usr/bin/sed' SETFILE='/usr/bin/SetFile' SET_DEVELOPER_DIR='' SET_EXECUTABLE_ORIGIN='' SET_OPENJDK='' SET_SHARED_LIBRARY_MAPFILE='' SET_SHARED_LIBRARY_NAME='' SET_SHARED_LIBRARY_ORIGIN='' SH='/bin/sh' SHARED_LIBRARY='' SHARED_LIBRARY_FLAGS='' SHARED_LIBRARY_SUFFIX='' SHELL='/bin/bash' SIGN_FLAG='' SJAVAC_SERVER_DIR='' SJAVAC_SERVER_JAVA='' SORT='/usr/bin/sort' SPARKLE_FRAMEWORK='' SPEC='/Users/mcherkas/ws/jdk8/jdk8u-dev/build/macosx-x86_64-normal-server-release/spec.gmk' SRC_ROOT='/Users/mcherkas/ws/jdk8/jdk8u-dev' STAT='/usr/bin/stat' STATIC_CXX_SETTING='' STATIC_LIBRARY='' STATIC_LIBRARY_SUFFIX='' STRIP='' SUPPORT_HEADFUL='yes' SUPPORT_HEADLESS='yes' SYS_ROOT='/' TAIL='/usr/bin/tail' TAR='/usr/bin/tar' TARGET_BITS_FLAG='' TEE='/usr/bin/tee' TEST_IN_BUILD='false' TIME='/usr/bin/time' TOOLS_DIR_CC='' TOOLS_DIR_CXX='' TOUCH='/usr/bin/touch' TR='/usr/bin/tr' UNAME='/usr/bin/uname' UNIQ='/usr/bin/uniq' UNLIMITED_CRYPTO='false' UNZIP='/usr/bin/unzip' UPX_EXE='' USER_RELEASE_SUFFIX='mcherkas_2015_06_09_23_21' USE_EXTERNAL_LIBGIF='' USE_EXTERNAL_LIBJPEG='' USE_EXTERNAL_LIBZ='' USE_PRECOMPILED_HEADER='' USING_BROKEN_SUSE_LD='' VARIANT='OPT' VS_INCLUDE='' VS_LIB='' VS_PATH='' WC='/usr/bin/wc' WHICH='/usr/bin/which' WINAR='' WINLD='' WIXDIR='' XARGS='/usr/bin/xargs' XATTR='/usr/bin/xattr' XCODEBUILD='/usr/bin/xcodebuild' XMKMF='' X_CFLAGS='' X_EXTRA_LIBS='' X_LIBS='' X_PRE_LIBS='' ZERO_ARCHDEF='AMD64' ZERO_ARCHFLAG='' ZIP='/usr/bin/zip' ZIP_DEBUGINFO_FILES='' ac_ct_CC='' ac_ct_CXX='' ac_ct_OBJC='' ac_ct_OBJCOPY='' ac_ct_OBJDUMP='' ac_ct_PROPER_COMPILER_CC='' ac_ct_PROPER_COMPILER_CXX='' bindir='${exec_prefix}/bin' build='x86_64-apple-darwin14.1.0' build_alias='' build_cpu='x86_64' build_os='darwin14.1.0' build_vendor='apple' datadir='${datarootdir}' datarootdir='${prefix}/share' docdir='${datarootdir}/doc/${PACKAGE_TARNAME}' dvidir='${docdir}' exec_prefix='NONE' host='x86_64-apple-darwin14.1.0' host_alias='' host_cpu='x86_64' host_os='darwin14.1.0' host_vendor='apple' htmldir='${docdir}' includedir='${prefix}/include' infodir='${datarootdir}/info' libdir='${exec_prefix}/lib' libexecdir='${exec_prefix}/libexec' localedir='${datarootdir}/locale' localstatedir='${prefix}/var' mandir='${datarootdir}/man' oldincludedir='/usr/include' pdfdir='${docdir}' prefix='NONE' program_transform_name='s,x,x,' psdir='${docdir}' sbindir='${exec_prefix}/sbin' sharedstatedir='${prefix}/com' sysconfdir='${prefix}/etc' target='x86_64-apple-darwin14.1.0' target_alias='' target_cpu='x86_64' target_os='darwin14.1.0' target_vendor='apple' ## ----------- ## ## confdefs.h. ## ## ----------- ## /* confdefs.h */ #define PACKAGE_NAME "OpenJDK" #define PACKAGE_TARNAME "openjdk" #define PACKAGE_VERSION "jdk8" #define PACKAGE_STRING "OpenJDK jdk8" #define PACKAGE_BUGREPORT "build-dev at openjdk.java.net" #define PACKAGE_URL "http://openjdk.java.net" configure: exit 77 From david.dehaven at oracle.com Tue Jun 9 21:11:15 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 9 Jun 2015 14:11:15 -0700 Subject: OpenJDK 8u45 on Yosemite In-Reply-To: <229B60BE-F829-473C-9B5C-A73A860E967D@gmail.com> References: <229B60BE-F829-473C-9B5C-A73A860E967D@gmail.com> Message-ID: > Hi all > > I had posted about problems with building openjdk8 on Mac OS X Yosemite last year. I am still unable to do the same. I did the following based on some posts tot he list in January: > > 1. bash configure ?with-tools-dir=?/Applications/Xcode4/Xcode.app/Contents/Developer/usr/bin/? > > 2. Applied the following patch to saproc.make: > - SALIBS = -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation > + SALIBS = -isysroot /Applications/Xcode4/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation > Now, the error shown is the following: > error: unable to open executable ?libjvm.dylib' > > What all should I do for a successful build? The backport of JDK-8043340 should have resolved this, this was done in time for 8u40. In short: don't use --with-tools-dir, use --with-xcode-path instead. There was a later fix to hotspot for building on Yosemite but it was too late for 8u40: changeset: 7161:10c237e58446 user: ddehaven date: Wed Mar 18 18:12:01 2015 -0700 summary: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) Patch: http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/10c237e58446 You can try applying that to your workspace and see if it helps. -DrD- From david.dehaven at oracle.com Tue Jun 9 21:19:05 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 9 Jun 2015 14:19:05 -0700 Subject: Building openjdk 8 on Mac OS X In-Reply-To: <55774A72.4070708@oracle.com> References: <2F46BC32-AB84-4640-A288-52DA2933B923@gmail.com> <545B318F.3090805@oracle.com> <5F78A0ED-DCE6-410D-9471-0732784DCD56@oracle.com> <55774A72.4070708@oracle.com> Message-ID: <7B6E8CA7-7AA1-40B8-A62A-3572F125A4A3@oracle.com> >> 2. Make a link form Xcode.4 lipo to /usr/bin/lipo You don't need to do this with the current command line tools, they've fixed the problem. If unsure, run "sudo xcode-select -switch /path/to/Xcode4.app" and then try running lipo with no args, if it deadlocks then it's still broken and you'll need to work around it. BUT with current JDK 8u you don't need to set Xcode 4 as the active Xcode, just pass --with-xcode-path=/path/to/Xcode4.app and it will figure everything out for you, including the lipo thing. Current jdk8u/dev should be buildable on Yosemite. I believe I also removed the need for lipo, it was never necessary. That might've been done for 9 only though. The configure args ONLY needs --with-xcode-path, don't pass the --with-extra-cflags args. You should see some lines like: checking Determining if we need to set DEVELOPER_DIR... yes (/path/to/Xcode4.app/Contents/Developer) checking for xcodebuild... /usr/bin/xcodebuild checking Determining Xcode SDK path... /path/to/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk If you see that, you should be good to go. -DrD- > On Jun 9, 2015, at 1:20 PM, mikhail cherkasov wrote: > > Hi Denis, > > I applied you instruction, but I still have an error during configuration: > > configure:21029: /usr/bin/gcc --version >&5 > i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) > Copyright (C) 2007 Free Software Foundation, Inc. > This is free software; see the source for copying conditions. There is NO > warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. > > couldn't understand kern.osversion `14.1.0' > .... > > configure:21131: error: C compiler cannot create executables > > I also attached config.log. > > Do you still can build jdk on macosx 10.10 ? Can you advise how to fix build in my environment? > > Thanks, > Mikhail. > > On 11/26/2014 4:30 PM, Denis Fokin wrote: >> Hi guys, >> >> good news. I am able to build open jdk8 on Yosemite (thanks to Anton Tarasov for his script to build on 10.9) >> >> Steps: >> >> 1. Download and save in some secure place Xcode4.6 >> 2. Make a link form Xcode.4 lipo to /usr/bin/lipo >> 3. Set MACOSX_DEPLOYMENT_TARGET enviroment variable to 10.8 >> 4. Execute configure like this >> >> sh configure --with-freetype=/Volumes/HD-PATU3/tools/freetype-2.4.0/ --with-extra-cflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-extra-cxxflags="-isysroot /Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -F/Applications/Xcode4.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks" --with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_20.jdk/Contents/Home/ >> >> Thank you, >> Denis. >> >> >> >>> On 12 Nov 2014, at 20:29, David DeHaven wrote: >>> >>> >>> Not 8, 9... >>> >>> -DrD- >>> >>>> Hi Wang >>>> >>>> You were able to compile openjdk8 on Yosemite!! Can you please look into the error faced by me (first post in the thread; posted below as well) and figure out the problem(s)? >>>> >>>> Regards, >>>> Manas >>>> >>>> >>>> >>>>> Yes, I can compile the whole mess on Yosemite/Xcode 6.1. There was an issue with FreeType when building OpenJDK, but it looks like that's been resolved now. >>>>> >>>>> -DrD- >>>>> >>>> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/utilities/yieldingWorkgroup.cpp >>>> Making signal interposition lib... >>>> couldn't understand kern.osversion `14.0.0' >>>> warning: (x86_64) /var/folders/16/5m_yzyd961b3l31crzg2hsl40000gp/T//ccEmbC6U.o unable to open object file >>>> warning: no debug symbols in executable (-arch x86_64) >>>> Making SA debugger back-end... >>>> couldn't understand kern.osversion `14.0.0' >>>> In file included from /System/Library/Frameworks/CoreServices.framework/Headers/CoreServices.h:55, >>>> from /System/Library/Frameworks/Foundation.framework/Headers/NSURLError.h:12, >>>> from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:80, >>>> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >>>> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:262: error: expected ?,? or ?}? before ?__attribute__? >>>> /System/Library/Frameworks/CoreServices.framework/Frameworks/FSEvents.framework/Headers/FSEvents.h:414: error: expected ?,? or ?}? before ?__attribute__? >>>> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:119, >>>> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >>>> /System/Library/Frameworks/Foundation.framework/Headers/NSUserActivity.h:55: error: expected a property attribute before ?weak? >>>> Compiling /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/src/share/vm/runtime/vm_version.cpp >>>> In file included from /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:171, >>>> from /Users/manas/Desktop/Software/openjdk/sources/openjdk8/hotspot/agent/src/os/bsd/MacosxDebuggerLocal.m:26: >>>> /System/Library/Frameworks/Foundation.framework/Headers/NSUserNotification.h:16: error: expected ?,? or ?}? before ?__attribute__? >>>> make[8]: *** [libsaproc.dylib] Error 1 >>>> make[8]: *** Waiting for unfinished jobs.... >>>> make[7]: *** [the_vm] Error 2 >>>> make[6]: *** [product] Error 2 >>>> make[5]: *** [generic_build2] Error 2 >>>> make[4]: *** [product] Error 2 >>>> make[3]: *** [all_product_universal] Error 2 >>>> make[2]: *** [universal_product] Error 2 >>>> make[1]: *** [/Users/manas/Desktop/Software/openjdk/sources/openjdk8/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 >>>> make: *** [hotspot-only] Error 2 >>>> > > From manasthakur17 at gmail.com Wed Jun 10 03:49:04 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 10 Jun 2015 09:19:04 +0530 Subject: OpenJDK 8u45 on Yosemite In-Reply-To: References: <229B60BE-F829-473C-9B5C-A73A860E967D@gmail.com> Message-ID: Hi David ?with-code-path is an unrecognised option; it?s not there in the configure script as well. Manas > On 10-Jun-2015, at 2:41 am, David DeHaven wrote: > > >> Hi all >> >> I had posted about problems with building openjdk8 on Mac OS X Yosemite last year. I am still unable to do the same. I did the following based on some posts tot he list in January: >> >> 1. bash configure ?with-tools-dir=?/Applications/Xcode4/Xcode.app/Contents/Developer/usr/bin/? >> >> 2. Applied the following patch to saproc.make: >> - SALIBS = -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation >> + SALIBS = -isysroot /Applications/Xcode4/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation >> Now, the error shown is the following: >> error: unable to open executable ?libjvm.dylib' >> >> What all should I do for a successful build? > > The backport of JDK-8043340 should have resolved this, this was done in time for 8u40. > > In short: don't use --with-tools-dir, use --with-xcode-path instead. > > > There was a later fix to hotspot for building on Yosemite but it was too late for 8u40: > changeset: 7161:10c237e58446 > user: ddehaven > date: Wed Mar 18 18:12:01 2015 -0700 > summary: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) > > Patch: > http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/10c237e58446 > > You can try applying that to your workspace and see if it helps. > > -DrD- > From manasthakur17 at gmail.com Wed Jun 10 04:52:35 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 10 Jun 2015 10:22:35 +0530 Subject: OpenJDK 8u45 on Yosemite In-Reply-To: References: <229B60BE-F829-473C-9B5C-A73A860E967D@gmail.com> Message-ID: Okay, I found that I should use ?jdk8u-dev?, and not ?jdk8u?; ?with-xcode-path is a valid option there. I?ll update if I am able to build now. Regards, Manas > On 10-Jun-2015, at 9:19 am, Manas Thakur wrote: > > Hi David > > ?with-code-path is an unrecognised option; it?s not there in the configure script as well. > > Manas > > >> On 10-Jun-2015, at 2:41 am, David DeHaven > wrote: >> >> >>> Hi all >>> >>> I had posted about problems with building openjdk8 on Mac OS X Yosemite last year. I am still unable to do the same. I did the following based on some posts tot he list in January: >>> >>> 1. bash configure ?with-tools-dir=?/Applications/Xcode4/Xcode.app/Contents/Developer/usr/bin/? >>> >>> 2. Applied the following patch to saproc.make: >>> - SALIBS = -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation >>> + SALIBS = -isysroot /Applications/Xcode4/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation >>> Now, the error shown is the following: >>> error: unable to open executable ?libjvm.dylib' >>> >>> What all should I do for a successful build? >> >> The backport of JDK-8043340 should have resolved this, this was done in time for 8u40. >> >> In short: don't use --with-tools-dir, use --with-xcode-path instead. >> >> >> There was a later fix to hotspot for building on Yosemite but it was too late for 8u40: >> changeset: 7161:10c237e58446 >> user: ddehaven >> date: Wed Mar 18 18:12:01 2015 -0700 >> summary: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) >> >> Patch: >> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/10c237e58446 >> >> You can try applying that to your workspace and see if it helps. >> >> -DrD- >> > From manasthakur17 at gmail.com Wed Jun 10 05:24:59 2015 From: manasthakur17 at gmail.com (Manas Thakur) Date: Wed, 10 Jun 2015 10:54:59 +0530 Subject: OpenJDK 8u45 on Yosemite In-Reply-To: References: <229B60BE-F829-473C-9B5C-A73A860E967D@gmail.com> Message-ID: <2395AA84-CB4D-4305-90A2-485DE896C9D9@gmail.com> Hi David jdk8u-dev build worked perfectly with ??with-code-path? option; no other patches were required! Thanks :-) Regards, Manas > On 10-Jun-2015, at 10:22 am, Manas Thakur wrote: > > Okay, I found that I should use ?jdk8u-dev?, and not ?jdk8u?; ?with-xcode-path is a valid option there. > I?ll update if I am able to build now. > > Regards, > Manas > > > >> On 10-Jun-2015, at 9:19 am, Manas Thakur > wrote: >> >> Hi David >> >> ?with-code-path is an unrecognised option; it?s not there in the configure script as well. >> >> Manas >> >> >>> On 10-Jun-2015, at 2:41 am, David DeHaven > wrote: >>> >>> >>>> Hi all >>>> >>>> I had posted about problems with building openjdk8 on Mac OS X Yosemite last year. I am still unable to do the same. I did the following based on some posts tot he list in January: >>>> >>>> 1. bash configure ?with-tools-dir=?/Applications/Xcode4/Xcode.app/Contents/Developer/usr/bin/? >>>> >>>> 2. Applied the following patch to saproc.make: >>>> - SALIBS = -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation >>>> + SALIBS = -isysroot /Applications/Xcode4/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation >>>> Now, the error shown is the following: >>>> error: unable to open executable ?libjvm.dylib' >>>> >>>> What all should I do for a successful build? >>> >>> The backport of JDK-8043340 should have resolved this, this was done in time for 8u40. >>> >>> In short: don't use --with-tools-dir, use --with-xcode-path instead. >>> >>> >>> There was a later fix to hotspot for building on Yosemite but it was too late for 8u40: >>> changeset: 7161:10c237e58446 >>> user: ddehaven >>> date: Wed Mar 18 18:12:01 2015 -0700 >>> summary: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) >>> >>> Patch: >>> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/10c237e58446 >>> >>> You can try applying that to your workspace and see if it helps. >>> >>> -DrD- >>> >> > From erik.joelsson at oracle.com Wed Jun 10 07:18:03 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Jun 2015 09:18:03 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576EF94.3010500@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> Message-ID: <5577E4AB.4090305@oracle.com> Looks good. /Erik On 2015-06-09 15:52, Magnus Ihse Bursie wrote: > Here's an updated webrev, which fixes the typos that were pointed out > by reviewers: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ > > > And here's a (much simpler) delta webrev which shows just these changes: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ > > > /Magnus > > On 2015-06-09 15:20, Daniel D. Daugherty wrote: >> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >>> Hi Daniel, >>> >>> Thank you for your thorough review! >> >> This was my (failing) attempt at a "fast pass" review... :-) >> >> >>> >>> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>>> > >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>>> >>>> >>>> General comment: Not all copyright years were updated. >>>> General comment: It looks like support for the 'patch' value is not >>>> completely >>>> implemented through all the Makefiles. I didn't audit for this, >>>> but it's >>>> just my impression. >>> >>> You are basically correct. The makefiles all propagate the patch >>> value where needed, but the actual source code changes in hotspot >>> and jdk ignores the patch field as of now. This will be corrected in >>> a later add-on patch, submitted by someone from the jdk and/or >>> hotspot team rather than the build team. >>> >>>> >>>> common/autoconf/generated-configure.sh >>>> There are multiple Copyright notices in this file. Why? >>> Oh dear, you've reviewed the generated file. :-& I'm really >>> impressed by your effort! >> >> Ahhh... now that you say it... it sounds familiar... I may have >> made this same mistake before. I'll try to remember next time. >> >> >>> However, the generated-configure.sh file is automatically created by >>> the autoconf framework from the rest of the files in >>> common/autoconf/*, so we cannot direcly modify it's contents - only >>> indirectly. The reason it's checked in, is that otherwise every user >>> would need to generate it before being able to run configure. In >>> build reviews, we usually either revert changes to >>> generated-configure.sh before posting a review to hide it (and >>> re-generate it before pushing), or we just ignore it during reviews. >>> I should have done that, or pointed out that it was not needed nor >>> possible to review when I cross-posted. I'm sorry. >>> >>>> >>>> L4076: # Verify that a given string represent a valid version >>>> number, and assing it to >>>> L4077: # a variable. >>>> Fixed two typos and reformat a bit: >>>> # Verify that a given string represents a valid version >>>> number, and >>>> # assigning it to a variable. >>> I'll put that fix in the source .m4 file instead. Thanks. >>>> >>>> L20262: as_fn_error $? "--with--version-string must have a >>>> value" "$LINENO" 5 >>>> The '--with--version...' part doesn't match previous usages >>>> where >>>> '--with-version...' is used >>> Yes, you're right. Erik pointed it out as well. It's a typo in the >>> error message. It's all over the place due to copied code. I'll fix >>> it in the source .m4 file. >>> >>> (As a side note, I have a half-finished follow-up patch that will >>> reduce the amount of code duplication, but it requires some >>> framework changes so it'll have to be a separate thing.) >>> >>>> >>>> L20275: # Unspecified numerical fields is interpreted as 0. >>>> Grammar: 'is interpreted' -> 'are interpreted' >>>> >>>> L20286: as_fn_error $? "Version string contains + but >>>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>>> Grammar: 'is missing' -> 'are missing' >>> Those darn English plural forms! Why can't you all do as we sensible >>> Swedes and get rid of them? ;-) >>> >>> (I'll fix) >>> >>>> >>>> L20388: username=`$ECHO "$USER" | $TR -d -c >>>> '[a-z][A-Z][0-9]'` >>>> This assumes that the "USER" variable is set. Should there >>>> be a check for "" and perhaps use "no_user_specified" or >>>> something like that? Perhaps the build setup always makes >>>> sure that "USER" is set to something. Don't know. >>> Hm. I think the worst thing that'll happen is that the username part >>> of the opt string gets empty. This part is basically copied right >>> off the old build, where we have relied on the $USER variable being >>> present for all the time with no problems, so I think it's quite >>> safe to assume. >>>> >>>> common/autoconf/jdk-options.m4 >>>> Don't know why the 'elliptic curve crypto implementation' support >>>> is relocated as part of this changeset, but ... >>> It was incorrectly placed not at the top indentation level, but in >>> the middle of the function definition where the old versioning code >>> were handled. (Which, mostly by chance, happens to work in autoconf, >>> but is really bad style). >>> >>>> make/Javadoc.gmk >>>> Did you mean to remove the 'clean' target? >>> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >>> that's just some dead code. >>> >>>> >>>> hotspot/make/windows/makefiles/compile.make >>>> No changes in the frames view. >>>> Update: udiff view shows a blank line deleted at the end of the >>>> file. >>> >>> That's probably the result of some change going forth and then back >>> again during development. But then again, removing extra blank >>> linkes is not a bad thing. (jcheck unfortunately does not enforce >>> any style checks for make files :-( so they tend to detoriate over >>> time.) >>> >>>> >>>> hotspot/src/share/vm/runtime/java.cpp >>>> L661: void JDK_Version::fully_initialize( >>>> L662: uint8_t major, uint8_t minor, uint8_t security, >>>> uint8_t update) { >>>> L663: // This is only called when current is less than 1.6 >>>> and we've gotten >>>> >>>> Since you're ripping out vestigial version support, I think >>>> this >>>> function can go away since this is version 9 and newer. >>>> Don't really >>>> know for sure, but based on that comment... >>> It probably can, yes. This and other core changes to the actual >>> .cpp/.java files will be addressed in a follow-up patch. >>>> >>>> hotspot/src/share/vm/runtime/java.hpp >>>> No comments. >>>> >>>> hotspot/src/share/vm/runtime/vmStructs.cpp >>>> L1240: please make the 'int' parameter align like the rest. >>> Are you okay with defering such a change to a follow-up patch? >> >> Yes. >> >> >>> It's likely the entire struct will need changes to be able to handle >>> a theoretically arbitrarily long version number. >>> >>>> >>>> hotspot/src/share/vm/runtime/vm_version.cpp >>>> L84: void Abstract_VM_Version::initialize() { >>>> L85: // FIXME: Initialization can probably be removed now. >>>> I agree, but that would entail also removing the >>>> _initialized and the uses of it... Follow on bug fix? >>> Definitely follow on. >>> >>>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>>> L149: * Returns the security version of the running JVM if >>>> it's 1.6 or newer >>>> This JavaDoc update is wrong, but it might not be important >>>> if sun.misc.Version class is going away. >>> I'm not sure if it's going to be replaced by, or just complemented >>> by java.util.Version, but in any case it will need a follow-up patch >>> to clean up this and other issues. >>>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>>> >>>> old L171: case "1.9": >>>> new L171: case "9": >>>> Should this logic support both versions? Will dropping >>>> "1.9" here prevent a pre-version changeset JVM from >>>> being dropped into a JDK for triage purposes? >>>> >>>> Granted we don't often triage 'javac' with different JVMs, >>>> but... >>> I'll defer that question to Kumar, who wrote that piece of code. My >>> guess is that when Hotspot express was dropped, the ability to use a >>> JVM from another JDK release bit rotteded away. >>> >>> /Magnus >> >> Dan > From Alan.Bateman at oracle.com Wed Jun 10 07:53:11 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Jun 2015 08:53:11 +0100 Subject: sjavac always compiled? Message-ID: <5577ECE7.4060708@oracle.com> There was a sjavac update pushed to jdk9/dev yesterday (JDK-8054717). I seem to be running into build issues on OS X since then (clean build, not a reconfigure). My boot JDK is 8u31. My configure command does not specify --enable-sjavac so I'm surprised this code is being compiled. Anyone else seeing this? -Alan Building target 'default' in configuration 'macosx-x86_64-normal-server-release' Compiling 830 files for BUILD_INTERIM_LANGTOOLS /ws/jdk9-dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java:231: error: no suitable method found for collect(Collector>) return c.stream().collect(Collectors.toMap(indexFunction, o -> o)); ^ method Stream.collect(Supplier,BiConsumer,BiConsumer) is not applicable (cannot infer type-variable(s) R#1 (actual and formal argument lists differ in length)) method Stream.collect(Collector) is not applicable (cannot infer type-variable(s) R#2,A,CAP#3,T#3,K,U (argument mismatch; Collector> cannot be converted to Collector>)) where T#1,I,R#1,T#2,R#2,A,T#3,K,U are type-variables: T#1 extends Object declared in method indexBy(Collection,Function) I extends Object declared in method indexBy(Collection,Function) R#1 extends Object declared in method collect(Supplier,BiConsumer,BiConsumer) T#2 extends Object declared in interface Stream R#2 extends Object declared in method collect(Collector) A extends Object declared in method collect(Collector) T#3 extends Object declared in method toMap(Function,Function) K extends Object declared in method toMap(Function,Function) U extends Object declared in method toMap(Function,Function) where CAP#1,CAP#2,CAP#3,CAP#4 are fresh type-variables: CAP#1 extends Object from capture of ? CAP#2 extends T#1 from capture of ? extends T#1 CAP#3 extends Object from capture of ? CAP#4 extends Object from capture of ? 1 error From erik.joelsson at oracle.com Wed Jun 10 08:00:30 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Jun 2015 10:00:30 +0200 Subject: sjavac always compiled? In-Reply-To: <5577ECE7.4060708@oracle.com> References: <5577ECE7.4060708@oracle.com> Message-ID: <5577EE9E.2030503@oracle.com> Hello, Sjavac has always been compiled in the interim langtools step, the configure flag only affects using it to compile the rest of the java classes. Has a bug been created for this? /Erik On 2015-06-10 09:53, Alan Bateman wrote: > > There was a sjavac update pushed to jdk9/dev yesterday (JDK-8054717). > I seem to be running into build issues on OS X since then (clean > build, not a reconfigure). My boot JDK is 8u31. My configure command > does not specify --enable-sjavac so I'm surprised this code is being > compiled. > > Anyone else seeing this? > > -Alan > > Building target 'default' in configuration > 'macosx-x86_64-normal-server-release' > Compiling 830 files for BUILD_INTERIM_LANGTOOLS > /ws/jdk9-dev/langtools/src/jdk.compiler/share/classes/com/sun/tools/sjavac/Util.java:231: > error: no suitable method found for > collect(Collector>) > return c.stream().collect(Collectors.toMap(indexFunction, o -> > o)); > ^ > method Stream.collect(Supplier,BiConsumer CAP#2>,BiConsumer) is not applicable > (cannot infer type-variable(s) R#1 > (actual and formal argument lists differ in length)) > method Stream.collect(Collector) is > not applicable > (cannot infer type-variable(s) R#2,A,CAP#3,T#3,K,U > (argument mismatch; Collector> > cannot be converted to Collector>)) > where T#1,I,R#1,T#2,R#2,A,T#3,K,U are type-variables: > T#1 extends Object declared in method indexBy(Collection extends T#1>,Function) > I extends Object declared in method indexBy(Collection extends T#1>,Function) > R#1 extends Object declared in method > collect(Supplier,BiConsumer T#2>,BiConsumer) > T#2 extends Object declared in interface Stream > R#2 extends Object declared in method collect(Collector super T#2,A,R#2>) > A extends Object declared in method collect(Collector super T#2,A,R#2>) > T#3 extends Object declared in method toMap(Function super T#3,? extends K>,Function) > K extends Object declared in method toMap(Function super T#3,? extends K>,Function) > U extends Object declared in method toMap(Function super T#3,? extends K>,Function) > where CAP#1,CAP#2,CAP#3,CAP#4 are fresh type-variables: > CAP#1 extends Object from capture of ? > CAP#2 extends T#1 from capture of ? extends T#1 > CAP#3 extends Object from capture of ? > CAP#4 extends Object from capture of ? > 1 error > From Alan.Bateman at oracle.com Wed Jun 10 08:06:44 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 10 Jun 2015 09:06:44 +0100 Subject: sjavac always compiled? In-Reply-To: <5577EE9E.2030503@oracle.com> References: <5577ECE7.4060708@oracle.com> <5577EE9E.2030503@oracle.com> Message-ID: <5577F014.8030800@oracle.com> On 10/06/2015 09:00, Erik Joelsson wrote: > Hello, > > Sjavac has always been compiled in the interim langtools step, the > configure flag only affects using it to compile the rest of the java > classes. > > Has a bug been created for this? > I haven't created a bug for this as I wasn't sure if this was something in my environment or an issue with the sjavac patch and some interaction with the interim javac build. -Alan From andreas.lundblad at oracle.com Wed Jun 10 09:02:19 2015 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 10 Jun 2015 11:02:19 +0200 Subject: sjavac always compiled? In-Reply-To: <5577F014.8030800@oracle.com> References: <5577ECE7.4060708@oracle.com> <5577EE9E.2030503@oracle.com> <5577F014.8030800@oracle.com> Message-ID: <20150610090218.GA1107@e6430> On Wed, Jun 10, 2015 at 09:06:44AM +0100, Alan Bateman wrote: > > > On 10/06/2015 09:00, Erik Joelsson wrote: > >Hello, > > > >Sjavac has always been compiled in the interim langtools step, the > >configure flag only affects using it to compile the rest of the > >java classes. > > > >Has a bug been created for this? > > > I haven't created a bug for this as I wasn't sure if this was > something in my environment or an issue with the sjavac patch and > some interaction with the interim javac build. I can reproduce this by compiling that method alone using 8u31. Seems to be a javac type inference bug, because changing Collectors.toMap to Collectors.toMap solves the issue. (It seems to have been fixed in 8u40.) What's the approperiate procedure here? Should I submit a patch that adds the type arguments to avoid forcing people to update their boot jdks? -- Andreas From andreas.lundblad at oracle.com Wed Jun 10 09:21:52 2015 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Wed, 10 Jun 2015 11:21:52 +0200 Subject: sjavac always compiled? In-Reply-To: <20150610090218.GA1107@e6430> References: <5577ECE7.4060708@oracle.com> <5577EE9E.2030503@oracle.com> <5577F014.8030800@oracle.com> <20150610090218.GA1107@e6430> Message-ID: <20150610092152.GB1107@e6430> On Wed, Jun 10, 2015 at 11:02:19AM +0200, Andreas Lundblad wrote: > What's the approperiate procedure here? Should I submit a patch that adds the type arguments to avoid forcing people to update their boot jdks? I have now pushed a patch that adds the type arguments. http://hg.openjdk.java.net/jdk9/dev/langtools/rev/5021d414632a -- Andreas From david.holmes at oracle.com Wed Jun 10 09:58:11 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 10 Jun 2015 19:58:11 +1000 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576EF94.3010500@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> Message-ID: <55780A33.1010302@oracle.com> Hi Magnus, Generally looks good - a few comments/queries below. On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: > Here's an updated webrev, which fixes the typos that were pointed out by > reviewers: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ common/autoconf/version-numbers Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of the version info? (Even if all zeroes presently.) --- Looking at hotspot changes I can't convince myself that the new streamlined "version" variables will capture things like "fastdebug". Will that filter through via configure variables? --- make/*/makefiles/vm.make Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) --- hotspot/src/share/vm/prims/jvm.h jdk/src/java.base/share/native/include/jvm.h I think this comment is way out of date: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */ and can be completely removed. Even if still true, mention of an "RE build" has no place in OpenJDK sources. --- hotspot/src/share/vm/runtime/java.cpp I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense. --- hotspot/src/share/vm/runtime/vmStructs.cpp Please fix the alignment (3 extra spaces on modified line): 1239 static_field(Abstract_VM_Version, _vm_minor_version, int) \ 1240 static_field(Abstract_VM_Version, _vm_security_version, int) \ --- hotspot/test/runtime/6981737/Test6981737.java This test is really only valid for the new version scheme now, so it should probably be rewritten - and in that case it really isn't testing 6981737 but should be replaced by a new test for the new version format. --- jdk/src/java.base/share/classes/sun/misc/Version.java.template This comment is nonsensical: /** ! * Returns the security version of the running JVM if it's 1.6 or newer * or any RE VM build. It will return 0 if it's an internal 1.5 or * 1.4.x build. * @since 1.6 */ as security version does not exist pre 9. Normally you should be adding a new method and deprecating the old one. The new one is @since 9. /** ! * Returns the security version of the running JDK. * @since 1.6 */ Ditto: @since 9 (but again old should be deprecated and new method added) 253 /** 254 * Returns the build number of the running JDK if it's a RE build 255 * It will return 0 if it's an internal build. As with jvm.h this seems obsolete commentary these days - not only RE builds define a build number. Thanks, David > > And here's a (much simpler) delta webrev which shows just these changes: > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-01/webrev.01/ > > > /Magnus > > On 2015-06-09 15:20, Daniel D. Daugherty wrote: >> On 6/9/15 7:12 AM, Magnus Ihse Bursie wrote: >>> Hi Daniel, >>> >>> Thank you for your thorough review! >> >> This was my (failing) attempt at a "fast pass" review... :-) >> >> >>> >>> On 2015-06-09 01:31, Daniel D. Daugherty wrote: >>>> > >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >>>> >>>> >>>> General comment: Not all copyright years were updated. >>>> General comment: It looks like support for the 'patch' value is not >>>> completely >>>> implemented through all the Makefiles. I didn't audit for this, >>>> but it's >>>> just my impression. >>> >>> You are basically correct. The makefiles all propagate the patch >>> value where needed, but the actual source code changes in hotspot and >>> jdk ignores the patch field as of now. This will be corrected in a >>> later add-on patch, submitted by someone from the jdk and/or hotspot >>> team rather than the build team. >>> >>>> >>>> common/autoconf/generated-configure.sh >>>> There are multiple Copyright notices in this file. Why? >>> Oh dear, you've reviewed the generated file. :-& I'm really impressed >>> by your effort! >> >> Ahhh... now that you say it... it sounds familiar... I may have >> made this same mistake before. I'll try to remember next time. >> >> >>> However, the generated-configure.sh file is automatically created by >>> the autoconf framework from the rest of the files in >>> common/autoconf/*, so we cannot direcly modify it's contents - only >>> indirectly. The reason it's checked in, is that otherwise every user >>> would need to generate it before being able to run configure. In >>> build reviews, we usually either revert changes to >>> generated-configure.sh before posting a review to hide it (and >>> re-generate it before pushing), or we just ignore it during reviews. >>> I should have done that, or pointed out that it was not needed nor >>> possible to review when I cross-posted. I'm sorry. >>> >>>> >>>> L4076: # Verify that a given string represent a valid version >>>> number, and assing it to >>>> L4077: # a variable. >>>> Fixed two typos and reformat a bit: >>>> # Verify that a given string represents a valid version >>>> number, and >>>> # assigning it to a variable. >>> I'll put that fix in the source .m4 file instead. Thanks. >>>> >>>> L20262: as_fn_error $? "--with--version-string must have a >>>> value" "$LINENO" 5 >>>> The '--with--version...' part doesn't match previous usages >>>> where >>>> '--with-version...' is used >>> Yes, you're right. Erik pointed it out as well. It's a typo in the >>> error message. It's all over the place due to copied code. I'll fix >>> it in the source .m4 file. >>> >>> (As a side note, I have a half-finished follow-up patch that will >>> reduce the amount of code duplication, but it requires some framework >>> changes so it'll have to be a separate thing.) >>> >>>> >>>> L20275: # Unspecified numerical fields is interpreted as 0. >>>> Grammar: 'is interpreted' -> 'are interpreted' >>>> >>>> L20286: as_fn_error $? "Version string contains + but >>>> both 'BUILD' and 'OPT' is missing" "$LINENO" 5 >>>> Grammar: 'is missing' -> 'are missing' >>> Those darn English plural forms! Why can't you all do as we sensible >>> Swedes and get rid of them? ;-) >>> >>> (I'll fix) >>> >>>> >>>> L20388: username=`$ECHO "$USER" | $TR -d -c >>>> '[a-z][A-Z][0-9]'` >>>> This assumes that the "USER" variable is set. Should there >>>> be a check for "" and perhaps use "no_user_specified" or >>>> something like that? Perhaps the build setup always makes >>>> sure that "USER" is set to something. Don't know. >>> Hm. I think the worst thing that'll happen is that the username part >>> of the opt string gets empty. This part is basically copied right off >>> the old build, where we have relied on the $USER variable being >>> present for all the time with no problems, so I think it's quite safe >>> to assume. >>>> >>>> common/autoconf/jdk-options.m4 >>>> Don't know why the 'elliptic curve crypto implementation' support >>>> is relocated as part of this changeset, but ... >>> It was incorrectly placed not at the top indentation level, but in >>> the middle of the function definition where the old versioning code >>> were handled. (Which, mostly by chance, happens to work in autoconf, >>> but is really bad style). >>> >>>> make/Javadoc.gmk >>>> Did you mean to remove the 'clean' target? >>> Yep. Cleaning is done by the top-level Main.gmk makefile nowadays, >>> that's just some dead code. >>> >>>> >>>> hotspot/make/windows/makefiles/compile.make >>>> No changes in the frames view. >>>> Update: udiff view shows a blank line deleted at the end of the >>>> file. >>> >>> That's probably the result of some change going forth and then back >>> again during development. But then again, removing extra blank linkes >>> is not a bad thing. (jcheck unfortunately does not enforce any style >>> checks for make files :-( so they tend to detoriate over time.) >>> >>>> >>>> hotspot/src/share/vm/runtime/java.cpp >>>> L661: void JDK_Version::fully_initialize( >>>> L662: uint8_t major, uint8_t minor, uint8_t security, >>>> uint8_t update) { >>>> L663: // This is only called when current is less than 1.6 and >>>> we've gotten >>>> >>>> Since you're ripping out vestigial version support, I think >>>> this >>>> function can go away since this is version 9 and newer. >>>> Don't really >>>> know for sure, but based on that comment... >>> It probably can, yes. This and other core changes to the actual >>> .cpp/.java files will be addressed in a follow-up patch. >>>> >>>> hotspot/src/share/vm/runtime/java.hpp >>>> No comments. >>>> >>>> hotspot/src/share/vm/runtime/vmStructs.cpp >>>> L1240: please make the 'int' parameter align like the rest. >>> Are you okay with defering such a change to a follow-up patch? >> >> Yes. >> >> >>> It's likely the entire struct will need changes to be able to handle >>> a theoretically arbitrarily long version number. >>> >>>> >>>> hotspot/src/share/vm/runtime/vm_version.cpp >>>> L84: void Abstract_VM_Version::initialize() { >>>> L85: // FIXME: Initialization can probably be removed now. >>>> I agree, but that would entail also removing the >>>> _initialized and the uses of it... Follow on bug fix? >>> Definitely follow on. >>> >>>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>>> L149: * Returns the security version of the running JVM if >>>> it's 1.6 or newer >>>> This JavaDoc update is wrong, but it might not be important >>>> if sun.misc.Version class is going away. >>> I'm not sure if it's going to be replaced by, or just complemented by >>> java.util.Version, but in any case it will need a follow-up patch to >>> clean up this and other issues. >>>> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >>>> >>>> old L171: case "1.9": >>>> new L171: case "9": >>>> Should this logic support both versions? Will dropping >>>> "1.9" here prevent a pre-version changeset JVM from >>>> being dropped into a JDK for triage purposes? >>>> >>>> Granted we don't often triage 'javac' with different JVMs, >>>> but... >>> I'll defer that question to Kumar, who wrote that piece of code. My >>> guess is that when Hotspot express was dropped, the ability to use a >>> JVM from another JDK release bit rotteded away. >>> >>> /Magnus >> >> Dan > From magnus.ihse.bursie at oracle.com Wed Jun 10 12:13:16 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Jun 2015 14:13:16 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55780A33.1010302@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> Message-ID: <557829DC.8000405@oracle.com> On 2015-06-10 11:58, David Holmes wrote: > Hi Magnus, > > Generally looks good - a few comments/queries below. In general, I believe most issues you found are valid. :-) However, as I said before in this thread, I'd like to see them resolved in the needed follow-up patches. The source code changes in Hotspot and JDK are inadequate to fully implement JEP-223, so these areas will need to be rewritten anyhow. Are you okay with resolving these issues later? > > On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >> Here's an updated webrev, which fixes the typos that were pointed out by >> reviewers: >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >> > > common/autoconf/version-numbers > > Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of > the version info? (Even if all zeroes presently.) So that's a tricky one. :-& The question here is, I think, does it make sense to update version-numbers when we do a security (9.0.1) or minor (9.1.0) release? Looking historically, the version-numbers file have not been changed for the 8u family. The only change was going from 8 to 9 when creating the new jdk9 forest. That was what I based my decition to only have the major number in the file. (The rest of the version string is set by configure flags when building, in Oracle case by the RE team.) If it makes sense to put the minor/security/patch numbers here, I won't oppose it, but I guess we have until the first such release to figure out what's best, and that likely includes discussion with RE and possibly other consumers in the community (RedHat etc). > > --- > > Looking at hotspot changes I can't convince myself that the new > streamlined "version" variables will capture things like "fastdebug". > Will that filter through via configure variables? The "fastdebug" label has been handled as a less valued token in the JEP-223 process. Right now there's no mention of it at all in the version string proposal in the JEP. As I understand it, Iris is about to propose an amendment which will just make fastdebug be a part of the OPT string. I'm not entirely happy with that myself, but that's the way it's decided. So wherever you can see the OPT string, you'll see the debug level tag. Currently, however, that's not how it is implemented in this patch. Since no decision was made on this (and it's still not formally decided), I had to pick a route to go forward. The current patch will instead put the "fastdebug" label as part of the PRE string (that's the reason for the pre-base and pre-debuglevel arguments to configure). If the planned changes goes into the JEP, this'll change to make the debuglevel tag a part of the OPT string instead. > --- > > make/*/makefiles/vm.make > > Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the > VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a > stand-alone hotspot build?) The hotspot JEP-223 work initially made by Alejandro kept support for stand-alone hotspot builds. I made additional changes on top of that, which still tried to cater for stand-alone builds. At this very moment I'm not sure if stand-alone hotspot builds are supposed to work or not, but I've tried to not change the situation with this patch. There are two future changes coming down the pipe: One is the additional JEP-223 work needed for Hotspot. I know Alejandro had plans for redesigning the API between Hotspot and the JDK, so no JDK version strings should be compiled into the JVM, but all of it extracted during an API in runtime. That would make most (all?) of the makefile changes in hotspot irrelevant. However, that implementation is not even started, so it's needed for the time being. The second change is the build-infra hotspot makefile rewrite. When that happens, stand-alone builds will definitely disappear, and if Hotspot still needs make support for version strings, then the logical choice is to use VERSION_CFLAGS. Ok? > > --- > > hotspot/src/share/vm/prims/jvm.h > jdk/src/java.base/share/native/include/jvm.h > > I think this comment is way out of date: > > /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER > is set to bNN) > * It will be zero for internal builds. > */ > > and can be completely removed. Even if still true, mention of an "RE > build" has no place in OpenJDK sources. Yep, agree. Follow-up patch, right? > > --- > > hotspot/src/share/vm/runtime/java.cpp > > I think a lot of the modified code is obsolete post Hotspot Express - > which makes it hard to determine if the changes make sense. Yep, agree. Follow-up patch, right? > > --- > > hotspot/src/share/vm/runtime/vmStructs.cpp > > Please fix the alignment (3 extra spaces on modified line): > > 1239 static_field(Abstract_VM_Version, _vm_minor_version, > int) \ > 1240 static_field(Abstract_VM_Version, > _vm_security_version, int) \ I was about to say "follow-up patch", but ugly indentation really sucks so I can fix this. Ok if I skip redoing the review for that? > > --- > > hotspot/test/runtime/6981737/Test6981737.java > > This test is really only valid for the new version scheme now, so it > should probably be rewritten - and in that case it really isn't > testing 6981737 but should be replaced by a new test for the new > version format. Yep, agree. Follow-up patch, right? > > --- > > jdk/src/java.base/share/classes/sun/misc/Version.java.template > > This comment is nonsensical: > > /** > ! * Returns the security version of the running JVM if it's 1.6 > or newer > * or any RE VM build. It will return 0 if it's an internal 1.5 or > * 1.4.x build. > * @since 1.6 > */ > > as security version does not exist pre 9. Normally you should be > adding a new method and deprecating the old one. The new one is @since 9. Yep, agree. Follow-up patch, right? > > /** > ! * Returns the security version of the running JDK. > * @since 1.6 > */ > > Ditto: @since 9 (but again old should be deprecated and new method added) > > 253 /** > 254 * Returns the build number of the running JDK if it's a RE > build > 255 * It will return 0 if it's an internal build. > > As with jvm.h this seems obsolete commentary these days - not only RE > builds define a build number. Yep, agree. Follow-up patch, right? /Magnus > > Thanks, > David From maurizio.cimadamore at oracle.com Wed Jun 10 13:25:36 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Jun 2015 14:25:36 +0100 Subject: question on checking dependencies across modules Message-ID: <55783AD0.5060705@oracle.com> Hi, In the context of the IntelliJ project support for JDK, I have a question on the very last step of 'make images' : ## Starting verify-modules Checking dependencies across JDK modules Access verification succeeded. I noticed that this step is always applied, regardless of whether there was actually any change in the sources/built classes or not. Is that deliberate? This is a bit unfortunate as in our setup we depend on 'make images' to run tests, and if there's nothing to do, you will still have to wait several seconds for 'make images' to complete. Maurizio From magnus.ihse.bursie at oracle.com Wed Jun 10 13:44:41 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Wed, 10 Jun 2015 15:44:41 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557625C8.5050200@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> Message-ID: <55783F49.6030906@oracle.com> On 2015-06-09 01:31, Daniel D. Daugherty wrote: > > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 > > > General comment: Not all copyright years were updated. I realize I missed that part of the review. :-( I have now updated the copyright years. Here's a delta review: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-02/webrev.01/ Here's the complete review once again: http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.03 Hopefully this is now the final version to be pushed to verona, and that any additional problems can be resolved with follow-up patches. /Magnus From erik.joelsson at oracle.com Wed Jun 10 15:30:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 10 Jun 2015 17:30:57 +0200 Subject: question on checking dependencies across modules In-Reply-To: <55783AD0.5060705@oracle.com> References: <55783AD0.5060705@oracle.com> Message-ID: <55785831.9040903@oracle.com> On 2015-06-10 15:25, Maurizio Cimadamore wrote: > Hi, > In the context of the IntelliJ project support for JDK, I have a > question on the very last step of 'make images' : > > ## Starting verify-modules > Checking dependencies across JDK modules > Access verification succeeded. > > I noticed that this step is always applied, regardless of whether > there was actually any change in the sources/built classes or not. Is > that deliberate? This is a bit unfortunate as in our setup we depend > on 'make images' to run tests, and if there's nothing to do, you will > still have to wait several seconds for 'make images' to complete. > You are not alone in finding it annoying. It was added to the images target to force it to be run often. We will stop running it when the module system is properly in place and can verify this implicitly at compile time. Unconditionally running it when nothing has changed could be fixed and would help in some situations. A workaround is to run "make jimages", which is usually what you want anyway and then following that with "make test-only" which bypasses the dependency on images. /Erik > Maurizio From maurizio.cimadamore at oracle.com Wed Jun 10 15:47:09 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Wed, 10 Jun 2015 16:47:09 +0100 Subject: question on checking dependencies across modules In-Reply-To: <55785831.9040903@oracle.com> References: <55783AD0.5060705@oracle.com> <55785831.9040903@oracle.com> Message-ID: <55785BFD.4040104@oracle.com> On 10/06/15 16:30, Erik Joelsson wrote: > > On 2015-06-10 15:25, Maurizio Cimadamore wrote: >> Hi, >> In the context of the IntelliJ project support for JDK, I have a >> question on the very last step of 'make images' : >> >> ## Starting verify-modules >> Checking dependencies across JDK modules >> Access verification succeeded. >> >> I noticed that this step is always applied, regardless of whether >> there was actually any change in the sources/built classes or not. Is >> that deliberate? This is a bit unfortunate as in our setup we depend >> on 'make images' to run tests, and if there's nothing to do, you will >> still have to wait several seconds for 'make images' to complete. >> > You are not alone in finding it annoying. It was added to the images > target to force it to be run often. We will stop running it when the > module system is properly in place and can verify this implicitly at > compile time. Unconditionally running it when nothing has changed > could be fixed and would help in some situations. A workaround is to > run "make jimages", which is usually what you want anyway and then > following that with "make test-only" which bypasses the dependency on > images. Ok thanks for the tip, I will try that. Maurizio > > /Erik >> Maurizio > From mandy.chung at oracle.com Wed Jun 10 16:27:12 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Jun 2015 09:27:12 -0700 Subject: question on checking dependencies across modules In-Reply-To: <55783AD0.5060705@oracle.com> References: <55783AD0.5060705@oracle.com> Message-ID: <97B2EDCC-083B-402E-BEF2-5154AA79B384@oracle.com> > On Jun 10, 2015, at 6:25 AM, Maurizio Cimadamore wrote: > > Hi, > In the context of the IntelliJ project support for JDK, I have a question on the very last step of 'make images' : > > ## Starting verify-modules > Checking dependencies across JDK modules > Access verification succeeded. > > I noticed that this step is always applied, regardless of whether there was actually any change in the sources/built classes or not. Is that deliberate? This is a bit unfortunate as in our setup we depend on 'make images' to run tests, and if there's nothing to do, you will still have to wait several seconds for 'make images' to complete. This step verifies access across module boundaries and should only be needed when any change in built classes. This can be improved while this step is temporary until the module system is moving along. Erik and Magnus may be able to come up with a simple way to check if any class is recompiled; otherwise this step can be skipped. Mandy From alejandro.murillo at oracle.com Wed Jun 10 17:21:59 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Wed, 10 Jun 2015 11:21:59 -0600 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557829DC.8000405@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> Message-ID: <55787237.20802@oracle.com> On 6/10/2015 6:13 AM, Magnus Ihse Bursie wrote: > On 2015-06-10 11:58, David Holmes wrote: >> Hi Magnus, >> >> Generally looks good - a few comments/queries below. > > In general, I believe most issues you found are valid. :-) However, as > I said before in this thread, I'd like to see them resolved in the > needed follow-up patches. The source code changes in Hotspot and JDK > are inadequate to fully implement JEP-223, so these areas will need to > be rewritten anyhow. Are you okay with resolving these issues later? > >> >> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>> Here's an updated webrev, which fixes the typos that were pointed >>> out by >>> reviewers: >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>> >> >> common/autoconf/version-numbers >> >> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >> the version info? (Even if all zeroes presently.) > So that's a tricky one. :-& The question here is, I think, does it > make sense to update version-numbers when we do a security (9.0.1) or > minor (9.1.0) release? Looking historically, the version-numbers file > have not been changed for the 8u family. The only change was going > from 8 to 9 when creating the new jdk9 forest. That was what I based > my decition to only have the major number in the file. (The rest of > the version string is set by configure flags when building, in Oracle > case by the RE team.) > > If it makes sense to put the minor/security/patch numbers here, I > won't oppose it, but I guess we have until the first such release to > figure out what's best, and that likely includes discussion with RE > and possibly other consumers in the community (RedHat etc). > >> >> --- >> >> Looking at hotspot changes I can't convince myself that the new >> streamlined "version" variables will capture things like "fastdebug". >> Will that filter through via configure variables? > > The "fastdebug" label has been handled as a less valued token in the > JEP-223 process. Right now there's no mention of it at all in the > version string proposal in the JEP. As I understand it, Iris is about > to propose an amendment which will just make fastdebug be a part of > the OPT string. I'm not entirely happy with that myself, but that's > the way it's decided. So wherever you can see the OPT string, you'll > see the debug level tag. > > Currently, however, that's not how it is implemented in this patch. > Since no decision was made on this (and it's still not formally > decided), I had to pick a route to go forward. The current patch will > instead put the "fastdebug" label as part of the PRE string (that's > the reason for the pre-base and pre-debuglevel arguments to > configure). If the planned changes goes into the JEP, this'll change > to make the debuglevel tag a part of the OPT string instead. > >> --- >> >> make/*/makefiles/vm.make >> >> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from >> the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >> stand-alone hotspot build?) > The hotspot JEP-223 work initially made by Alejandro kept support for > stand-alone hotspot builds. I made additional changes on top of that, > which still tried to cater for stand-alone builds. At this very moment > I'm not sure if stand-alone hotspot builds are supposed to work or > not, but I've tried to not change the situation with this patch. > > There are two future changes coming down the pipe: One is the > additional JEP-223 work needed for Hotspot. I know Alejandro had plans > for redesigning the API between Hotspot and the JDK, so no JDK version > strings should be compiled into the JVM, but all of it extracted > during an API in runtime. That would make most (all?) of the makefile > changes in hotspot irrelevant. However, that implementation is not > even started, so it's needed for the time being. There's already an API used by Hotspot to get JDK version values. I'm investigating using that and extend it if required. yes, there is a lot stuff in the hotspot code that should be removed (mostly in the makefiles) and I'm not against making those changes now, I just think they are somewhat out of the scope of this project. And should be done as individual RFEs or as part of the upcoming hotspot makefile refactoring. Alejandro > > The second change is the build-infra hotspot makefile rewrite. When > that happens, stand-alone builds will definitely disappear, and if > Hotspot still needs make support for version strings, then the logical > choice is to use VERSION_CFLAGS. > > Ok? > >> >> --- >> >> hotspot/src/share/vm/prims/jvm.h >> jdk/src/java.base/share/native/include/jvm.h >> >> I think this comment is way out of date: >> >> /* Build number is available only for RE build (i.e. >> JDK_BUILD_NUMBER is set to bNN) >> * It will be zero for internal builds. >> */ >> >> and can be completely removed. Even if still true, mention of an "RE >> build" has no place in OpenJDK sources. > Yep, agree. Follow-up patch, right? > >> >> --- >> >> hotspot/src/share/vm/runtime/java.cpp >> >> I think a lot of the modified code is obsolete post Hotspot Express - >> which makes it hard to determine if the changes make sense. > Yep, agree. Follow-up patch, right? >> >> --- >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Please fix the alignment (3 extra spaces on modified line): >> >> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >> int) \ >> 1240 static_field(Abstract_VM_Version, _vm_security_version, >> int) \ > > I was about to say "follow-up patch", but ugly indentation really > sucks so I can fix this. Ok if I skip redoing the review for that? > >> >> --- >> >> hotspot/test/runtime/6981737/Test6981737.java >> >> This test is really only valid for the new version scheme now, so it >> should probably be rewritten - and in that case it really isn't >> testing 6981737 but should be replaced by a new test for the new >> version format. > Yep, agree. Follow-up patch, right? >> >> --- >> >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> >> This comment is nonsensical: >> >> /** >> ! * Returns the security version of the running JVM if it's 1.6 >> or newer >> * or any RE VM build. It will return 0 if it's an internal 1.5 or >> * 1.4.x build. >> * @since 1.6 >> */ >> >> as security version does not exist pre 9. Normally you should be >> adding a new method and deprecating the old one. The new one is >> @since 9. > Yep, agree. Follow-up patch, right? >> >> /** >> ! * Returns the security version of the running JDK. >> * @since 1.6 >> */ >> >> Ditto: @since 9 (but again old should be deprecated and new method >> added) >> >> 253 /** >> 254 * Returns the build number of the running JDK if it's a RE >> build >> 255 * It will return 0 if it's an internal build. >> >> As with jvm.h this seems obsolete commentary these days - not only RE >> builds define a build number. > Yep, agree. Follow-up patch, right? > > /Magnus > >> >> Thanks, >> David > -- Alejandro From peter.brunet at oracle.com Wed Jun 10 22:05:10 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 10 Jun 2015 17:05:10 -0500 Subject: RfR JDK-8078335 Message-ID: <5578B496.1080509@oracle.com> Please review this simple patch which causes jdk.accessibility to be built for all platforms, not just for Windows. I tested it on Win and Mac. http://cr.openjdk.java.net/~ptbrunet/JDK-8078335/webrev.00/ Pete From peter.brunet at oracle.com Wed Jun 10 22:33:52 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 10 Jun 2015 17:33:52 -0500 Subject: RfR JDK-8055160 In-Reply-To: <551EFF4E.1070007@oracle.com> References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> Message-ID: <5578BB50.6090708@oracle.com> Due to some other priorities it's been over 2 months since the last webrev. An update is here: http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 The changes from webrev.02 are: 1) The test was changed to not use the service provider to test the activation of the service provider. Instead a file is created when Toolkit.getDefaultToolkit activates providers and tested for existence when the test runs. 2) The copyright header in the new jdk.accessibility files were fixed. Pete On 4/3/15 3:59 PM, Pete Brunet wrote: > Due to the recent push of JDK-8076182 (Open source Java Access Bridge) > which exposed some files that were in closed the webrev needs a full > re-review. I've also made the changes requested by Mandy. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/ > > Pete > > On 3/23/15 4:41 PM, Mandy Chung wrote: >> >> >> On 3/19/2015 6:03 PM, Pete Brunet wrote: >>> A new webrev is available at >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.01/ >>> >> >> line 820-821: this comment is incorrect. >> >> line 831-838: what happens if ServiceConfigurationException thrown or >> any exception is thrown by the activate method? This should wrap >> with AWTError as I mentioned in my previous review comment. This was >> hidden with the test (see below). >> >> line 891-901: this example may not be necessary as the service loader >> documentation should cover it. >> >>> >>> >>> The changes to the tests are: >>> - added an unused provider >>> - added a test activating two providers >>> >>> Mandy, Regarding the last bullet I'm not sure I resolved your >>> comment, "For the test, since you support multiple providers, >>> perhaps good to add one more test case to activate two providers and >>> load two providers but only one is activated." If not, please let >>> me know. >> >> Almost. For Foo, Bar providers, their activate method throwing >> RuntimeException actually stops loading the second provider. The >> activate method could perhaps update some static field defined in the >> Load class if it's called (perhaps adding its name) so that you can >> tell whether the expected providers are activated. UnusedProvider >> throwing RuntimeException is good since you don't expect it's activated. >> >> Otherwise, looks good. >> >> Mandy > From omajid at redhat.com Wed Jun 10 22:36:09 2015 From: omajid at redhat.com (Omair Majid) Date: Wed, 10 Jun 2015 18:36:09 -0400 Subject: RFR: 8087156: SetupNativeCompilation ignores CFLAGS_release for cpp files Message-ID: <20150610223609.GC19138@redhat.com> Hi, I discovered a bug in SetupNativeCompilation that results in some C++ code being built with wrong CXXFLAGS. Bug: https://bugs.openjdk.java.net/browse/JDK-8087156 Webrev: http://cr.openjdk.java.net/~omajid/webrevs/8087156-setupnativecompilation/00/ It turns out that debugging flags are automatically added to the CXXFLAGS which makes the code that copies over CFLAGS to CXXFLAGS if CXXFLAGS is empty fail. This causes the desired CXXFLAGS to not be set at all. Depending on the code, these CXXFLAGS can include -DPRODUCT. In other words, some JDK code is currently being built as if in non-product mode. An example of this is libunpack: jdk/make/lib/Lib-jdk.pack200.gmk: $(eval $(call SetupNativeCompilation,BUILD_LIBUNPACK, \ ... snip ... CFLAGS_release := -DPRODUCT, \ ... snip ... The same issue exists in OpenJDK 8. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From peter.brunet at oracle.com Wed Jun 10 22:39:15 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 10 Jun 2015 17:39:15 -0500 Subject: RfR JDK-8055160 In-Reply-To: <5578BB50.6090708@oracle.com> References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> Message-ID: <5578BC93.80107@oracle.com> Note that I need to remove the import of java.io.PrintWriter in java.awt.Toolkit.java On 6/10/15 5:33 PM, Pete Brunet wrote: > Due to some other priorities it's been over 2 months since the last > webrev. An update is here: > http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 > > The changes from webrev.02 are: > > 1) The test was changed to not use the service provider to test the > activation of the service provider. Instead a file is created when > Toolkit.getDefaultToolkit activates providers and tested for existence > when the test runs. > > 2) The copyright header in the new jdk.accessibility files were fixed. > > Pete > > On 4/3/15 3:59 PM, Pete Brunet wrote: >> Due to the recent push of JDK-8076182 (Open source Java Access >> Bridge) which exposed some files that were in closed the webrev needs >> a full re-review. I've also made the changes requested by Mandy. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/ >> >> Pete >> >> On 3/23/15 4:41 PM, Mandy Chung wrote: >>> >>> >>> On 3/19/2015 6:03 PM, Pete Brunet wrote: >>>> A new webrev is available at >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.01/ >>>> >>> >>> line 820-821: this comment is incorrect. >>> >>> line 831-838: what happens if ServiceConfigurationException thrown >>> or any exception is thrown by the activate method? This should wrap >>> with AWTError as I mentioned in my previous review comment. This >>> was hidden with the test (see below). >>> >>> line 891-901: this example may not be necessary as the service >>> loader documentation should cover it. >>> >>>> >>>> >>>> The changes to the tests are: >>>> - added an unused provider >>>> - added a test activating two providers >>>> >>>> Mandy, Regarding the last bullet I'm not sure I resolved your >>>> comment, "For the test, since you support multiple providers, >>>> perhaps good to add one more test case to activate two providers >>>> and load two providers but only one is activated." If not, please >>>> let me know. >>> >>> Almost. For Foo, Bar providers, their activate method throwing >>> RuntimeException actually stops loading the second provider. The >>> activate method could perhaps update some static field defined in >>> the Load class if it's called (perhaps adding its name) so that you >>> can tell whether the expected providers are activated. >>> UnusedProvider throwing RuntimeException is good since you don't >>> expect it's activated. >>> >>> Otherwise, looks good. >>> >>> Mandy >> > From mandy.chung at oracle.com Wed Jun 10 23:08:18 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Jun 2015 16:08:18 -0700 Subject: RfR JDK-8055160 In-Reply-To: <5578BB50.6090708@oracle.com> References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> Message-ID: <1E363A12-FF3D-461E-B356-F210608BB3B7@oracle.com> Just a quick check, jdk.accessibility is only linked in windows image at the moment. It is a bug. Are you going to fix that in this changeset? I think you have to verify this change in windows as well as other platforms. Mandy > On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote: > > Due to some other priorities it's been over 2 months since the last webrev. An update is here: > http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 > > The changes from webrev.02 are: > > 1) The test was changed to not use the service provider to test the activation of the service provider. Instead a file is created when Toolkit.getDefaultToolkit activates providers and tested for existence when the test runs. > > 2) The copyright header in the new jdk.accessibility files were fixed. > > Pete > > On 4/3/15 3:59 PM, Pete Brunet wrote: >> Due to the recent push of JDK-8076182 (Open source Java Access Bridge) which exposed some files that were in closed the webrev needs a full re-review. I've also made the changes requested by Mandy. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/ >> >> Pete >> >> On 3/23/15 4:41 PM, Mandy Chung wrote: >>> >>> >>> On 3/19/2015 6:03 PM, Pete Brunet wrote: >>>> A new webrev is available at >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.01/ >>>> >>> >>> line 820-821: this comment is incorrect. >>> >>> line 831-838: what happens if ServiceConfigurationException thrown or any exception is thrown by the activate method? This should wrap with AWTError as I mentioned in my previous review comment. This was hidden with the test (see below). >>> >>> line 891-901: this example may not be necessary as the service loader documentation should cover it. >>> >>>> >>>> >>>> The changes to the tests are: >>>> - added an unused provider >>>> - added a test activating two providers >>>> >>>> Mandy, Regarding the last bullet I'm not sure I resolved your comment, "For the test, since you support multiple providers, perhaps good to add one more test case to activate two providers and load two providers but only one is activated." If not, please let me know. >>> >>> Almost. For Foo, Bar providers, their activate method throwing RuntimeException actually stops loading the second provider. The activate method could perhaps update some static field defined in the Load class if it's called (perhaps adding its name) so that you can tell whether the expected providers are activated. UnusedProvider throwing RuntimeException is good since you don't expect it's activated. >>> >>> Otherwise, looks good. >>> >>> Mandy >> > From mandy.chung at oracle.com Wed Jun 10 23:29:33 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Jun 2015 16:29:33 -0700 Subject: RfR JDK-8055160 In-Reply-To: <5578BB50.6090708@oracle.com> References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> Message-ID: > On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote: > > Due to some other priorities it's been over 2 months since the last webrev. An update is here: > http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 BarProvider.java You can use try-with-resource try (PrintWriter writer = new PrintWriter("BarProvider.txt?)) { writer.println("BarProvider-activated?); } catch (IOException e) { throw new UncheckedException(e); } That will close the writer. I think you should rethow IOException instead of swallowing it. Same comment to other provider implementation. Load.java The test should clean up all files before starting loading the providers since someone may run the test standalone multiple times on the same directory. Otherwise looks good to me. make/Images.gmk needs fixing as I mentioned earlier. Mandy From maurizio.cimadamore at oracle.com Wed Jun 10 23:38:16 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Thu, 11 Jun 2015 00:38:16 +0100 Subject: question on checking dependencies across modules In-Reply-To: <97B2EDCC-083B-402E-BEF2-5154AA79B384@oracle.com> References: <55783AD0.5060705@oracle.com> <97B2EDCC-083B-402E-BEF2-5154AA79B384@oracle.com> Message-ID: <5578CA68.90800@oracle.com> On 10/06/15 17:27, Mandy Chung wrote: >> On Jun 10, 2015, at 6:25 AM, Maurizio Cimadamore wrote: >> >> Hi, >> In the context of the IntelliJ project support for JDK, I have a question on the very last step of 'make images' : >> >> ## Starting verify-modules >> Checking dependencies across JDK modules >> Access verification succeeded. >> >> I noticed that this step is always applied, regardless of whether there was actually any change in the sources/built classes or not. Is that deliberate? This is a bit unfortunate as in our setup we depend on 'make images' to run tests, and if there's nothing to do, you will still have to wait several seconds for 'make images' to complete. > This step verifies access across module boundaries and should only be needed when any change in built classes. This can be improved while this step is temporary until the module system is moving along. Erik and Magnus may be able to come up with a simple way to check if any class is recompiled; otherwise this step can be skipped. Right - this is what I was trying to ask - i.e. if there was any weird reason as to why this step was necessary even w/o any change in any source. It seems like the current behavior is mostly accidental and, coupled with the fact that (i) this is going away soon and (ii) there are workarounds (make jimages) - it should best be left as it is now? Now, 'jimages' seems to be working fine for my needs - what is the feeling about this target moving forward? Is it something we can rely upon, or is 'jimages' also going away/replaced by something else (in which case using 'images' would be a more stable choice) ? Maurizio > Mandy > From peter.brunet at oracle.com Wed Jun 10 23:54:31 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 10 Jun 2015 18:54:31 -0500 Subject: RfR JDK-8055160 In-Reply-To: <1E363A12-FF3D-461E-B356-F210608BB3B7@oracle.com> References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> <1E363A12-FF3D-461E-B356-F210608BB3B7@oracle.com> Message-ID: <5578CE37.8090400@oracle.com> Hi Mandy, That's fixed in the JDK-8078335 patch I submitted earlier in the day to build-dev as a RfR. I tested that on Win and Mac. http://cr.openjdk.java.net/~ptbrunet/JDK-8078335/webrev.00/ Pete On 6/10/15 6:08 PM, Mandy Chung wrote: > Just a quick check, jdk.accessibility is only linked in windows image at the moment. It is a bug. Are you going to fix that in this changeset? I think you have to verify this change in windows as well as other platforms. > > Mandy > > >> On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote: >> >> Due to some other priorities it's been over 2 months since the last webrev. An update is here: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 >> >> The changes from webrev.02 are: >> >> 1) The test was changed to not use the service provider to test the activation of the service provider. Instead a file is created when Toolkit.getDefaultToolkit activates providers and tested for existence when the test runs. >> >> 2) The copyright header in the new jdk.accessibility files were fixed. >> >> Pete >> >> On 4/3/15 3:59 PM, Pete Brunet wrote: >>> Due to the recent push of JDK-8076182 (Open source Java Access Bridge) which exposed some files that were in closed the webrev needs a full re-review. I've also made the changes requested by Mandy. >>> >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/ >>> >>> Pete >>> >>> On 3/23/15 4:41 PM, Mandy Chung wrote: >>>> >>>> On 3/19/2015 6:03 PM, Pete Brunet wrote: >>>>> A new webrev is available at >>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.01/ >>>>> >>>> line 820-821: this comment is incorrect. >>>> >>>> line 831-838: what happens if ServiceConfigurationException thrown or any exception is thrown by the activate method? This should wrap with AWTError as I mentioned in my previous review comment. This was hidden with the test (see below). >>>> >>>> line 891-901: this example may not be necessary as the service loader documentation should cover it. >>>> >>>>> >>>>> The changes to the tests are: >>>>> - added an unused provider >>>>> - added a test activating two providers >>>>> >>>>> Mandy, Regarding the last bullet I'm not sure I resolved your comment, "For the test, since you support multiple providers, perhaps good to add one more test case to activate two providers and load two providers but only one is activated." If not, please let me know. >>>> Almost. For Foo, Bar providers, their activate method throwing RuntimeException actually stops loading the second provider. The activate method could perhaps update some static field defined in the Load class if it's called (perhaps adding its name) so that you can tell whether the expected providers are activated. UnusedProvider throwing RuntimeException is good since you don't expect it's activated. >>>> >>>> Otherwise, looks good. >>>> >>>> Mandy From mandy.chung at oracle.com Thu Jun 11 01:39:45 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Jun 2015 18:39:45 -0700 Subject: RfR JDK-8055160 In-Reply-To: <5578CE37.8090400@oracle.com> References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> <1E363A12-FF3D-461E-B356-F210608BB3B7@oracle.com> <5578CE37.8090400@oracle.com> Message-ID: <4303BD71-B5C6-46BA-A685-734FFA089ACD@oracle.com> > On Jun 10, 2015, at 4:54 PM, Pete Brunet wrote: > > Hi Mandy, That's fixed in the JDK-8078335 patch I submitted earlier in > the day to build-dev as a RfR. I tested that on Win and Mac. > > http://cr.openjdk.java.net/~ptbrunet/JDK-8078335/webrev.00/ Looks good to me. Mandy > > Pete > > On 6/10/15 6:08 PM, Mandy Chung wrote: >> Just a quick check, jdk.accessibility is only linked in windows image at the moment. It is a bug. Are you going to fix that in this changeset? I think you have to verify this change in windows as well as other platforms. >> >> Mandy >> >> >>> On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote: >>> >>> Due to some other priorities it's been over 2 months since the last webrev. An update is here: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 >>> >>> The changes from webrev.02 are: >>> >>> 1) The test was changed to not use the service provider to test the activation of the service provider. Instead a file is created when Toolkit.getDefaultToolkit activates providers and tested for existence when the test runs. >>> >>> 2) The copyright header in the new jdk.accessibility files were fixed. >>> >>> Pete >>> >>> On 4/3/15 3:59 PM, Pete Brunet wrote: >>>> Due to the recent push of JDK-8076182 (Open source Java Access Bridge) which exposed some files that were in closed the webrev needs a full re-review. I've also made the changes requested by Mandy. >>>> >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/ >>>> >>>> Pete >>>> >>>> On 3/23/15 4:41 PM, Mandy Chung wrote: >>>>> >>>>> On 3/19/2015 6:03 PM, Pete Brunet wrote: >>>>>> A new webrev is available at >>>>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.01/ >>>>>> >>>>> line 820-821: this comment is incorrect. >>>>> >>>>> line 831-838: what happens if ServiceConfigurationException thrown or any exception is thrown by the activate method? This should wrap with AWTError as I mentioned in my previous review comment. This was hidden with the test (see below). >>>>> >>>>> line 891-901: this example may not be necessary as the service loader documentation should cover it. >>>>> >>>>>> >>>>>> The changes to the tests are: >>>>>> - added an unused provider >>>>>> - added a test activating two providers >>>>>> >>>>>> Mandy, Regarding the last bullet I'm not sure I resolved your comment, "For the test, since you support multiple providers, perhaps good to add one more test case to activate two providers and load two providers but only one is activated." If not, please let me know. >>>>> Almost. For Foo, Bar providers, their activate method throwing RuntimeException actually stops loading the second provider. The activate method could perhaps update some static field defined in the Load class if it's called (perhaps adding its name) so that you can tell whether the expected providers are activated. UnusedProvider throwing RuntimeException is good since you don't expect it's activated. >>>>> >>>>> Otherwise, looks good. >>>>> >>>>> Mandy > From david.holmes at oracle.com Thu Jun 11 04:52:53 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jun 2015 14:52:53 +1000 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <557829DC.8000405@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> Message-ID: <55791425.8070709@oracle.com> Hi Magnus, On 10/06/2015 10:13 PM, Magnus Ihse Bursie wrote: > On 2015-06-10 11:58, David Holmes wrote: >> Hi Magnus, >> >> Generally looks good - a few comments/queries below. > > In general, I believe most issues you found are valid. :-) However, as I > said before in this thread, I'd like to see them resolved in the needed > follow-up patches. The source code changes in Hotspot and JDK are > inadequate to fully implement JEP-223, so these areas will need to be > rewritten anyhow. Are you okay with resolving these issues later? Given this is going to a staging repo I'm okay with deferring things - I just have a concern whether such things may be overlooked given that the integration with the staging repo will not be undergoing a final review. I would prefer to see the Version.java.template doc comments corrected, even if the issue of whether to add and deprecate is deferred, but again as this is to a staging area I can let it slide for now. I saw the fix to hotspot/src/share/vm/runtime/vmStructs.cpp. Thanks, David >> >> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>> Here's an updated webrev, which fixes the typos that were pointed out by >>> reviewers: >>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>> >> >> common/autoconf/version-numbers >> >> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >> the version info? (Even if all zeroes presently.) > So that's a tricky one. :-& The question here is, I think, does it make > sense to update version-numbers when we do a security (9.0.1) or minor > (9.1.0) release? Looking historically, the version-numbers file have not > been changed for the 8u family. The only change was going from 8 to 9 > when creating the new jdk9 forest. That was what I based my decition to > only have the major number in the file. (The rest of the version string > is set by configure flags when building, in Oracle case by the RE team.) > > If it makes sense to put the minor/security/patch numbers here, I won't > oppose it, but I guess we have until the first such release to figure > out what's best, and that likely includes discussion with RE and > possibly other consumers in the community (RedHat etc). > >> >> --- >> >> Looking at hotspot changes I can't convince myself that the new >> streamlined "version" variables will capture things like "fastdebug". >> Will that filter through via configure variables? > > The "fastdebug" label has been handled as a less valued token in the > JEP-223 process. Right now there's no mention of it at all in the > version string proposal in the JEP. As I understand it, Iris is about to > propose an amendment which will just make fastdebug be a part of the OPT > string. I'm not entirely happy with that myself, but that's the way it's > decided. So wherever you can see the OPT string, you'll see the debug > level tag. > > Currently, however, that's not how it is implemented in this patch. > Since no decision was made on this (and it's still not formally > decided), I had to pick a route to go forward. The current patch will > instead put the "fastdebug" label as part of the PRE string (that's the > reason for the pre-base and pre-debuglevel arguments to configure). If > the planned changes goes into the JEP, this'll change to make the > debuglevel tag a part of the OPT string instead. > >> --- >> >> make/*/makefiles/vm.make >> >> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the >> VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >> stand-alone hotspot build?) > The hotspot JEP-223 work initially made by Alejandro kept support for > stand-alone hotspot builds. I made additional changes on top of that, > which still tried to cater for stand-alone builds. At this very moment > I'm not sure if stand-alone hotspot builds are supposed to work or not, > but I've tried to not change the situation with this patch. > > There are two future changes coming down the pipe: One is the additional > JEP-223 work needed for Hotspot. I know Alejandro had plans for > redesigning the API between Hotspot and the JDK, so no JDK version > strings should be compiled into the JVM, but all of it extracted during > an API in runtime. That would make most (all?) of the makefile changes > in hotspot irrelevant. However, that implementation is not even started, > so it's needed for the time being. > > The second change is the build-infra hotspot makefile rewrite. When that > happens, stand-alone builds will definitely disappear, and if Hotspot > still needs make support for version strings, then the logical choice is > to use VERSION_CFLAGS. > > Ok? > >> >> --- >> >> hotspot/src/share/vm/prims/jvm.h >> jdk/src/java.base/share/native/include/jvm.h >> >> I think this comment is way out of date: >> >> /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER >> is set to bNN) >> * It will be zero for internal builds. >> */ >> >> and can be completely removed. Even if still true, mention of an "RE >> build" has no place in OpenJDK sources. > Yep, agree. Follow-up patch, right? > >> >> --- >> >> hotspot/src/share/vm/runtime/java.cpp >> >> I think a lot of the modified code is obsolete post Hotspot Express - >> which makes it hard to determine if the changes make sense. > Yep, agree. Follow-up patch, right? >> >> --- >> >> hotspot/src/share/vm/runtime/vmStructs.cpp >> >> Please fix the alignment (3 extra spaces on modified line): >> >> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >> int) \ >> 1240 static_field(Abstract_VM_Version, >> _vm_security_version, int) \ > > I was about to say "follow-up patch", but ugly indentation really sucks > so I can fix this. Ok if I skip redoing the review for that? > >> >> --- >> >> hotspot/test/runtime/6981737/Test6981737.java >> >> This test is really only valid for the new version scheme now, so it >> should probably be rewritten - and in that case it really isn't >> testing 6981737 but should be replaced by a new test for the new >> version format. > Yep, agree. Follow-up patch, right? >> >> --- >> >> jdk/src/java.base/share/classes/sun/misc/Version.java.template >> >> This comment is nonsensical: >> >> /** >> ! * Returns the security version of the running JVM if it's 1.6 >> or newer >> * or any RE VM build. It will return 0 if it's an internal 1.5 or >> * 1.4.x build. >> * @since 1.6 >> */ >> >> as security version does not exist pre 9. Normally you should be >> adding a new method and deprecating the old one. The new one is @since 9. > Yep, agree. Follow-up patch, right? >> >> /** >> ! * Returns the security version of the running JDK. >> * @since 1.6 >> */ >> >> Ditto: @since 9 (but again old should be deprecated and new method added) >> >> 253 /** >> 254 * Returns the build number of the running JDK if it's a RE >> build >> 255 * It will return 0 if it's an internal build. >> >> As with jvm.h this seems obsolete commentary these days - not only RE >> builds define a build number. > Yep, agree. Follow-up patch, right? > > /Magnus > >> >> Thanks, >> David > From david.holmes at oracle.com Thu Jun 11 05:37:41 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Jun 2015 15:37:41 +1000 Subject: RfR JDK-8078335 In-Reply-To: <5578B496.1080509@oracle.com> References: <5578B496.1080509@oracle.com> Message-ID: <55791EA5.3050207@oracle.com> On 11/06/2015 8:05 AM, Pete Brunet wrote: > Please review this simple patch which causes jdk.accessibility to be > built for all platforms, not just for Windows. I tested it on Win and Mac. > http://cr.openjdk.java.net/~ptbrunet/JDK-8078335/webrev.00/ Looks okay but please ensure you test on all platforms (via JPRT) before or when pushing. Thanks, David > Pete > From erik.joelsson at oracle.com Thu Jun 11 06:51:00 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 08:51:00 +0200 Subject: RFR: 8087156: SetupNativeCompilation ignores CFLAGS_release for cpp files In-Reply-To: <20150610223609.GC19138@redhat.com> References: <20150610223609.GC19138@redhat.com> Message-ID: <55792FD4.5030907@oracle.com> Hello Omair, This looks good to me, thanks for catching it! /Erik On 2015-06-11 00:36, Omair Majid wrote: > Hi, > > I discovered a bug in SetupNativeCompilation that results in some C++ > code being built with wrong CXXFLAGS. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087156 > Webrev: http://cr.openjdk.java.net/~omajid/webrevs/8087156-setupnativecompilation/00/ > > It turns out that debugging flags are automatically added to the > CXXFLAGS which makes the code that copies over CFLAGS to CXXFLAGS if > CXXFLAGS is empty fail. This causes the desired CXXFLAGS to not be set > at all. > > Depending on the code, these CXXFLAGS can include -DPRODUCT. In other > words, some JDK code is currently being built as if in non-product mode. > An example of this is libunpack: > > jdk/make/lib/Lib-jdk.pack200.gmk: > > $(eval $(call SetupNativeCompilation,BUILD_LIBUNPACK, \ > ... snip ... > CFLAGS_release := -DPRODUCT, \ > ... snip ... > > The same issue exists in OpenJDK 8. > > Thanks, > Omair > From erik.joelsson at oracle.com Thu Jun 11 06:53:54 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 08:53:54 +0200 Subject: question on checking dependencies across modules In-Reply-To: <5578CA68.90800@oracle.com> References: <55783AD0.5060705@oracle.com> <97B2EDCC-083B-402E-BEF2-5154AA79B384@oracle.com> <5578CA68.90800@oracle.com> Message-ID: <55793082.7080807@oracle.com> On 2015-06-11 01:38, Maurizio Cimadamore wrote: > > > On 10/06/15 17:27, Mandy Chung wrote: >>> On Jun 10, 2015, at 6:25 AM, Maurizio Cimadamore >>> wrote: >>> >>> Hi, >>> In the context of the IntelliJ project support for JDK, I have a >>> question on the very last step of 'make images' : >>> >>> ## Starting verify-modules >>> Checking dependencies across JDK modules >>> Access verification succeeded. >>> >>> I noticed that this step is always applied, regardless of whether >>> there was actually any change in the sources/built classes or not. >>> Is that deliberate? This is a bit unfortunate as in our setup we >>> depend on 'make images' to run tests, and if there's nothing to do, >>> you will still have to wait several seconds for 'make images' to >>> complete. >> This step verifies access across module boundaries and should only be >> needed when any change in built classes. This can be improved >> while this step is temporary until the module system is moving >> along. Erik and Magnus may be able to come up with a simple way to >> check if any class is recompiled; otherwise this step can be skipped. > Right - this is what I was trying to ask - i.e. if there was any weird > reason as to why this step was necessary even w/o any change in any > source. It seems like the current behavior is mostly accidental and, > coupled with the fact that (i) this is going away soon and (ii) there > are workarounds (make jimages) - it should best be left as it is now? > I might look into fixing dependency checking for the dependency checking, can't promise it though. > Now, 'jimages' seems to be working fine for my needs - what is the > feeling about this target moving forward? Is it something we can rely > upon, or is 'jimages' also going away/replaced by something else (in > which case using 'images' would be a more stable choice) ? > jimages should not be considered a stable choice, I already don't like the name. Expect it to change at some point. /Erik > Maurizio >> Mandy >> > From erik.joelsson at oracle.com Thu Jun 11 06:56:16 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 08:56:16 +0200 Subject: RfR JDK-8078335 In-Reply-To: <5578B496.1080509@oracle.com> References: <5578B496.1080509@oracle.com> Message-ID: <55793110.70105@oracle.com> Change looks fine, but as David pointed out, please run through jprt. /Erik On 2015-06-11 00:05, Pete Brunet wrote: > Please review this simple patch which causes jdk.accessibility to be > built for all platforms, not just for Windows. I tested it on Win and Mac. > http://cr.openjdk.java.net/~ptbrunet/JDK-8078335/webrev.00/ > > Pete > From erik.joelsson at oracle.com Thu Jun 11 06:58:41 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 08:58:41 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55783F49.6030906@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <55783F49.6030906@oracle.com> Message-ID: <557931A1.6030406@oracle.com> Looks good. /Erik On 2015-06-10 15:44, Magnus Ihse Bursie wrote: > On 2015-06-09 01:31, Daniel D. Daugherty wrote: >> > >> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.01 >> >> >> General comment: Not all copyright years were updated. > > I realize I missed that part of the review. :-( > > I have now updated the copyright years. Here's a delta review: > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch-delta-02/webrev.01/ > > > Here's the complete review once again: > > http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.03 > > > Hopefully this is now the final version to be pushed to verona, and > that any additional problems can be resolved with follow-up patches. > > /Magnus From Alan.Bateman at oracle.com Thu Jun 11 09:17:05 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 11 Jun 2015 10:17:05 +0100 Subject: sjavac always compiled? In-Reply-To: <20150610092152.GB1107@e6430> References: <5577ECE7.4060708@oracle.com> <5577EE9E.2030503@oracle.com> <5577F014.8030800@oracle.com> <20150610090218.GA1107@e6430> <20150610092152.GB1107@e6430> Message-ID: <55795211.8090400@oracle.com> On 10/06/2015 10:21, Andreas Lundblad wrote: > On Wed, Jun 10, 2015 at 11:02:19AM +0200, Andreas Lundblad wrote: >> What's the approperiate procedure here? Should I submit a patch that adds the type arguments to avoid forcing people to update their boot jdks? > I have now pushed a patch that adds the type arguments. > > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/5021d414632a > Thanks for that. I should probably have tested with 8u40 as a boot JDK before bringing up this issue. -Alan From erik.joelsson at oracle.com Thu Jun 11 10:46:28 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 12:46:28 +0200 Subject: RFR: JDK-8087193: Support building with devkits on Macosx Message-ID: <55796704.3030901@oracle.com> Hello, Please review this minor tweak to configure which enables the use of a portable devkit on Macosx. Also included is the script used to generate the devkit. The plan is use this internally on our build servers to ease installation and setup of our machines. Bug: https://bugs.openjdk.java.net/browse/JDK-8087193 Webrev: http://cr.openjdk.java.net/~erikj/8087193/webrev.01/ /Erik From erik.joelsson at oracle.com Thu Jun 11 10:53:33 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 12:53:33 +0200 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx Message-ID: <557968AD.2040705@oracle.com> Hello, Please review this small makefile tweak. When using a devkit to build hotspot on Macosx, the dtrace command gets confused and tries to use the wrong preprocessor. I've fixed this by splitting out the running of the preprocessor to a separate call. I've verified by comparing the generated header files with and without the patch. Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 Patch inline: diff -r 11af3990d56c make/bsd/makefiles/dtrace.make --- a/make/bsd/makefiles/dtrace.make +++ b/make/bsd/makefiles/dtrace.make @@ -263,14 +263,19 @@ $(DtraceOutDir): mkdir $(DtraceOutDir) +# When building using a devkit, dtrace cannot find the correct preprocessor so +# we run it explicitly before runing dtrace. $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | $(DtraceOutDir) - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s $(DTRACE_COMMON_SRCDIR)/hotspot.d + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d | $(DtraceOutDir) - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot_jni.d $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | $(DtraceOutDir) - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s $(DTRACE_COMMON_SRCDIR)/hs_private.d + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d dtrace_gen_headers: $(DtraceOutDir)/hotspot.h $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h /Erik From erik.joelsson at oracle.com Thu Jun 11 11:14:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 13:14:21 +0200 Subject: RFR: JDK-8087193: Support building with devkits on Macosx In-Reply-To: <55796704.3030901@oracle.com> References: <55796704.3030901@oracle.com> Message-ID: <55796D8D.8000703@oracle.com> I forgot to motivate the change. Configure runs config.guess to figure out what kind of machine it's running on. That file in turn uses the C preprocessor to figure out if it's 32 or 64 bit. If we don't setup devkit before running config.guess, the preprocessor might not be available and configure will think the mac is a 32 bit machine. /Erik On 2015-06-11 12:46, Erik Joelsson wrote: > Hello, > > Please review this minor tweak to configure which enables the use of a > portable devkit on Macosx. Also included is the script used to > generate the devkit. The plan is use this internally on our build > servers to ease installation and setup of our machines. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087193 > Webrev: http://cr.openjdk.java.net/~erikj/8087193/webrev.01/ > > /Erik From magnus.ihse.bursie at oracle.com Thu Jun 11 12:14:59 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 11 Jun 2015 14:14:59 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <55791425.8070709@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> <5576E81B.8050703@oracle.com> <5576EF94.3010500@oracle.com> <55780A33.1010302@oracle.com> <557829DC.8000405@oracle.com> <55791425.8070709@oracle.com> Message-ID: <55797BC3.9080202@oracle.com> On 2015-06-11 06:52, David Holmes wrote: > Hi Magnus, > > On 10/06/2015 10:13 PM, Magnus Ihse Bursie wrote: >> On 2015-06-10 11:58, David Holmes wrote: >>> Hi Magnus, >>> >>> Generally looks good - a few comments/queries below. >> >> In general, I believe most issues you found are valid. :-) However, as I >> said before in this thread, I'd like to see them resolved in the needed >> follow-up patches. The source code changes in Hotspot and JDK are >> inadequate to fully implement JEP-223, so these areas will need to be >> rewritten anyhow. Are you okay with resolving these issues later? > > Given this is going to a staging repo I'm okay with deferring things - > I just have a concern whether such things may be overlooked given that > the integration with the staging repo will not be undergoing a final > review. I agree completely with your concern. I have summarized the issues that were raised but not addressed during this review, and created JBS bugs, one per component. I will do my best to make sure that fixing them does not get lost from the Verona project agenda. The three bugs are: https://bugs.openjdk.java.net/browse/JDK-8087202 https://bugs.openjdk.java.net/browse/JDK-8087203 https://bugs.openjdk.java.net/browse/JDK-8087205 Here's the core content of them. If I have missed something, please add it to the bug reports: HOTSPOT: Alan Bateman: Will the update_version and special_update_version fields eventually be dropped from the jvm_version_info structure? The webrev shows a change to this comment in jvm.h: "Third, this file contains various I/O and network operations needed by the standard Java I/O and network APIs." I think this comment can be removed because those JVM_* functions were removed some time ago. Daniel D. Daugherty: General comment: It looks like support for the 'patch' value is not completely implemented through all the Makefiles. I didn't audit for this, but it's just my impression. hotspot/src/share/vm/runtime/java.cpp L661: void JDK_Version::fully_initialize( L662: uint8_t major, uint8_t minor, uint8_t security, uint8_t update) { L663: // This is only called when current is less than 1.6 and we've gotten Since you're ripping out vestigial version support, I think this function can go away since this is version 9 and newer. Don't really know for sure, but based on that comment... hotspot/src/share/vm/runtime/vm_version.cpp L84: void Abstract_VM_Version::initialize() { L85: // FIXME: Initialization can probably be removed now. I agree, but that would entail also removing the _initialized and the uses of it... Follow on bug fix? David Holmes: make/*/makefiles/vm.make Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a stand-alone hotspot build?) hotspot/src/share/vm/prims/jvm.h I think this comment is way out of date: /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER is set to bNN) * It will be zero for internal builds. */ and can be completely removed. Even if still true, mention of an "RE build" has no place in OpenJDK sources. hotspot/src/share/vm/runtime/java.cpp I think a lot of the modified code is obsolete post Hotspot Express - which makes it hard to determine if the changes make sense. hotspot/test/runtime/6981737/Test6981737.java This test is really only valid for the new version scheme now, so it should probably be rewritten - and in that case it really isn't testing 6981737 but should be replaced by a new test for the new version format. JDK: Alan Bateman: Version.java.template - the comment in jvmSecurityVersion() still talks about 1.6 and newer. Can this be replaced to just say that it returns the security version? Daniel D. Daugherty: jdk/src/java.base/share/classes/sun/misc/Version.java.template L149: * Returns the security version of the running JVM if it's 1.6 or newer This JavaDoc update is wrong, but it might not be important if sun.misc.Version class is going away. David Holmes: jdk/src/java.base/share/classes/sun/misc/Version.java.template This comment is nonsensical: /** ! * Returns the security version of the running JVM if it's 1.6 or newer * or any RE VM build. It will return 0 if it's an internal 1.5 or * 1.4.x build. * @since 1.6 */ as security version does not exist pre 9. Normally you should be adding a new method and deprecating the old one. The new one is @since 9. /** ! * Returns the security version of the running JDK. * @since 1.6 */ Ditto: @since 9 (but again old should be deprecated and new method added) 253 /** 254 * Returns the build number of the running JDK if it's a RE build 255 * It will return 0 if it's an internal build. As with jvm.h this seems obsolete commentary these days - not only RE builds define a build number. LANGTOOLS: Daniel D. Daugherty: langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java old L171: case "1.9": new L171: case "9": Should this logic support both versions? Will dropping "1.9" here prevent a pre-version changeset JVM from being dropped into a JDK for triage purposes? Granted we don't often triage 'javac' with different JVMs, but... Jan Lahoda: +1 on keeping both "1.9" and "9" here. javac can be used independently on the rest of JDK to some extent, so support for running it on older builds of JDK 9 seems reasonable to me. (I wonder if current JDK 9 javac should be prepared for the new version scheme in advance.) /Magnus > > I would prefer to see the Version.java.template doc comments > corrected, even if the issue of whether to add and deprecate is > deferred, but again as this is to a staging area I can let it slide > for now. > > I saw the fix to hotspot/src/share/vm/runtime/vmStructs.cpp. > > Thanks, > David > >>> >>> On 9/06/2015 11:52 PM, Magnus Ihse Bursie wrote: >>>> Here's an updated webrev, which fixes the typos that were pointed >>>> out by >>>> reviewers: >>>> http://cr.openjdk.java.net/~ihse/JDK-8085822-JEP-223-initial-patch/webrev.02/ >>>> >>>> >>> >>> common/autoconf/version-numbers >>> >>> Shouldn't there be a DEFAULT_VERSION_XXX for each of the XXX parts of >>> the version info? (Even if all zeroes presently.) >> So that's a tricky one. :-& The question here is, I think, does it make >> sense to update version-numbers when we do a security (9.0.1) or minor >> (9.1.0) release? Looking historically, the version-numbers file have not >> been changed for the 8u family. The only change was going from 8 to 9 >> when creating the new jdk9 forest. That was what I based my decition to >> only have the major number in the file. (The rest of the version string >> is set by configure flags when building, in Oracle case by the RE team.) >> >> If it makes sense to put the minor/security/patch numbers here, I won't >> oppose it, but I guess we have until the first such release to figure >> out what's best, and that likely includes discussion with RE and >> possibly other consumers in the community (RedHat etc). >> >>> >>> --- >>> >>> Looking at hotspot changes I can't convince myself that the new >>> streamlined "version" variables will capture things like "fastdebug". >>> Will that filter through via configure variables? >> >> The "fastdebug" label has been handled as a less valued token in the >> JEP-223 process. Right now there's no mention of it at all in the >> version string proposal in the JEP. As I understand it, Iris is about to >> propose an amendment which will just make fastdebug be a part of the OPT >> string. I'm not entirely happy with that myself, but that's the way it's >> decided. So wherever you can see the OPT string, you'll see the debug >> level tag. >> >> Currently, however, that's not how it is implemented in this patch. >> Since no decision was made on this (and it's still not formally >> decided), I had to pick a route to go forward. The current patch will >> instead put the "fastdebug" label as part of the PRE string (that's the >> reason for the pre-base and pre-debuglevel arguments to configure). If >> the planned changes goes into the JEP, this'll change to make the >> debuglevel tag a part of the OPT string instead. >> >>> --- >>> >>> make/*/makefiles/vm.make >>> >>> Shouldn't the -DVERSION_XX=$(VERSION_XX) definitions be taken from the >>> VERSION_CFLAGS in spec.gmk? (Or are you still allowing for a >>> stand-alone hotspot build?) >> The hotspot JEP-223 work initially made by Alejandro kept support for >> stand-alone hotspot builds. I made additional changes on top of that, >> which still tried to cater for stand-alone builds. At this very moment >> I'm not sure if stand-alone hotspot builds are supposed to work or not, >> but I've tried to not change the situation with this patch. >> >> There are two future changes coming down the pipe: One is the additional >> JEP-223 work needed for Hotspot. I know Alejandro had plans for >> redesigning the API between Hotspot and the JDK, so no JDK version >> strings should be compiled into the JVM, but all of it extracted during >> an API in runtime. That would make most (all?) of the makefile changes >> in hotspot irrelevant. However, that implementation is not even started, >> so it's needed for the time being. >> >> The second change is the build-infra hotspot makefile rewrite. When that >> happens, stand-alone builds will definitely disappear, and if Hotspot >> still needs make support for version strings, then the logical choice is >> to use VERSION_CFLAGS. >> >> Ok? >> >>> >>> --- >>> >>> hotspot/src/share/vm/prims/jvm.h >>> jdk/src/java.base/share/native/include/jvm.h >>> >>> I think this comment is way out of date: >>> >>> /* Build number is available only for RE build (i.e. JDK_BUILD_NUMBER >>> is set to bNN) >>> * It will be zero for internal builds. >>> */ >>> >>> and can be completely removed. Even if still true, mention of an "RE >>> build" has no place in OpenJDK sources. >> Yep, agree. Follow-up patch, right? >> >>> >>> --- >>> >>> hotspot/src/share/vm/runtime/java.cpp >>> >>> I think a lot of the modified code is obsolete post Hotspot Express - >>> which makes it hard to determine if the changes make sense. >> Yep, agree. Follow-up patch, right? >>> >>> --- >>> >>> hotspot/src/share/vm/runtime/vmStructs.cpp >>> >>> Please fix the alignment (3 extra spaces on modified line): >>> >>> 1239 static_field(Abstract_VM_Version, _vm_minor_version, >>> int) \ >>> 1240 static_field(Abstract_VM_Version, >>> _vm_security_version, int) \ >> >> I was about to say "follow-up patch", but ugly indentation really sucks >> so I can fix this. Ok if I skip redoing the review for that? >> >>> >>> --- >>> >>> hotspot/test/runtime/6981737/Test6981737.java >>> >>> This test is really only valid for the new version scheme now, so it >>> should probably be rewritten - and in that case it really isn't >>> testing 6981737 but should be replaced by a new test for the new >>> version format. >> Yep, agree. Follow-up patch, right? >>> >>> --- >>> >>> jdk/src/java.base/share/classes/sun/misc/Version.java.template >>> >>> This comment is nonsensical: >>> >>> /** >>> ! * Returns the security version of the running JVM if it's 1.6 >>> or newer >>> * or any RE VM build. It will return 0 if it's an internal >>> 1.5 or >>> * 1.4.x build. >>> * @since 1.6 >>> */ >>> >>> as security version does not exist pre 9. Normally you should be >>> adding a new method and deprecating the old one. The new one is >>> @since 9. >> Yep, agree. Follow-up patch, right? >>> >>> /** >>> ! * Returns the security version of the running JDK. >>> * @since 1.6 >>> */ >>> >>> Ditto: @since 9 (but again old should be deprecated and new method >>> added) >>> >>> 253 /** >>> 254 * Returns the build number of the running JDK if it's a RE >>> build >>> 255 * It will return 0 if it's an internal build. >>> >>> As with jvm.h this seems obsolete commentary these days - not only RE >>> builds define a build number. >> Yep, agree. Follow-up patch, right? >> >> /Magnus >> >>> >>> Thanks, >>> David >> From erik.joelsson at oracle.com Thu Jun 11 13:09:12 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 15:09:12 +0200 Subject: RFR: JDK-8087193: Support building with devkits on Macosx In-Reply-To: <55796D8D.8000703@oracle.com> References: <55796704.3030901@oracle.com> <55796D8D.8000703@oracle.com> Message-ID: <55798878.3000308@oracle.com> It seems this approach didn't quite work out. The bootstrapping order of configure is sensitive. Here is another attempt at solving the issue by simply forcing macosx to be x86_64 in our config.guess wrapper. http://cr.openjdk.java.net/~erikj/8087193/webrev.02/ /Erik On 2015-06-11 13:14, Erik Joelsson wrote: > I forgot to motivate the change. Configure runs config.guess to figure > out what kind of machine it's running on. That file in turn uses the C > preprocessor to figure out if it's 32 or 64 bit. If we don't setup > devkit before running config.guess, the preprocessor might not be > available and configure will think the mac is a 32 bit machine. > > /Erik > > On 2015-06-11 12:46, Erik Joelsson wrote: >> Hello, >> >> Please review this minor tweak to configure which enables the use of >> a portable devkit on Macosx. Also included is the script used to >> generate the devkit. The plan is use this internally on our build >> servers to ease installation and setup of our machines. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8087193 >> Webrev: http://cr.openjdk.java.net/~erikj/8087193/webrev.01/ >> >> /Erik > From erik.joelsson at oracle.com Thu Jun 11 13:11:06 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 15:11:06 +0200 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557968AD.2040705@oracle.com> References: <557968AD.2040705@oracle.com> Message-ID: <557988EA.1030705@oracle.com> Hello again, I missed cleaning the path correctly when testing this so missed another needed change. When calling "lipo", the hotspot makefiles should use the variable supplied by configure. Here is an updated patch. Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ /Erik On 2015-06-11 12:53, Erik Joelsson wrote: > Hello, > > Please review this small makefile tweak. When using a devkit to build > hotspot on Macosx, the dtrace command gets confused and tries to use > the wrong preprocessor. I've fixed this by splitting out the running > of the preprocessor to a separate call. I've verified by comparing the > generated header files with and without the patch. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 > Patch inline: > diff -r 11af3990d56c make/bsd/makefiles/dtrace.make > --- a/make/bsd/makefiles/dtrace.make > +++ b/make/bsd/makefiles/dtrace.make > @@ -263,14 +263,19 @@ > $(DtraceOutDir): > mkdir $(DtraceOutDir) > > +# When building using a devkit, dtrace cannot find the correct > preprocessor so > +# we run it explicitly before runing dtrace. > $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | > $(DtraceOutDir) > - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s > $(DTRACE_COMMON_SRCDIR)/hotspot.d > + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c > $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d > + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d > > $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > | $(DtraceOutDir) > - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s > $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c > $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d > + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot_jni.d > > $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | > $(DtraceOutDir) > - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s > $(DTRACE_COMMON_SRCDIR)/hs_private.d > + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c > $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d > + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d > > dtrace_gen_headers: $(DtraceOutDir)/hotspot.h > $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h > > > /Erik From erik.joelsson at oracle.com Thu Jun 11 13:23:36 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 11 Jun 2015 15:23:36 +0200 Subject: RFR: JDK-8087208: Add devkit creation script for windows Message-ID: <55798BD8.4070708@oracle.com> For reference, I would like to add the script used to create the devkit on Windows to the source tree. Bug: https://bugs.openjdk.java.net/browse/JDK-8087208 Webrev: http://cr.openjdk.java.net/~erikj/8087208/webrev.01/ /Erik From david.holmes at oracle.com Fri Jun 12 02:20:04 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jun 2015 12:20:04 +1000 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557988EA.1030705@oracle.com> References: <557968AD.2040705@oracle.com> <557988EA.1030705@oracle.com> Message-ID: <557A41D4.8040300@oracle.com> Hi Erik, On 11/06/2015 11:11 PM, Erik Joelsson wrote: > Hello again, > > I missed cleaning the path correctly when testing this so missed another > needed change. When calling "lipo", the hotspot makefiles should use the > variable supplied by configure. Here is an updated patch. > > Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ Typo: + # we run it explicitly before runing dtrace. runing -> running Looks okay, only question I have is whether the preprocessed .d files should be placed into DtraceOutDir or some tmp location? I'm not sure where the contents of DtraceOutDir end up. Thanks, David > /Erik > > On 2015-06-11 12:53, Erik Joelsson wrote: >> Hello, >> >> Please review this small makefile tweak. When using a devkit to build >> hotspot on Macosx, the dtrace command gets confused and tries to use >> the wrong preprocessor. I've fixed this by splitting out the running >> of the preprocessor to a separate call. I've verified by comparing the >> generated header files with and without the patch. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 >> Patch inline: >> diff -r 11af3990d56c make/bsd/makefiles/dtrace.make >> --- a/make/bsd/makefiles/dtrace.make >> +++ b/make/bsd/makefiles/dtrace.make >> @@ -263,14 +263,19 @@ >> $(DtraceOutDir): >> mkdir $(DtraceOutDir) >> >> +# When building using a devkit, dtrace cannot find the correct >> preprocessor so >> +# we run it explicitly before runing dtrace. >> $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | >> $(DtraceOutDir) >> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >> $(DTRACE_COMMON_SRCDIR)/hotspot.d >> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >> $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d >> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d >> >> $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >> | $(DtraceOutDir) >> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d >> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot_jni.d >> >> $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | >> $(DtraceOutDir) >> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >> $(DTRACE_COMMON_SRCDIR)/hs_private.d >> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >> $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d >> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d >> >> dtrace_gen_headers: $(DtraceOutDir)/hotspot.h >> $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h >> >> >> /Erik > From erik.joelsson at oracle.com Fri Jun 12 06:35:25 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 12 Jun 2015 08:35:25 +0200 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557A41D4.8040300@oracle.com> References: <557968AD.2040705@oracle.com> <557988EA.1030705@oracle.com> <557A41D4.8040300@oracle.com> Message-ID: <557A7DAD.3020304@oracle.com> Hello David, On 2015-06-12 04:20, David Holmes wrote: > Hi Erik, > > On 11/06/2015 11:11 PM, Erik Joelsson wrote: >> Hello again, >> >> I missed cleaning the path correctly when testing this so missed another >> needed change. When calling "lipo", the hotspot makefiles should use the >> variable supplied by configure. Here is an updated patch. >> >> Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ > > Typo: + # we run it explicitly before runing dtrace. > > runing -> running > Fixing that. > Looks okay, only question I have is whether the preprocessed .d files > should be placed into DtraceOutDir or some tmp location? I'm not sure > where the contents of DtraceOutDir end up. > It's defined as DtraceOutDir = $(GENERATED)/dtracefiles which I assume is added to -I for the compiler later. I would say that it's safe to have a couple of other files end up in the same directory. Thanks /Erik > Thanks, > David > >> /Erik >> >> On 2015-06-11 12:53, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this small makefile tweak. When using a devkit to build >>> hotspot on Macosx, the dtrace command gets confused and tries to use >>> the wrong preprocessor. I've fixed this by splitting out the running >>> of the preprocessor to a separate call. I've verified by comparing the >>> generated header files with and without the patch. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 >>> Patch inline: >>> diff -r 11af3990d56c make/bsd/makefiles/dtrace.make >>> --- a/make/bsd/makefiles/dtrace.make >>> +++ b/make/bsd/makefiles/dtrace.make >>> @@ -263,14 +263,19 @@ >>> $(DtraceOutDir): >>> mkdir $(DtraceOutDir) >>> >>> +# When building using a devkit, dtrace cannot find the correct >>> preprocessor so >>> +# we run it explicitly before runing dtrace. >>> $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | >>> $(DtraceOutDir) >>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>> $(DTRACE_COMMON_SRCDIR)/hotspot.d >>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>> $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d >>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d >>> >>> $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>> | $(DtraceOutDir) >>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d >>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s >>> $(DtraceOutDir)/hotspot_jni.d >>> >>> $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | >>> $(DtraceOutDir) >>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>> $(DTRACE_COMMON_SRCDIR)/hs_private.d >>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>> $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d >>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d >>> >>> dtrace_gen_headers: $(DtraceOutDir)/hotspot.h >>> $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h >>> >>> >>> /Erik >> From magnus.ihse.bursie at oracle.com Fri Jun 12 06:52:46 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Jun 2015 08:52:46 +0200 Subject: RFR: JDK-8087193: Support building with devkits on Macosx In-Reply-To: <55798878.3000308@oracle.com> References: <55796704.3030901@oracle.com> <55796D8D.8000703@oracle.com> <55798878.3000308@oracle.com> Message-ID: <557A81BE.6010700@oracle.com> On 2015-06-11 15:09, Erik Joelsson wrote: > It seems this approach didn't quite work out. The bootstrapping order > of configure is sensitive. Here is another attempt at solving the > issue by simply forcing macosx to be x86_64 in our config.guess wrapper. > > http://cr.openjdk.java.net/~erikj/8087193/webrev.02/ This code: +echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null +if test $? = 0; then + REAL_CPU=`uname -m` + OUT=$REAL_CPU`echo $OUT | sed -e 's/[^-]*//'` +fi Can you provide an example of uname -m and the resulting OUT string on macosx/x64? /Magnus > > /Erik > > On 2015-06-11 13:14, Erik Joelsson wrote: >> I forgot to motivate the change. Configure runs config.guess to >> figure out what kind of machine it's running on. That file in turn >> uses the C preprocessor to figure out if it's 32 or 64 bit. If we >> don't setup devkit before running config.guess, the preprocessor >> might not be available and configure will think the mac is a 32 bit >> machine. >> >> /Erik >> >> On 2015-06-11 12:46, Erik Joelsson wrote: >>> Hello, >>> >>> Please review this minor tweak to configure which enables the use of >>> a portable devkit on Macosx. Also included is the script used to >>> generate the devkit. The plan is use this internally on our build >>> servers to ease installation and setup of our machines. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087193 >>> Webrev: http://cr.openjdk.java.net/~erikj/8087193/webrev.01/ >>> >>> /Erik >> > From erik.joelsson at oracle.com Fri Jun 12 07:05:35 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 12 Jun 2015 09:05:35 +0200 Subject: RFR: JDK-8087193: Support building with devkits on Macosx In-Reply-To: <557A81BE.6010700@oracle.com> References: <55796704.3030901@oracle.com> <55796D8D.8000703@oracle.com> <55798878.3000308@oracle.com> <557A81BE.6010700@oracle.com> Message-ID: <557A84BF.1050008@oracle.com> On the machine I'm trying this on, without any C compiler on the path, this is what I get with the patch. Note that "uname -p" is what autoconf-config.guess is using. > uname -m x86_64 > uname -p i386 > bash common/autoconf/build-aux/autoconf-config.guess i386-apple-darwin13.4.0 > bash common/autoconf/build-aux/config.guess x86_64-apple-darwin13.4.0 /Erik On 2015-06-12 08:52, Magnus Ihse Bursie wrote: > On 2015-06-11 15:09, Erik Joelsson wrote: >> It seems this approach didn't quite work out. The bootstrapping order >> of configure is sensitive. Here is another attempt at solving the >> issue by simply forcing macosx to be x86_64 in our config.guess wrapper. >> >> http://cr.openjdk.java.net/~erikj/8087193/webrev.02/ > > This code: > > +echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null > +if test $? = 0; then > + REAL_CPU=`uname -m` > + OUT=$REAL_CPU`echo $OUT | sed -e 's/[^-]*//'` > +fi > > > Can you provide an example of uname -m and the resulting OUT string > on macosx/x64? > > /Magnus > >> >> /Erik >> >> On 2015-06-11 13:14, Erik Joelsson wrote: >>> I forgot to motivate the change. Configure runs config.guess to >>> figure out what kind of machine it's running on. That file in turn >>> uses the C preprocessor to figure out if it's 32 or 64 bit. If we >>> don't setup devkit before running config.guess, the preprocessor >>> might not be available and configure will think the mac is a 32 bit >>> machine. >>> >>> /Erik >>> >>> On 2015-06-11 12:46, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this minor tweak to configure which enables the use >>>> of a portable devkit on Macosx. Also included is the script used to >>>> generate the devkit. The plan is use this internally on our build >>>> servers to ease installation and setup of our machines. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087193 >>>> Webrev: http://cr.openjdk.java.net/~erikj/8087193/webrev.01/ >>>> >>>> /Erik >>> >> > From david.holmes at oracle.com Fri Jun 12 07:11:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 12 Jun 2015 17:11:45 +1000 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557A7DAD.3020304@oracle.com> References: <557968AD.2040705@oracle.com> <557988EA.1030705@oracle.com> <557A41D4.8040300@oracle.com> <557A7DAD.3020304@oracle.com> Message-ID: <557A8631.6000706@oracle.com> On 12/06/2015 4:35 PM, Erik Joelsson wrote: > Hello David, > > On 2015-06-12 04:20, David Holmes wrote: >> Hi Erik, >> >> On 11/06/2015 11:11 PM, Erik Joelsson wrote: >>> Hello again, >>> >>> I missed cleaning the path correctly when testing this so missed another >>> needed change. When calling "lipo", the hotspot makefiles should use the >>> variable supplied by configure. Here is an updated patch. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ >> >> Typo: + # we run it explicitly before runing dtrace. >> >> runing -> running >> > Fixing that. >> Looks okay, only question I have is whether the preprocessed .d files >> should be placed into DtraceOutDir or some tmp location? I'm not sure >> where the contents of DtraceOutDir end up. >> > It's defined as > DtraceOutDir = $(GENERATED)/dtracefiles > > which I assume is added to -I for the compiler later. I would say that > it's safe to have a couple of other files end up in the same directory. Yep now I see it: Src_Dirs_I += $(GENERATED) and then: ./share/vm/utilities/dtrace.hpp:#include "dtracefiles/hotspot.h" ./share/vm/utilities/dtrace.hpp:#include "dtracefiles/hotspot_jni.h" ./share/vm/utilities/dtrace.hpp:#include "dtracefiles/hs_private.h" No problem. Thanks, David > Thanks > /Erik >> Thanks, >> David >> >>> /Erik >>> >>> On 2015-06-11 12:53, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this small makefile tweak. When using a devkit to build >>>> hotspot on Macosx, the dtrace command gets confused and tries to use >>>> the wrong preprocessor. I've fixed this by splitting out the running >>>> of the preprocessor to a separate call. I've verified by comparing the >>>> generated header files with and without the patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 >>>> Patch inline: >>>> diff -r 11af3990d56c make/bsd/makefiles/dtrace.make >>>> --- a/make/bsd/makefiles/dtrace.make >>>> +++ b/make/bsd/makefiles/dtrace.make >>>> @@ -263,14 +263,19 @@ >>>> $(DtraceOutDir): >>>> mkdir $(DtraceOutDir) >>>> >>>> +# When building using a devkit, dtrace cannot find the correct >>>> preprocessor so >>>> +# we run it explicitly before runing dtrace. >>>> $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | >>>> $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hotspot.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d >>>> >>>> $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>>> | $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s >>>> $(DtraceOutDir)/hotspot_jni.d >>>> >>>> $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | >>>> $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hs_private.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hs_private.d >>>> >>>> dtrace_gen_headers: $(DtraceOutDir)/hotspot.h >>>> $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h >>>> >>>> >>>> /Erik >>> > From magnus.ihse.bursie at oracle.com Fri Jun 12 13:02:18 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Jun 2015 15:02:18 +0200 Subject: RfR JDK-8055160 In-Reply-To: <5578BB50.6090708@oracle.com> References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> Message-ID: <557AD85A.2000702@oracle.com> On 2015-06-11 00:33, Pete Brunet wrote: > Due to some other priorities it's been over 2 months since the last > webrev. An update is here: > http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 Build changes look good. /Magnus > > The changes from webrev.02 are: > > 1) The test was changed to not use the service provider to test the > activation of the service provider. Instead a file is created when > Toolkit.getDefaultToolkit activates providers and tested for existence > when the test runs. > > 2) The copyright header in the new jdk.accessibility files were fixed. > > Pete > > On 4/3/15 3:59 PM, Pete Brunet wrote: >> Due to the recent push of JDK-8076182 (Open source Java Access Bridge) >> which exposed some files that were in closed the webrev needs a full >> re-review. I've also made the changes requested by Mandy. >> >> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.02/ >> >> Pete >> >> On 3/23/15 4:41 PM, Mandy Chung wrote: >>> >>> On 3/19/2015 6:03 PM, Pete Brunet wrote: >>>> A new webrev is available at >>>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.01/ >>>> >>> line 820-821: this comment is incorrect. >>> >>> line 831-838: what happens if ServiceConfigurationException thrown or >>> any exception is thrown by the activate method? This should wrap >>> with AWTError as I mentioned in my previous review comment. This was >>> hidden with the test (see below). >>> >>> line 891-901: this example may not be necessary as the service loader >>> documentation should cover it. >>> >>>> >>>> The changes to the tests are: >>>> - added an unused provider >>>> - added a test activating two providers >>>> >>>> Mandy, Regarding the last bullet I'm not sure I resolved your >>>> comment, "For the test, since you support multiple providers, >>>> perhaps good to add one more test case to activate two providers and >>>> load two providers but only one is activated." If not, please let >>>> me know. >>> Almost. For Foo, Bar providers, their activate method throwing >>> RuntimeException actually stops loading the second provider. The >>> activate method could perhaps update some static field defined in the >>> Load class if it's called (perhaps adding its name) so that you can >>> tell whether the expected providers are activated. UnusedProvider >>> throwing RuntimeException is good since you don't expect it's activated. >>> >>> Otherwise, looks good. >>> >>> Mandy From magnus.ihse.bursie at oracle.com Fri Jun 12 13:04:29 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Jun 2015 15:04:29 +0200 Subject: RFR: 8087156: SetupNativeCompilation ignores CFLAGS_release for cpp files In-Reply-To: <55792FD4.5030907@oracle.com> References: <20150610223609.GC19138@redhat.com> <55792FD4.5030907@oracle.com> Message-ID: <557AD8DD.6020306@oracle.com> On 2015-06-11 08:51, Erik Joelsson wrote: > Hello Omair, > > This looks good to me, thanks for catching it! Looks good to me too. However, this is not the first time we've encountered a problem like this. I ran into a similar problem some time ago. It's a very brittle system we have. I believe we should get rid of the CXXFLAGS and just have CFLAGS and let them cover c++ compilation as well. Do we have use cases where C and C++ both are used in the same library, and requires different flags? /Magnus > > /Erik > > On 2015-06-11 00:36, Omair Majid wrote: >> Hi, >> >> I discovered a bug in SetupNativeCompilation that results in some C++ >> code being built with wrong CXXFLAGS. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8087156 >> Webrev: >> http://cr.openjdk.java.net/~omajid/webrevs/8087156-setupnativecompilation/00/ >> >> It turns out that debugging flags are automatically added to the >> CXXFLAGS which makes the code that copies over CFLAGS to CXXFLAGS if >> CXXFLAGS is empty fail. This causes the desired CXXFLAGS to not be set >> at all. >> >> Depending on the code, these CXXFLAGS can include -DPRODUCT. In other >> words, some JDK code is currently being built as if in non-product mode. >> An example of this is libunpack: >> >> jdk/make/lib/Lib-jdk.pack200.gmk: >> >> $(eval $(call SetupNativeCompilation,BUILD_LIBUNPACK, \ >> ... snip ... >> CFLAGS_release := -DPRODUCT, \ >> ... snip ... >> >> The same issue exists in OpenJDK 8. >> >> Thanks, >> Omair >> > From magnus.ihse.bursie at oracle.com Fri Jun 12 13:05:31 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Jun 2015 15:05:31 +0200 Subject: RFR: JDK-8087208: Add devkit creation script for windows In-Reply-To: <55798BD8.4070708@oracle.com> References: <55798BD8.4070708@oracle.com> Message-ID: <557AD91B.80609@oracle.com> On 2015-06-11 15:23, Erik Joelsson wrote: > For reference, I would like to add the script used to create the > devkit on Windows to the source tree. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087208 > Webrev: http://cr.openjdk.java.net/~erikj/8087208/webrev.01/ > > /Erik Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Fri Jun 12 13:07:37 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Jun 2015 15:07:37 +0200 Subject: RFR: JDK-8087193: Support building with devkits on Macosx In-Reply-To: <557A84BF.1050008@oracle.com> References: <55796704.3030901@oracle.com> <55796D8D.8000703@oracle.com> <55798878.3000308@oracle.com> <557A81BE.6010700@oracle.com> <557A84BF.1050008@oracle.com> Message-ID: <557AD999.1090204@oracle.com> On 2015-06-12 09:05, Erik Joelsson wrote: > On the machine I'm trying this on, without any C compiler on the path, > this is what I get with the patch. Note that "uname -p" is what > autoconf-config.guess is using. > > > uname -m > x86_64 > > uname -p > i386 > > > bash common/autoconf/build-aux/autoconf-config.guess > i386-apple-darwin13.4.0 > > > bash common/autoconf/build-aux/config.guess > x86_64-apple-darwin13.4.0 Thanks! I misread the sed expression and couldn't figure out how it could possibly work. :) Looks good to me now. /Magnus > > /Erik > > On 2015-06-12 08:52, Magnus Ihse Bursie wrote: >> On 2015-06-11 15:09, Erik Joelsson wrote: >>> It seems this approach didn't quite work out. The bootstrapping >>> order of configure is sensitive. Here is another attempt at solving >>> the issue by simply forcing macosx to be x86_64 in our config.guess >>> wrapper. >>> >>> http://cr.openjdk.java.net/~erikj/8087193/webrev.02/ >> >> This code: >> >> +echo $OUT | grep i386-apple-darwin > /dev/null 2> /dev/null >> +if test $? = 0; then >> + REAL_CPU=`uname -m` >> + OUT=$REAL_CPU`echo $OUT | sed -e 's/[^-]*//'` >> +fi >> >> >> Can you provide an example of uname -m and the resulting OUT string >> on macosx/x64? >> >> /Magnus >> >>> >>> /Erik >>> >>> On 2015-06-11 13:14, Erik Joelsson wrote: >>>> I forgot to motivate the change. Configure runs config.guess to >>>> figure out what kind of machine it's running on. That file in turn >>>> uses the C preprocessor to figure out if it's 32 or 64 bit. If we >>>> don't setup devkit before running config.guess, the preprocessor >>>> might not be available and configure will think the mac is a 32 bit >>>> machine. >>>> >>>> /Erik >>>> >>>> On 2015-06-11 12:46, Erik Joelsson wrote: >>>>> Hello, >>>>> >>>>> Please review this minor tweak to configure which enables the use >>>>> of a portable devkit on Macosx. Also included is the script used >>>>> to generate the devkit. The plan is use this internally on our >>>>> build servers to ease installation and setup of our machines. >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087193 >>>>> Webrev: http://cr.openjdk.java.net/~erikj/8087193/webrev.01/ >>>>> >>>>> /Erik >>>> >>> >> > From magnus.ihse.bursie at oracle.com Fri Jun 12 13:10:36 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Jun 2015 15:10:36 +0200 Subject: question on checking dependencies across modules In-Reply-To: <5578CA68.90800@oracle.com> References: <55783AD0.5060705@oracle.com> <97B2EDCC-083B-402E-BEF2-5154AA79B384@oracle.com> <5578CA68.90800@oracle.com> Message-ID: <557ADA4C.9040808@oracle.com> On 2015-06-11 01:38, Maurizio Cimadamore wrote: > > > On 10/06/15 17:27, Mandy Chung wrote: >>> On Jun 10, 2015, at 6:25 AM, Maurizio Cimadamore >>> wrote: >>> >>> Hi, >>> In the context of the IntelliJ project support for JDK, I have a >>> question on the very last step of 'make images' : >>> >>> ## Starting verify-modules >>> Checking dependencies across JDK modules >>> Access verification succeeded. >>> >>> I noticed that this step is always applied, regardless of whether >>> there was actually any change in the sources/built classes or not. >>> Is that deliberate? This is a bit unfortunate as in our setup we >>> depend on 'make images' to run tests, and if there's nothing to do, >>> you will still have to wait several seconds for 'make images' to >>> complete. >> This step verifies access across module boundaries and should only be >> needed when any change in built classes. This can be improved >> while this step is temporary until the module system is moving >> along. Erik and Magnus may be able to come up with a simple way to >> check if any class is recompiled; otherwise this step can be skipped. > Right - this is what I was trying to ask - i.e. if there was any weird > reason as to why this step was necessary even w/o any change in any > source. It seems like the current behavior is mostly accidental and, > coupled with the fact that (i) this is going away soon and (ii) there > are workarounds (make jimages) - it should best be left as it is now? > > Now, 'jimages' seems to be working fine for my needs - what is the > feeling about this target moving forward? Is it something we can rely > upon, or is 'jimages' also going away/replaced by something else (in > which case using 'images' would be a more stable choice) ? The following targets from Main.gmk are the "main entry points": # Traditional targets typically run by users. # These can be considered aliases for the targets now named by a more # "modern" naming scheme. default: exploded-image jdk: exploded-image images: product-images docs: docs-image all: all-images I think I can safely promise that these will never go away. So "images" would be a safe choice, but not jimages. /Magnus From magnus.ihse.bursie at oracle.com Fri Jun 12 13:12:11 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 12 Jun 2015 15:12:11 +0200 Subject: RFR: JDK-8087195: Support building hotspot with devkits on Macosx In-Reply-To: <557A7DAD.3020304@oracle.com> References: <557968AD.2040705@oracle.com> <557988EA.1030705@oracle.com> <557A41D4.8040300@oracle.com> <557A7DAD.3020304@oracle.com> Message-ID: <557ADAAB.6040309@oracle.com> On 2015-06-12 08:35, Erik Joelsson wrote: > Hello David, > > On 2015-06-12 04:20, David Holmes wrote: >> Hi Erik, >> >> On 11/06/2015 11:11 PM, Erik Joelsson wrote: >>> Hello again, >>> >>> I missed cleaning the path correctly when testing this so missed >>> another >>> needed change. When calling "lipo", the hotspot makefiles should use >>> the >>> variable supplied by configure. Here is an updated patch. >>> >>> Webrev: http://cr.openjdk.java.net/~erikj/8087195/webrev.hotspot.01/ >> >> Typo: + # we run it explicitly before runing dtrace. >> >> runing -> running >> > Fixing that. Looks good to me then. /Magnus >> Looks okay, only question I have is whether the preprocessed .d files >> should be placed into DtraceOutDir or some tmp location? I'm not sure >> where the contents of DtraceOutDir end up. >> > It's defined as > DtraceOutDir = $(GENERATED)/dtracefiles > > which I assume is added to -I for the compiler later. I would say that > it's safe to have a couple of other files end up in the same directory. > > Thanks > /Erik >> Thanks, >> David >> >>> /Erik >>> >>> On 2015-06-11 12:53, Erik Joelsson wrote: >>>> Hello, >>>> >>>> Please review this small makefile tweak. When using a devkit to build >>>> hotspot on Macosx, the dtrace command gets confused and tries to use >>>> the wrong preprocessor. I've fixed this by splitting out the running >>>> of the preprocessor to a separate call. I've verified by comparing the >>>> generated header files with and without the patch. >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8087195 >>>> Patch inline: >>>> diff -r 11af3990d56c make/bsd/makefiles/dtrace.make >>>> --- a/make/bsd/makefiles/dtrace.make >>>> +++ b/make/bsd/makefiles/dtrace.make >>>> @@ -263,14 +263,19 @@ >>>> $(DtraceOutDir): >>>> mkdir $(DtraceOutDir) >>>> >>>> +# When building using a devkit, dtrace cannot find the correct >>>> preprocessor so >>>> +# we run it explicitly before runing dtrace. >>>> $(DtraceOutDir)/hotspot.h: $(DTRACE_COMMON_SRCDIR)/hotspot.d | >>>> $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hotspot.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hotspot.d > $(DtraceOutDir)/hotspot.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s $(DtraceOutDir)/hotspot.d >>>> >>>> $(DtraceOutDir)/hotspot_jni.h: $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>>> | $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hotspot_jni.d > $(DtraceOutDir)/hotspot_jni.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s >>>> $(DtraceOutDir)/hotspot_jni.d >>>> >>>> $(DtraceOutDir)/hs_private.h: $(DTRACE_COMMON_SRCDIR)/hs_private.d | >>>> $(DtraceOutDir) >>>> - $(QUIETLY) $(DTRACE_PROG) $(DTRACE_OPTS) -C -I. -h -o $@ -s >>>> $(DTRACE_COMMON_SRCDIR)/hs_private.d >>>> + $(QUIETLY) $(CC) -E $(DTRACE_OPTS) -I. -x c >>>> $(DTRACE_COMMON_SRCDIR)/hs_private.d > $(DtraceOutDir)/hs_private.d >>>> + $(QUIETLY) $(DTRACE_PROG) -h -o $@ -s >>>> $(DtraceOutDir)/hs_private.d >>>> >>>> dtrace_gen_headers: $(DtraceOutDir)/hotspot.h >>>> $(DtraceOutDir)/hotspot_jni.h $(DtraceOutDir)/hs_private.h >>>> >>>> >>>> /Erik >>> > From peter.brunet at oracle.com Fri Jun 12 14:36:02 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 12 Jun 2015 09:36:02 -0500 Subject: RfR JDK-8055160 In-Reply-To: References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> Message-ID: <557AEE52.8000504@oracle.com> Thanks Mandy. I need one more review from the awt-dev team. Pete On 6/10/15 6:29 PM, Mandy Chung wrote: >> On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote: >> >> Due to some other priorities it's been over 2 months since the last webrev. An update is here: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 > BarProvider.java > You can use try-with-resource > try (PrintWriter writer = new PrintWriter("BarProvider.txt?)) { > writer.println("BarProvider-activated?); > } catch (IOException e) { > throw new UncheckedException(e); > } > > That will close the writer. I think you should rethow IOException instead of swallowing it. > > Same comment to other provider implementation. > > Load.java > The test should clean up all files before starting loading the providers since someone may run the test standalone multiple times on the same directory. > > Otherwise looks good to me. > > make/Images.gmk needs fixing as I mentioned earlier. > > Mandy > > From Sergey.Bylokhov at oracle.com Fri Jun 12 15:48:36 2015 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Jun 2015 18:48:36 +0300 Subject: RfR JDK-8055160 In-Reply-To: <557AEE52.8000504@oracle.com> References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> <557AEE52.8000504@oracle.com> Message-ID: <557AFF54.9080808@oracle.com> Looks fine. On 12.06.2015 17:36, Pete Brunet wrote: > Thanks Mandy. > > I need one more review from the awt-dev team. > > Pete > > On 6/10/15 6:29 PM, Mandy Chung wrote: >>> On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote: >>> >>> Due to some other priorities it's been over 2 months since the last webrev. An update is here: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 >> BarProvider.java >> You can use try-with-resource >> try (PrintWriter writer = new PrintWriter("BarProvider.txt?)) { >> writer.println("BarProvider-activated?); >> } catch (IOException e) { >> throw new UncheckedException(e); >> } >> >> That will close the writer. I think you should rethow IOException instead of swallowing it. >> >> Same comment to other provider implementation. >> >> Load.java >> The test should clean up all files before starting loading the providers since someone may run the test standalone multiple times on the same directory. >> >> Otherwise looks good to me. >> >> make/Images.gmk needs fixing as I mentioned earlier. >> >> Mandy >> >> -- Best regards, Sergey. From omajid at redhat.com Fri Jun 12 16:08:08 2015 From: omajid at redhat.com (Omair Majid) Date: Fri, 12 Jun 2015 12:08:08 -0400 Subject: RFR: 8087156: SetupNativeCompilation ignores CFLAGS_release for cpp files In-Reply-To: <557AD8DD.6020306@oracle.com> References: <20150610223609.GC19138@redhat.com> <55792FD4.5030907@oracle.com> <557AD8DD.6020306@oracle.com> Message-ID: <20150612160808.GF2726@redhat.com> * Magnus Ihse Bursie [2015-06-12 09:02]: > Looks good to me too. Thanks for the review! Sorry I was unable to credit you since I already pushed the patch. > However, this is not the first time we've encountered a problem like this. I > ran into a similar problem some time ago. It's a very brittle system we > have. I believe we should get rid of the CXXFLAGS and just have CFLAGS and > let them cover c++ compilation as well. > > Do we have use cases where C and C++ both are used in the same library, and > requires different flags? I took a cursory look through everything (except hotspot makefiles) and I don't see any obvious such case. All code uses either identical CFLAGS and CXXFLAGS or only one of CFLAGS or CXXFLAGS. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From peter.brunet at oracle.com Fri Jun 12 20:07:11 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 12 Jun 2015 15:07:11 -0500 Subject: RfR JDK-8055160 In-Reply-To: References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> Message-ID: <557B3BEF.8080107@oracle.com> Thanks Mandy, The new patch is at http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.04 On 6/10/15 6:29 PM, Mandy Chung wrote: >> On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote: >> >> Due to some other priorities it's been over 2 months since the last webrev. An update is here: >> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 > BarProvider.java > You can use try-with-resource > try (PrintWriter writer = new PrintWriter("BarProvider.txt?)) { > writer.println("BarProvider-activated?); > } catch (IOException e) { > throw new UncheckedException(e); > } > > That will close the writer. I think you should rethow IOException instead of swallowing it. > > Same comment to other provider implementation. Done, using UncheckedIOException. > > Load.java > The test should clean up all files before starting loading the providers since someone may run the test standalone multiple times on the same directory. Done. I was removing them in the shell script but I've moved that now to the Java code. I had to add delete to the permissions in accessibilityProvider.sp. > > Otherwise looks good to me. > > make/Images.gmk needs fixing as I mentioned earlier. Done in JDK-8078335. > > Mandy > > From mandy.chung at oracle.com Fri Jun 12 20:52:23 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Jun 2015 13:52:23 -0700 Subject: RfR JDK-8055160 In-Reply-To: <557B3BEF.8080107@oracle.com> References: <5507429B.1090300@oracle.com> <55077FEB.20101@oracle.com> <5507E910.9090200@oracle.com> <550893B9.7050003@oracle.com> <55089B98.1000206@oracle.com> <550B71F2.60906@oracle.com> <55108897.7000703@oracle.com> <551EFF4E.1070007@oracle.com> <5578BB50.6090708@oracle.com> <557B3BEF.8080107@oracle.com> Message-ID: > On Jun 12, 2015, at 1:07 PM, Pete Brunet wrote: > > Thanks Mandy, The new patch is at > http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.04 > Looks good. Thanks. > On 6/10/15 6:29 PM, Mandy Chung wrote: >>> On Jun 10, 2015, at 3:33 PM, Pete Brunet wrote: >>> >>> Due to some other priorities it's been over 2 months since the last webrev. An update is here: >>> http://cr.openjdk.java.net/~ptbrunet/JDK-8055160/webrev.03 >> BarProvider.java >> You can use try-with-resource >> try (PrintWriter writer = new PrintWriter("BarProvider.txt?)) { >> writer.println("BarProvider-activated?); >> } catch (IOException e) { >> throw new UncheckedException(e); >> } >> >> That will close the writer. I think you should rethow IOException instead of swallowing it. >> >> Same comment to other provider implementation. > Done, using UncheckedIOException. >> >> Load.java >> The test should clean up all files before starting loading the providers since someone may run the test standalone multiple times on the same directory. > Done. I was removing them in the shell script but I've moved that now > to the Java code. I had to add delete to the permissions in > accessibilityProvider.sp. I missed that in the shell test. The new version is good. Thanks Mandy From sean.coffey at oracle.com Mon Jun 15 13:30:41 2015 From: sean.coffey at oracle.com (=?UTF-8?B?U2XDoW4gQ29mZmV5?=) Date: Mon, 15 Jun 2015 14:30:41 +0100 Subject: Question around the 8054717 fix Message-ID: <557ED381.9060200@oracle.com> Hi, I had a security library fix reviewed last week [1] and all was ok with builds back then. Today, I found that my build is broken and I think it's down to the changes introduced from the 8054717 fix. The build error (snippet) is : > /opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:74: error: ECPublicKeyImpl(byte[]) is not public in ECPublicKeyImpl; cannot be accessed from outside package > return new ECPublicKeyImpl(x509Spec.getEncoded()); > ^ > /opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:77: error: constructor ECPublicKeyImpl in class ECPublicKeyImpl cannot be applied to given types; > return new ECPublicKeyImpl( > ^ > required: byte[] > found: ECPoint,ECParameterSpec > reason: actual and formal argument lists differ in length I've confirmed that I do have the correct access type modifications in the ECPublicKeyImpl constructor (moved to public) The build system appears to be picking up the older ECPublicKeyImpl class in the bootstrap JDK and not the newly built classes. 8054717 appears to have modified bootclasspath settings. Is this an issue with my security fix or a build issue ? I've tried the build on my local system and an JPRT. regards, Sean. [1] http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/ From joe.darcy at oracle.com Mon Jun 15 17:13:09 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 15 Jun 2015 10:13:09 -0700 Subject: JDK 9 RFR of JDK-8098579: Remove non-existent javax.tools.annotation package from CORE_PKGS.gmk Message-ID: <557F07A5.3090209@oracle.com> Hello, Please review the fix below to address JDK-8098579: Remove non-existent javax.tools.annotation package from CORE_PKGS.gmk Thanks, -Joe diff -r 1bcfd6b87265 make/common/CORE_PKGS.gmk --- a/make/common/CORE_PKGS.gmk Thu Jun 11 20:18:41 2015 -0700 +++ b/make/common/CORE_PKGS.gmk Mon Jun 15 10:07:11 2015 -0700 @@ -222,7 +222,6 @@ javax.swing.plaf.nimbus \ javax.swing.plaf.synth \ javax.tools \ - javax.tools.annotation \ javax.transaction \ javax.transaction.xa \ javax.xml.parsers \ From Roger.Riggs at Oracle.com Mon Jun 15 21:58:22 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 15 Jun 2015 17:58:22 -0400 Subject: RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version Message-ID: <557F4A7E.1080203@Oracle.com> Please review code for Windows 10 that sets the System properties for os.name and os.version from the version of kernel32.dll. The update uses the same technique used by Hotspot in src/os/windows/vm/os_windows.cpp. The Windows link of CoreLibraries.gmk includes version.lib/dll. The behavior of GetVersionEx has changed so it reports whatever version the application asserts it is compatible with instead of the current version of Windows. See: https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx The same change is desirable for 8u60. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-win-ver-8066504/ Issue: https://bugs.openjdk.java.net/browse/JDK-8066504 Thanks, Roger From valerie.peng at oracle.com Mon Jun 15 23:58:04 2015 From: valerie.peng at oracle.com (Valerie Peng) Date: Mon, 15 Jun 2015 16:58:04 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557628F8.8000001@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> Message-ID: <557F668C.5090101@oracle.com> It seems that the jimage refresh change may still take some time, so we will end up removing the makefile related changes and then deferring the ServiceLoader related changes to Jake workspace. Here is the latest webrev (Security source/test changes only, no more makefile changes) http://cr.openjdk.java.net/~valeriep/7191662/webrev.04/ Summary of changes from webrev.03: 1) switch back to provider class names for java.security file 2) separated out the java.policy change into its own as SQE has filed a bug for it 3) updated sun.security.jca.Providers class due to 1) 4) fixed sun.security.tools.jarsigner.Main to use the new Provider.configure() api 5) fixed a bug in sun.security.pkcs11.PKCS11Test regarding searching and configuring PKCS11 provider Thanks, Valerie On 6/8/2015 4:44 PM, Valerie Peng wrote: > > What is the bug id for the image refresh change? Just so I can keep a > watch and hold my changes for the time being. > > My webrev has a new regression test which compares the list of > providers found by ServiceLoader and Security.getProviders() call. So, > if the META-INF/services/java.security.Provider file content is not > correct, the new test would fail and it's a clear indication that > ServiceLoader can't find one or more of the providers. > > Thanks, > Valerie > > On 6/5/2015 10:43 PM, Mandy Chung wrote: >>> On Jun 5, 2015, at 4:32 PM, Valerie Peng >>> wrote: >>> >>> >>> I don't know image builder well enough to answer your question. >> The current implementation of the image builder sorts the modules by >> their name that are mapped to the same class loader. That explains >> why java.naming is the first one containing >> META-INF/services/java.security.Provider in your current list. >> >> There is no guarantee in what particular order a module is processed >> first. I don?t know if the jimage refresh work will change the >> ordering either. Since this is temporary, I?m okay if you want to >> depend on the image build implementation as long as you have a test >> to catch it and verify >> java.naming/META-INF/services/java.security.Provider file content. >> The existing security tests may also catch it but I think it?s not >> obvious to indicate that the security tests fail because of the issue >> of the merged service configuration file. >> >> Please also hold off until the image refresh change goes into >> jdk9/dev so that you can verify if your build change still works. >> >> If you want to push earlier, another alternative we discussed earlier >> is to separate the META-INF/services file and make change and >> java.security to keep using classname. That can be pushed that in a >> second phase with a proper image builder support. >> >> Mandy >> >>> Based on my own experiment, it seems to pick up the one from >>> java.naming when duplication occurs, so that's why I saved the >>> merged result to there and named the Gensrc makefile with >>> java.naming. The result build work fine. >>> >>> Does this explain what I am trying to do here? If you have better >>> ways to get this done, I am certainly open to that idea. >>> Thanks, >>> Valerie >>> >>> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>>> Hello Valerie, >>>> >>>> The merging seems ok, but I thought there was non determinism in >>>> the image builder regarding which provider would get picked up. Is >>>> that resolved or do you really need to override all of those >>>> providers with your generated file in gensrc? I can assist in >>>> writing that makefile logic if needed. >>>> >>>> /Erik >>>> >>>> On 2015-06-04 23:58, Valerie Peng wrote: >>>>> Build experts, >>>>> >>>>> Can you please review the make file related change, i.e. the new >>>>> file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>>> >>>>> This is for merging the java.security.Provider file from various >>>>> providers and use the (merged) result for the final image build. >>>>> >>>>> Thanks, >>>>> Valerie >>>>> >>>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>>> Correct, if the makefile related changes are removed then no need >>>>>> for build team to review 7191662 webrev anymore. >>>>>> There are other discussions ongoing and we should be able to >>>>>> reach a decision in a day or two. >>>>>> Will update the list again. >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>>> Please find comments in line... >>>>>>>> >>>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>>> Valerie, >>>>>>>>> >>>>>>>>> Did you see my comment yesterday? >>>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>>>> >>>>>>>> Yes, we exchanged emails after this above one. I will follow up >>>>>>>> your latest one later today. >>>>>>>> >>>>>>>>> Since you have reverted the java.security to keep the >>>>>>>>> classname, to avoid causing merge conflict to jimage refresh, >>>>>>>>> let?s remove the META-INF files in the first push and the >>>>>>>>> build change. >>>>>>>>> >>>>>>>>> The security providers will be loaded via the fallback >>>>>>>>> mechanism (i.e. ProviderLoader.legacyLoad method). You should >>>>>>>>> keep the ProviderLoader.load method to take the provider name >>>>>>>>> instead of classname. >>>>>>>> Sure, I can remove the META-INF files so the providers are >>>>>>>> loaded through the legacyLoad(). >>>>>>>> Hmm, the ProviderLoader.load() method is used by java.security >>>>>>>> file provider loading. Since the current list still uses class >>>>>>>> name, it should take class name when checking for matches while >>>>>>>> iterating through the list returned by ServiceLoader. >>>>>>>> This way, when changes are sync'ed into Jake, no extra change >>>>>>>> required and the providers will be loaded through >>>>>>>> ProviderLoader.load() automatically with the current list. >>>>>>>> >>>>>>>>> I?ll file a bug to follow up to change java.security to list >>>>>>>>> the provider name. This will wait after the jimage refresh >>>>>>>>> goes into jdk9/dev >>>>>>>> Ok. >>>>>>>> Thanks, >>>>>>>> Valerie >>>>>>> I'm not sure I followed completely here were this landed. Does >>>>>>> this mean that there's currently no need for a build system code >>>>>>> review on >>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and >>>>>>> that a new webrev will be posted instead? >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> >>>>>>>>> . >>>>>>>>> >>>>>>>>> Mandy >>>>>>>>> >>>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie >>>>>>>>>> Peng wrote: >>>>>>>>>> >>>>>>>>>> Hi, build experts, >>>>>>>>>> >>>>>>>>>> Can you please review the make file related change, i.e. the >>>>>>>>>> new file make/gensrc/Gensrc-java.naming.gmk, in the following >>>>>>>>>> webrev: >>>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>>> >>>>>>>>>> This is for merging the java.security.Provider file from >>>>>>>>>> various providers and use the (merged) result for the final >>>>>>>>>> image build. >>>>>>>>>> >>>>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>>>> Thanks, >>>>>>>>>> Valerie >>>>>>>>>> (Java Security Team) From andreas.lundblad at oracle.com Tue Jun 16 08:04:54 2015 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Tue, 16 Jun 2015 10:04:54 +0200 Subject: Question around the 8054717 fix In-Reply-To: <557ED381.9060200@oracle.com> References: <557ED381.9060200@oracle.com> Message-ID: <20150616080453.GA568@e6430> On Mon, Jun 15, 2015 at 02:30:41PM +0100, Se?n Coffey wrote: > Hi, > > I had a security library fix reviewed last week [1] and all was ok > with builds back then. Today, I found that my build is broken and I > think it's down to the changes introduced from the 8054717 fix. > > The build error (snippet) is : > > >/opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:74: error: ECPublicKeyImpl(byte[]) is not public in ECPublicKeyImpl; cannot be accessed from outside package > > return new ECPublicKeyImpl(x509Spec.getEncoded()); > > ^ > >/opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:77: error: constructor ECPublicKeyImpl in class ECPublicKeyImpl cannot be applied to given types; > > return new ECPublicKeyImpl( > > ^ > > required: byte[] > > found: ECPoint,ECParameterSpec > > reason: actual and formal argument lists differ in length > I've confirmed that I do have the correct access type modifications > in the ECPublicKeyImpl constructor (moved to public) > > The build system appears to be picking up the older ECPublicKeyImpl > class in the bootstrap JDK and not the newly built classes. 8054717 > appears to have modified bootclasspath settings. > > Is this an issue with my security fix or a build issue ? I've tried > the build on my local system and an JPRT. This could very well be related to 8054717. It's strange that it picks up ECPublicKeyImpl from the boostrap JDK though. We changed the build so that the bootclasspath is empty when compiling the JDK. What's the easiest way for me to reproduce this? Could I get a JPRT id and download your files somehow? (Sorry, I'm still learning JPRT.) -- Andreas From sean.coffey at oracle.com Tue Jun 16 08:28:31 2015 From: sean.coffey at oracle.com (=?windows-1252?Q?Se=E1n_Coffey?=) Date: Tue, 16 Jun 2015 09:28:31 +0100 Subject: Question around the 8054717 fix In-Reply-To: <20150616080453.GA568@e6430> References: <557ED381.9060200@oracle.com> <20150616080453.GA568@e6430> Message-ID: <557FDE2F.4010105@oracle.com> Andreas, thanks for getting back. Easiest way to reproduce this is probably by importing the jdk patch directly : http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/ http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/jdk.patch and then : gmake jdk.crypto.pkcs11 Regards, Sean. On 16/06/2015 09:04, Andreas Lundblad wrote: > On Mon, Jun 15, 2015 at 02:30:41PM +0100, Se?n Coffey wrote: >> Hi, >> >> I had a security library fix reviewed last week [1] and all was ok >> with builds back then. Today, I found that my build is broken and I >> think it's down to the changes introduced from the 8054717 fix. >> >> The build error (snippet) is : >> >>> /opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:74: error: ECPublicKeyImpl(byte[]) is not public in ECPublicKeyImpl; cannot be accessed from outside package >>> return new ECPublicKeyImpl(x509Spec.getEncoded()); >>> ^ >>> /opt/jprt/T/P1/081059.scoffey/s/jdk/src/jdk.crypto.pkcs11/share/classes/sun/security/pkcs11/P11ECUtil.java:77: error: constructor ECPublicKeyImpl in class ECPublicKeyImpl cannot be applied to given types; >>> return new ECPublicKeyImpl( >>> ^ >>> required: byte[] >>> found: ECPoint,ECParameterSpec >>> reason: actual and formal argument lists differ in length >> I've confirmed that I do have the correct access type modifications >> in the ECPublicKeyImpl constructor (moved to public) >> >> The build system appears to be picking up the older ECPublicKeyImpl >> class in the bootstrap JDK and not the newly built classes. 8054717 >> appears to have modified bootclasspath settings. >> >> Is this an issue with my security fix or a build issue ? I've tried >> the build on my local system and an JPRT. > This could very well be related to 8054717. > > It's strange that it picks up ECPublicKeyImpl from the boostrap JDK though. We changed the build so that the bootclasspath is empty when compiling the JDK. > > What's the easiest way for me to reproduce this? Could I get a JPRT id and download your files somehow? (Sorry, I'm still learning JPRT.) > > -- Andreas From andreas.lundblad at oracle.com Tue Jun 16 09:14:53 2015 From: andreas.lundblad at oracle.com (Andreas Lundblad) Date: Tue, 16 Jun 2015 11:14:53 +0200 Subject: Question around the 8054717 fix In-Reply-To: <557FDE2F.4010105@oracle.com> References: <557ED381.9060200@oracle.com> <20150616080453.GA568@e6430> <557FDE2F.4010105@oracle.com> Message-ID: <20150616091452.GB568@e6430> On Tue, Jun 16, 2015 at 09:28:31AM +0100, Se?n Coffey wrote: > Andreas, > > thanks for getting back. Easiest way to reproduce this is probably > by importing the jdk patch directly : > > http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/ > http://cr.openjdk.java.net/~coffeys/webrev.8080102.jdk9.v2/webrev/jdk.patch > > and then : gmake jdk.crypto.pkcs11 > > Regards, > Sean. Thanks. Will look into it. -- Andreas From sbaiduzh at redhat.com Tue Jun 16 10:46:27 2015 From: sbaiduzh at redhat.com (Stanislav Baiduzhyi) Date: Tue, 16 Jun 2015 12:46:27 +0200 Subject: distinguishing my jdk derivative by setting java_runtime_name In-Reply-To: <555A7638.4090405@oracle.com> References: <555A7638.4090405@oracle.com> Message-ID: <557FFE83.9030101@redhat.com> On 19/05/15 01:31, David Holmes wrote: > On 19/05/2015 6:19 AM, Brian Toal wrote: >> I'd like to be able to distinguish my openjdk build from others, by >> setting java_runtime_name to something that signifies my openjdk >> derivative. Is it possible to set java_runtime_name that's used >> in .//jdk/src/share/classes/sun/misc/Version.java.template via configure? > > I think you just edit common/autoconf/version-numbers > > David > >> How do others typically do this? I've been hunting all the refernces quite some time now, so here is what I've found so far: 1. Change vendor in jdk/src/share/native/java/lang/System.c . I was not able to do that with make options, so went the hard way and made a patch for myself. 2. Configure with --with-user-release-suffix="$USER_SUFFIX". That will affect output of 'java -version'. 3. Use make variables, that will affect the rest of system properties: make LAUNCHER_NAME=$USER_SUFFIX \ PRODUCT_NAME=$PRODUCT_NAME \ HOTSPOT_VM_DISTRO=$PRODUCT_NAME \ HOTSPOT_BUILD_VERSION=$USER_SUFFIX-$BUILD_NUMBER \ images If you will find more options to change - please post here as well. From mandy.chung at oracle.com Tue Jun 16 16:13:19 2015 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 16 Jun 2015 09:13:19 -0700 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557F668C.5090101@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> <557F668C.5090101@oracle.com> Message-ID: <7A152BA1-336C-40EB-B1AE-BAD31B254436@oracle.com> I skimmed it and looks okay to me. Thanks for separating this build work and avoid interfering the jimage refresh work. Mandy > On Jun 15, 2015, at 4:58 PM, Valerie Peng wrote: > > > It seems that the jimage refresh change may still take some time, so we will end up removing the makefile related changes and then deferring the ServiceLoader related changes to Jake workspace. > > Here is the latest webrev (Security source/test changes only, no more makefile changes) > http://cr.openjdk.java.net/~valeriep/7191662/webrev.04/ > > Summary of changes from webrev.03: > 1) switch back to provider class names for java.security file > 2) separated out the java.policy change into its own as SQE has filed a bug for it > 3) updated sun.security.jca.Providers class due to 1) > 4) fixed sun.security.tools.jarsigner.Main to use the new Provider.configure() api > 5) fixed a bug in sun.security.pkcs11.PKCS11Test regarding searching and configuring PKCS11 provider > > Thanks, > Valerie > > On 6/8/2015 4:44 PM, Valerie Peng wrote: >> >> What is the bug id for the image refresh change? Just so I can keep a watch and hold my changes for the time being. >> >> My webrev has a new regression test which compares the list of providers found by ServiceLoader and Security.getProviders() call. So, if the META-INF/services/java.security.Provider file content is not correct, the new test would fail and it's a clear indication that ServiceLoader can't find one or more of the providers. >> >> Thanks, >> Valerie >> >> On 6/5/2015 10:43 PM, Mandy Chung wrote: >>>> On Jun 5, 2015, at 4:32 PM, Valerie Peng wrote: >>>> >>>> >>>> I don't know image builder well enough to answer your question. >>> The current implementation of the image builder sorts the modules by their name that are mapped to the same class loader. That explains why java.naming is the first one containing META-INF/services/java.security.Provider in your current list. >>> >>> There is no guarantee in what particular order a module is processed first. I don?t know if the jimage refresh work will change the ordering either. Since this is temporary, I?m okay if you want to depend on the image build implementation as long as you have a test to catch it and verify java.naming/META-INF/services/java.security.Provider file content. The existing security tests may also catch it but I think it?s not obvious to indicate that the security tests fail because of the issue of the merged service configuration file. >>> >>> Please also hold off until the image refresh change goes into jdk9/dev so that you can verify if your build change still works. >>> >>> If you want to push earlier, another alternative we discussed earlier is to separate the META-INF/services file and make change and java.security to keep using classname. That can be pushed that in a second phase with a proper image builder support. >>> >>> Mandy >>> >>>> Based on my own experiment, it seems to pick up the one from java.naming when duplication occurs, so that's why I saved the merged result to there and named the Gensrc makefile with java.naming. The result build work fine. >>>> >>>> Does this explain what I am trying to do here? If you have better ways to get this done, I am certainly open to that idea. >>>> Thanks, >>>> Valerie >>>> >>>> On 6/5/2015 12:21 AM, Erik Joelsson wrote: >>>>> Hello Valerie, >>>>> >>>>> The merging seems ok, but I thought there was non determinism in the image builder regarding which provider would get picked up. Is that resolved or do you really need to override all of those providers with your generated file in gensrc? I can assist in writing that makefile logic if needed. >>>>> >>>>> /Erik >>>>> >>>>> On 2015-06-04 23:58, Valerie Peng wrote: >>>>>> Build experts, >>>>>> >>>>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: http://cr.openjdk.java.net/~valeriep/7191662/webrev.03 >>>>>> >>>>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>>>> >>>>>> Thanks, >>>>>> Valerie >>>>>> >>>>>> On 6/3/2015 10:27 AM, Valerie (Yu-Ching) Peng wrote: >>>>>>> Correct, if the makefile related changes are removed then no need for build team to review 7191662 webrev anymore. >>>>>>> There are other discussions ongoing and we should be able to reach a decision in a day or two. >>>>>>> Will update the list again. >>>>>>> Thanks, >>>>>>> Valerie >>>>>>> >>>>>>> On 06/01/15 16:39, Magnus Ihse Bursie wrote: >>>>>>>> On 2015-05-29 00:10, Valerie Peng wrote: >>>>>>>>> Please find comments in line... >>>>>>>>> >>>>>>>>> On 5/27/2015 3:42 PM, Mandy Chung wrote: >>>>>>>>>> Valerie, >>>>>>>>>> >>>>>>>>>> Did you see my comment yesterday? >>>>>>>>>> http://mail.openjdk.java.net/pipermail/security-dev/2015-May/012254.html >>>>>>>>> Yes, we exchanged emails after this above one. I will follow up your latest one later today. >>>>>>>>> >>>>>>>>>> Since you have reverted the java.security to keep the classname, to avoid causing merge conflict to jimage refresh, let?s remove the META-INF files in the first push and the build change. >>>>>>>>>> >>>>>>>>>> The security providers will be loaded via the fallback mechanism (i.e. ProviderLoader.legacyLoad method). You should keep the ProviderLoader.load method to take the provider name instead of classname. >>>>>>>>> Sure, I can remove the META-INF files so the providers are loaded through the legacyLoad(). >>>>>>>>> Hmm, the ProviderLoader.load() method is used by java.security file provider loading. Since the current list still uses class name, it should take class name when checking for matches while iterating through the list returned by ServiceLoader. >>>>>>>>> This way, when changes are sync'ed into Jake, no extra change required and the providers will be loaded through ProviderLoader.load() automatically with the current list. >>>>>>>>> >>>>>>>>>> I?ll file a bug to follow up to change java.security to list the provider name. This will wait after the jimage refresh goes into jdk9/dev >>>>>>>>> Ok. >>>>>>>>> Thanks, >>>>>>>>> Valerie >>>>>>>> I'm not sure I followed completely here were this landed. Does this mean that there's currently no need for a build system code review on http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/, and that a new webrev will be posted instead? >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>>> . >>>>>>>>>> >>>>>>>>>> Mandy >>>>>>>>>> >>>>>>>>>>> On May 27, 2015, at 3:29 PM, Valerie Peng wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, build experts, >>>>>>>>>>> >>>>>>>>>>> Can you please review the make file related change, i.e. the new file make/gensrc/Gensrc-java.naming.gmk, in the following webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~valeriep/7191662/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> This is for merging the java.security.Provider file from various providers and use the (merged) result for the final image build. >>>>>>>>>>> >>>>>>>>>>> The rest of source code changes are reviewed by my team already. >>>>>>>>>>> Thanks, >>>>>>>>>>> Valerie >>>>>>>>>>> (Java Security Team) From david.dehaven at oracle.com Tue Jun 16 18:11:37 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Tue, 16 Jun 2015 11:11:37 -0700 Subject: OpenJDK 8u45 on Yosemite In-Reply-To: <2395AA84-CB4D-4305-90A2-485DE896C9D9@gmail.com> References: <229B60BE-F829-473C-9B5C-A73A860E967D@gmail.com> <2395AA84-CB4D-4305-90A2-485DE896C9D9@gmail.com> Message-ID: <95EB7F24-38A4-4062-9301-FFA3612551CB@oracle.com> Excellent! -DrD- > Hi David > > jdk8u-dev build worked perfectly with ??with-code-path? option; no other patches were required! Thanks :-) > > Regards, > Manas > > > >> On 10-Jun-2015, at 10:22 am, Manas Thakur wrote: >> >> Okay, I found that I should use ?jdk8u-dev?, and not ?jdk8u?; ?with-xcode-path is a valid option there. >> I?ll update if I am able to build now. >> >> Regards, >> Manas >> >> >> >>> On 10-Jun-2015, at 9:19 am, Manas Thakur wrote: >>> >>> Hi David >>> >>> ?with-code-path is an unrecognised option; it?s not there in the configure script as well. >>> >>> Manas >>> >>> >>>> On 10-Jun-2015, at 2:41 am, David DeHaven wrote: >>>> >>>> >>>>> Hi all >>>>> >>>>> I had posted about problems with building openjdk8 on Mac OS X Yosemite last year. I am still unable to do the same. I did the following based on some posts tot he list in January: >>>>> >>>>> 1. bash configure ?with-tools-dir=?/Applications/Xcode4/Xcode.app/Contents/Developer/usr/bin/? >>>>> >>>>> 2. Applied the following patch to saproc.make: >>>>> - SALIBS = -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation >>>>> + SALIBS = -isysroot /Applications/Xcode4/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.8.sdk -g -framework Foundation -F/System/Library/Frameworks/JavaVM.framework/Frameworks -framework JavaNativeFoundation -framework Security -framework CoreFoundation >>>>> Now, the error shown is the following: >>>>> error: unable to open executable ?libjvm.dylib' >>>>> >>>>> What all should I do for a successful build? >>>> >>>> The backport of JDK-8043340 should have resolved this, this was done in time for 8u40. >>>> >>>> In short: don't use --with-tools-dir, use --with-xcode-path instead. >>>> >>>> >>>> There was a later fix to hotspot for building on Yosemite but it was too late for 8u40: >>>> changeset: 7161:10c237e58446 >>>> user: ddehaven >>>> date: Wed Mar 18 18:12:01 2015 -0700 >>>> summary: 8075400: Cannot build hotspot in jdk8u on OSX 10.10 (Yosemite) >>>> >>>> Patch: >>>> http://hg.openjdk.java.net/jdk8u/hs-dev/hotspot/rev/10c237e58446 >>>> >>>> You can try applying that to your workspace and see if it helps. >>>> >>>> -DrD- >>>> >>> >> > From Alan.Bateman at oracle.com Wed Jun 17 08:34:12 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Jun 2015 09:34:12 +0100 Subject: RFR 7191662: JCE providers should be located via ServiceLoader In-Reply-To: <557F668C.5090101@oracle.com> References: <55664547.7050002@oracle.com> <5567924B.5030604@oracle.com> <556CED19.5050700@oracle.com> <556F38F4.4070109@oracle.com> <5570CA21.7070309@oracle.com> <55714DF2.7090100@oracle.com> <557231A3.4040403@oracle.com> <29C2066D-F8EF-43C7-AAF6-48FFC6AB5A14@oracle.com> <557628F8.8000001@oracle.com> <557F668C.5090101@oracle.com> Message-ID: <55813104.7050109@oracle.com> On 16/06/2015 00:58, Valerie Peng wrote: > > It seems that the jimage refresh change may still take some time, so > we will end up removing the makefile related changes and then > deferring the ServiceLoader related changes to Jake workspace. > > Here is the latest webrev (Security source/test changes only, no more > makefile changes) > http://cr.openjdk.java.net/~valeriep/7191662/webrev.04/ > > Summary of changes from webrev.03: > 1) switch back to provider class names for java.security file > 2) separated out the java.policy change into its own as SQE has filed > a bug for it > 3) updated sun.security.jca.Providers class due to 1) > 4) fixed sun.security.tools.jarsigner.Main to use the new > Provider.configure() api > 5) fixed a bug in sun.security.pkcs11.PKCS11Test regarding searching > and configuring PKCS11 provider I'm also happy with dropping the make file changes and the META-INF/services files from this patch. Not for this patch but at some point I think we should re-examine the javadoc in Provider to make it clearer how it can be deployed as a service provider. Specifically the wording "A provider normally identifies itself with a file named java.security.Provider in the resource directory META-INF/services" could be re-examined. -Alan. From erik.joelsson at oracle.com Wed Jun 17 09:31:50 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Jun 2015 11:31:50 +0200 Subject: JDK 9 RFR of JDK-8098579: Remove non-existent javax.tools.annotation package from CORE_PKGS.gmk In-Reply-To: <557F07A5.3090209@oracle.com> References: <557F07A5.3090209@oracle.com> Message-ID: <55813E86.9080909@oracle.com> Hello Joe, Looks good to me. /Erik On 2015-06-15 19:13, joe darcy wrote: > Hello, > > Please review the fix below to address > > JDK-8098579: Remove non-existent javax.tools.annotation package > from CORE_PKGS.gmk > > Thanks, > > -Joe > > diff -r 1bcfd6b87265 make/common/CORE_PKGS.gmk > --- a/make/common/CORE_PKGS.gmk Thu Jun 11 20:18:41 2015 -0700 > +++ b/make/common/CORE_PKGS.gmk Mon Jun 15 10:07:11 2015 -0700 > @@ -222,7 +222,6 @@ > javax.swing.plaf.nimbus \ > javax.swing.plaf.synth \ > javax.tools \ > - javax.tools.annotation \ > javax.transaction \ > javax.transaction.xa \ > javax.xml.parsers \ > From erik.joelsson at oracle.com Wed Jun 17 09:33:27 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Jun 2015 11:33:27 +0200 Subject: RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version In-Reply-To: <557F4A7E.1080203@Oracle.com> References: <557F4A7E.1080203@Oracle.com> Message-ID: <55813EE7.9070409@oracle.com> Hello Roger, Build change looks fine to me. /Erik On 2015-06-15 23:58, Roger Riggs wrote: > Please review code for Windows 10 that sets the System properties for > os.name and os.version > from the version of kernel32.dll. The update uses the same technique > used by Hotspot > in src/os/windows/vm/os_windows.cpp. > > The Windows link of CoreLibraries.gmk includes version.lib/dll. > > The behavior of GetVersionEx has changed so it reports whatever > version the application > asserts it is compatible with instead of the current version of Windows. > See: > https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx > > The same change is desirable for 8u60. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-win-ver-8066504/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8066504 > > Thanks, Roger > From martijnverburg at gmail.com Wed Jun 17 10:00:07 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 17 Jun 2015 11:00:07 +0100 Subject: Error: SPEC mismatch! Current working directory does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR Message-ID: Hi all, Sitting in the build OpenJDK workshop at Devoxx UK and I have the following issue on Mac OS X (building jdk9). Error: SPEC mismatch! Current working directory /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9 ------- Seems to be related to: http://hg.openjdk.java.net/jdk9/jdk9/rev/f077ae77feb1 and/or http://hg.openjdk.java.net/jdk9/jdk9/rev/f658baecb743 ? ------- Full configure and command details: A new configuration has been successfully created in /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release using configure arguments '--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/'. Configuration summary: * Debug level: release * HS debug level: product * JDK variant: normal * JVM variants: server * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64 Tools summary: * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime Environment (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode) (at /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home) * Toolchain: clang (clang/LLVM) * C Compiler: Version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix (at /usr/bin/clang) * C++ Compiler: Version Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix (at /usr/bin/clang++) Build performance summary: * Cores to use: 4 * Memory limit: 16384 MB Martijns-MacBook-Pro:jdk9 karianna$ make clean install Compiling 5 files for BUILD_GENMODULESLIST Error: SPEC mismatch! Current working directory /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9 does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9 /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9 /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9 /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/make/Init.gmk:206: *** Cannot continue. Stop. make: *** [clean] Error 2 Cheers, Martijn From erik.joelsson at oracle.com Wed Jun 17 10:28:43 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 17 Jun 2015 12:28:43 +0200 Subject: Error: SPEC mismatch! Current working directory does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR In-Reply-To: References: Message-ID: <55814BDB.9050004@oracle.com> Hello Martijn, I believe this is a problem of string comparisons of file paths and character case. The file system on Macosx is case insensitive, but we aren't treating it as such properly. The difference is in the 'p' in 'project' in the directory name 'AdoptOpenJDK_projects'. The directory name on disk and the CWD are not in agreement of the case of that character. As a workaround, try CDing out and into the directory again but with the proper name and then rerun configure and make. /Erik On 2015-06-17 12:00, Martijn Verburg wrote: > Hi all, > > Sitting in the build OpenJDK workshop at Devoxx UK and I have the following > issue on Mac OS X (building jdk9). > > Error: SPEC mismatch! Current working directory > /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9 > > ------- > > Seems to be related to: > http://hg.openjdk.java.net/jdk9/jdk9/rev/f077ae77feb1 and/or > http://hg.openjdk.java.net/jdk9/jdk9/rev/f658baecb743 ? > > ------- > > Full configure and command details: > > A new configuration has been successfully created in > /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release > using configure arguments > '--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/'. > > Configuration summary: > * Debug level: release > * HS debug level: product > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64 > > Tools summary: > * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime Environment > (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, > mixed mode) (at > /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home) > * Toolchain: clang (clang/LLVM) > * C Compiler: Version Apple LLVM version 6.1.0 (clang-602.0.53) (based > on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix (at > /usr/bin/clang) > * C++ Compiler: Version Apple LLVM version 6.1.0 (clang-602.0.53) (based > on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix (at > /usr/bin/clang++) > > Build performance summary: > * Cores to use: 4 > * Memory limit: 16384 MB > > Martijns-MacBook-Pro:jdk9 karianna$ make clean install > Compiling 5 files for BUILD_GENMODULESLIST > Error: SPEC mismatch! Current working directory > /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9 > does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR > /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9 > /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9 > /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9 > /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/make/Init.gmk:206: > *** Cannot continue. Stop. > make: *** [clean] Error 2 > > Cheers, > Martijn From martijnverburg at gmail.com Wed Jun 17 10:46:53 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 17 Jun 2015 11:46:53 +0100 Subject: Error: SPEC mismatch! Current working directory does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR In-Reply-To: <55814BDB.9050004@oracle.com> References: <55814BDB.9050004@oracle.com> Message-ID: Hi Erik, Thanks, renaming the directory to match the casing got me past that step. I'm on the next issue now, I'll post with a separate subject. Cheers, Martijn On 17 June 2015 at 11:28, Erik Joelsson wrote: > Hello Martijn, > > I believe this is a problem of string comparisons of file paths and > character case. The file system on Macosx is case insensitive, but we > aren't treating it as such properly. The difference is in the 'p' in > 'project' in the directory name 'AdoptOpenJDK_projects'. The directory name > on disk and the CWD are not in agreement of the case of that character. As > a workaround, try CDing out and into the directory again but with the > proper name and then rerun configure and make. > > /Erik > > > On 2015-06-17 12:00, Martijn Verburg wrote: > >> Hi all, >> >> Sitting in the build OpenJDK workshop at Devoxx UK and I have the >> following >> issue on Mac OS X (building jdk9). >> >> Error: SPEC mismatch! Current working directory >> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9 >> >> ------- >> >> Seems to be related to: >> http://hg.openjdk.java.net/jdk9/jdk9/rev/f077ae77feb1 and/or >> http://hg.openjdk.java.net/jdk9/jdk9/rev/f658baecb743 ? >> >> ------- >> >> Full configure and command details: >> >> A new configuration has been successfully created in >> >> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-x86_64-normal-server-release >> using configure arguments >> >> '--with-boot-jdk=/Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home/'. >> >> Configuration summary: >> * Debug level: release >> * HS debug level: product >> * JDK variant: normal >> * JVM variants: server >> * OpenJDK target: OS: macosx, CPU architecture: x86, address length: 64 >> >> Tools summary: >> * Boot JDK: java version "1.8.0_45" Java(TM) SE Runtime Environment >> (build 1.8.0_45-b14) Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, >> mixed mode) (at >> /Library/Java/JavaVirtualMachines/jdk1.8.0_45.jdk/Contents/Home) >> * Toolchain: clang (clang/LLVM) >> * C Compiler: Version Apple LLVM version 6.1.0 (clang-602.0.53) (based >> on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix >> (at >> /usr/bin/clang) >> * C++ Compiler: Version Apple LLVM version 6.1.0 (clang-602.0.53) (based >> on LLVM 3.6.0svn) Target: x86_64-apple-darwin14.3.0 Thread model: posix >> (at >> /usr/bin/clang++) >> >> Build performance summary: >> * Cores to use: 4 >> * Memory limit: 16384 MB >> >> Martijns-MacBook-Pro:jdk9 karianna$ make clean install >> Compiling 5 files for BUILD_GENMODULESLIST >> Error: SPEC mismatch! Current working directory >> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9 >> does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR >> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9 >> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9 >> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9 >> >> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/make/Init.gmk:206: >> *** Cannot continue. Stop. >> make: *** [clean] Error 2 >> >> Cheers, >> Martijn >> > > From martijnverburg at gmail.com Wed Jun 17 11:06:20 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 17 Jun 2015 12:06:20 +0100 Subject: Mac OS X - error: out-of-line definition of 'getenv' does not match any declaration in 'os' in os_bsd.cpp Message-ID: Hi all, Building jdk9 on latest Mac OS X, XCode/Clang etc. Not sure if the Mac OS X build still needs to rely on BSD as such.... I'll dig further but figured it was worth reporting the initial error. ------- Note: Recompile with -Xlint:unchecked for details. /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/hotspot/src/os/bsd/vm/os_bsd.cpp:196:10: error: out-of-line definition of 'getenv' does not match any declaration in 'os' bool os::getenv(const char* name, char* buf, int len) { ^~~~~~ 1 error generated. make[10]: *** [os_bsd.o] Error 1 make[10]: *** Waiting for unfinished jobs.... make[9]: *** [the_vm] Error 2 make[8]: *** [product] Error 2 make[7]: *** [generic_build2] Error 2 make[6]: *** [product] Error 2 make[5]: *** [all_product_universal] Error 2 make[4]: *** [universal_product] Error 2 make[3]: *** [/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] Error 2 make[2]: *** [hotspot] Error 2 ERROR: Build failed for targets 'clean images' in configuration 'macosx-x86_64-normal-server-release' (exit code 2) Hint: If caused by a warning, try configure --disable-warnings-as-errors make[1]: *** [main] Error 2 make: *** [clean] Error 2 Cheers, Martijn From Alan.Bateman at oracle.com Wed Jun 17 11:32:41 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Jun 2015 12:32:41 +0100 Subject: RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version In-Reply-To: <557F4A7E.1080203@Oracle.com> References: <557F4A7E.1080203@Oracle.com> Message-ID: <55815AD9.8060904@oracle.com> On 15/06/2015 22:58, Roger Riggs wrote: > Please review code for Windows 10 that sets the System properties for > os.name and os.version > from the version of kernel32.dll. The update uses the same technique > used by Hotspot > in src/os/windows/vm/os_windows.cpp. > > The Windows link of CoreLibraries.gmk includes version.lib/dll. > > The behavior of GetVersionEx has changed so it reports whatever > version the application > asserts it is compatible with instead of the current version of Windows. > See: > https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx > > The same change is desirable for 8u60. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-win-ver-8066504/ Is it time to use the new version helper APIs and move away from GetVersionEx? I don't object to looking at the file version of kernel32.dll but I would think we should be looking to replace it soon (in hotspot too). Also, is there any update needed in src/windows/resource/java.manifest? In passing, GetNativeSystemInfo has been in Windows since Windows XP so I don't think we need to use GetModuleHandle to get the address now. -Alan From david.holmes at oracle.com Wed Jun 17 12:49:46 2015 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Jun 2015 22:49:46 +1000 Subject: Mac OS X - error: out-of-line definition of 'getenv' does not match any declaration in 'os' in os_bsd.cpp In-Reply-To: References: Message-ID: <55816CEA.1060705@oracle.com> On 17/06/2015 9:06 PM, Martijn Verburg wrote: > Hi all, > > Building jdk9 on latest Mac OS X, XCode/Clang etc. Not sure if the Mac OS > X build still needs to rely on BSD as such.... I'll dig further but > figured it was worth reporting the initial error. > > ------- > > Note: Recompile with -Xlint:unchecked for details. > /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/hotspot/src/os/bsd/vm/os_bsd.cpp:196:10: > error: out-of-line definition of 'getenv' does not match any declaration in > 'os' > bool os::getenv(const char* name, char* buf, int len) { os::getenv was removed. Are you working with an up to date and consistent source forest ?? David ^~~~~~ > 1 error generated. > make[10]: *** [os_bsd.o] Error 1 > make[10]: *** Waiting for unfinished jobs.... > make[9]: *** [the_vm] Error 2 > make[8]: *** [product] Error 2 > make[7]: *** [generic_build2] Error 2 > make[6]: *** [product] Error 2 > make[5]: *** [all_product_universal] Error 2 > make[4]: *** [universal_product] Error 2 > make[3]: *** > [/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] > Error 2 > make[2]: *** [hotspot] Error 2 > > ERROR: Build failed for targets 'clean images' in configuration > 'macosx-x86_64-normal-server-release' (exit code 2) > Hint: If caused by a warning, try configure --disable-warnings-as-errors > > make[1]: *** [main] Error 2 > make: *** [clean] Error 2 > > Cheers, > Martijn > From martijnverburg at gmail.com Wed Jun 17 13:25:15 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 17 Jun 2015 14:25:15 +0100 Subject: Mac OS X - error: out-of-line definition of 'getenv' does not match any declaration in 'os' in os_bsd.cpp In-Reply-To: <55816CEA.1060705@oracle.com> References: <55816CEA.1060705@oracle.com> Message-ID: Hi David, My bad, I was using http://hg.openjdk.java.net/jdk9/dev as opposed to http://hg.openjdk.java.net/jdk9/jdk9 - of course this leads to my third build issue which I'll post about with a separate title. Apologies all, I appreciate it's painful to deal with the endless queries on my part, please stack up the beverages score of what I owe all of you when we next meet in person! Cheers, Martijn On 17 June 2015 at 13:49, David Holmes wrote: > On 17/06/2015 9:06 PM, Martijn Verburg wrote: > >> Hi all, >> >> Building jdk9 on latest Mac OS X, XCode/Clang etc. Not sure if the Mac OS >> X build still needs to rely on BSD as such.... I'll dig further but >> figured it was worth reporting the initial error. >> >> ------- >> >> Note: Recompile with -Xlint:unchecked for details. >> >> /Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/hotspot/src/os/bsd/vm/os_bsd.cpp:196:10: >> error: out-of-line definition of 'getenv' does not match any declaration >> in >> 'os' >> bool os::getenv(const char* name, char* buf, int len) { >> > > os::getenv was removed. Are you working with an up to date and consistent > source forest ?? > > David > > > ^~~~~~ > >> 1 error generated. >> make[10]: *** [os_bsd.o] Error 1 >> make[10]: *** Waiting for unfinished jobs.... >> make[9]: *** [the_vm] Error 2 >> make[8]: *** [product] Error 2 >> make[7]: *** [generic_build2] Error 2 >> make[6]: *** [product] Error 2 >> make[5]: *** [all_product_universal] Error 2 >> make[4]: *** [universal_product] Error 2 >> make[3]: *** >> >> [/Users/karianna/Documents/workspace/AdoptOpenJDK_Projects/jdk9/build/macosx-x86_64-normal-server-release/hotspot/_hotspot.timestamp] >> Error 2 >> make[2]: *** [hotspot] Error 2 >> >> ERROR: Build failed for targets 'clean images' in configuration >> 'macosx-x86_64-normal-server-release' (exit code 2) >> Hint: If caused by a warning, try configure --disable-warnings-as-errors >> >> make[1]: *** [main] Error 2 >> make: *** [clean] Error 2 >> >> Cheers, >> Martijn >> >> From martijnverburg at gmail.com Wed Jun 17 13:41:46 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Wed, 17 Jun 2015 14:41:46 +0100 Subject: Build success! Message-ID: Hi all, In an attempt to be the most annoying person on build-dev in June (do you hand out prizes, because I'm totally winning). I'm now at the "error: comparison of array 'rasterP->sppsm.offsets' not equal to a null pointer is always true" bug aka https://bugs.openjdk.java.net/browse/JDK-8080993 The workaround suggested in that bug does the trick and I have jdk9 building once more. Thnaks all! Cheers, Martijn From Roger.Riggs at Oracle.com Wed Jun 17 13:49:05 2015 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 17 Jun 2015 09:49:05 -0400 Subject: RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version In-Reply-To: <55815AD9.8060904@oracle.com> References: <557F4A7E.1080203@Oracle.com> <55815AD9.8060904@oracle.com> Message-ID: <55817AD1.8070107@Oracle.com> Hi Alan, Would there be any concerns about backporting to JDK 8? On 6/17/2015 7:32 AM, Alan Bateman wrote: > On 15/06/2015 22:58, Roger Riggs wrote: >> Please review code for Windows 10 that sets the System properties for >> os.name and os.version >> from the version of kernel32.dll. The update uses the same technique >> used by Hotspot >> in src/os/windows/vm/os_windows.cpp. >> >> The Windows link of CoreLibraries.gmk includes version.lib/dll. >> >> The behavior of GetVersionEx has changed so it reports whatever >> version the application >> asserts it is compatible with instead of the current version of Windows. >> See: >> https://msdn.microsoft.com/en-us/library/windows/desktop/ms724451%28v=vs.85%29.aspx >> >> The same change is desirable for 8u60. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-win-ver-8066504/ > > Is it time to use the new version helper APIs and move away from > GetVersionEx? The new helper APIs only verify that the OS is at least the version requested. It does not reveal what version the OS is actually running on. Adding a manifest attribute just declares the minimum version required and is reported by GetVersionEx. In the current case, the code uses GetVersionEx as a fallback in case the version on kernel32.dll is not available. That fallback could be removed since kernel32.dll must exist on all supported versions. > > I don't object to looking at the file version of kernel32.dll but I > would think we should be looking to replace it soon (in hotspot too). The Hotspot version was updated by Christian to deal with the changes to GetVersionEx. In his view, it is more robust than the alternatives. The example given in MSDN to get the full version number : "To obtain the full version number for the operating system, call the *GetFileVersionInfo* function on one of the system DLLs, such as Kernel32.dll, then call *VerQueryValue* to obtain the \\StringFileInfo\\\\ProductVersion subblock of the file version information." An alternative is to use a cascade of IsWindowsOrGreater() calls to narrow in on it. But if there were a future version of Windows, os.name would report it as Windows 10. > > Also, is there any update needed in src/windows/resource/java.manifest? If using the version of kernel32.dll then the manifest version does not affect the value of os.name. But yes, I added the Windows 10 supportedOS uid. > > In passing, GetNativeSystemInfo has been in Windows since Windows XP > so I don't think we need to use GetModuleHandle to get the address now. ok. Similarly, can the case for Windows 3.1 be removed? (its not in theJDK 8 supported matrix ) caseVER_PLATFORM_WIN32s: Thanks, Roger > > -Alan From Alan.Bateman at oracle.com Wed Jun 17 13:58:10 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 17 Jun 2015 14:58:10 +0100 Subject: RFR 9/8: 8066504: GetVersionEx in java.base/windows/native/libjava/java_props_md.c might not get correct Windows version In-Reply-To: <55817AD1.8070107@Oracle.com> References: <557F4A7E.1080203@Oracle.com> <55815AD9.8060904@oracle.com> <55817AD1.8070107@Oracle.com> Message-ID: <55817CF2.3080401@oracle.com> On 17/06/2015 14:49, Roger Riggs wrote: > Hi Alan, > > Would there be any concerns about backporting to JDK 8? I don't think so but it will require the jdk8u maintainers to approve. > > The new helper APIs > > only verify that the OS is at least the version requested. > It does not reveal what version the OS is actually running on. > Adding a manifest attribute just declares the minimum version required > and is reported by GetVersionEx. > In the current case, the code uses GetVersionEx as a fallback in > case the version on kernel32.dll is not available. > That fallback could be removed since kernel32.dll must exist on all > supported versions. Okay, I thought the helper APIs had better support than this. Maybe the Microsoft folks that are contributing to OpenJDK might have suggestions. In general I don't have any objections to the approach, just thought it was a big odd that the OS forces us to look at the version of kernel32.dll. > : > >> >> Also, is there any update needed in src/windows/resource/java.manifest? > If using the version of kernel32.dll then the manifest version does > not affect the value of os.name. > But yes, I added the Windows 10 supportedOS uid. I don't think this was in the first webrev that I saw but I see it is there now, looks fine. >> >> In passing, GetNativeSystemInfo has been in Windows since Windows XP >> so I don't think we need to use GetModuleHandle to get the address now. > ok. > > Similarly, can the case for Windows 3.1 be removed? (its not in > theJDK 8 supported matrix > ) > caseVER_PLATFORM_WIN32s: I think that would be a fine cleanup. -Alan. From erik.joelsson at oracle.com Thu Jun 18 07:57:20 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 18 Jun 2015 09:57:20 +0200 Subject: RFR: JDK-8080915: [macosx] JDK 9 installation does not add java info to the java_home plist Message-ID: <558279E0.5050303@oracle.com> Hello, Please review this trivial fix for mac bundles. In JDK-8078058, the logic for generating the Info.plist files was changed. The problem is that when introducing the SetupTextProcessing macro for generating these files, actually including the definition of the macro was forgotten. The fix is to simply add the proper include. I have verified that with this fix, Info.plist is build like before. Bug: https://bugs.openjdk.java.net/browse/JDK-8080915 Patch inline: diff -r 704d642602d3 make/MacBundles.gmk --- a/make/MacBundles.gmk +++ b/make/MacBundles.gmk @@ -25,6 +25,7 @@ include $(SPEC) include MakeBase.gmk +include TextFileProcessing.gmk default: bundles /Erik From erik.joelsson at oracle.com Thu Jun 18 09:14:03 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 18 Jun 2015 11:14:03 +0200 Subject: RFR: JDK-8081814: Modularize the deploy build Message-ID: <55828BDB.2020900@oracle.com> Hello, Here is a review of the open changes needed for an Oracle internal change. The open changes should not affect the build but are mostly just providing more hooks for customizations or generalizing concepts. The changes have already been reviewed internally by Magnus Ihse and David DeHaven, but posting here for transparency and, of course, in case someone else have something to add. Bug: https://bugs.openjdk.java.net/browse/JDK-8081814 Webrev: http://cr.openjdk.java.net/~erikj/8081814/webrev.01/ /Erik From tim.bell at oracle.com Thu Jun 18 14:14:50 2015 From: tim.bell at oracle.com (Tim Bell) Date: Thu, 18 Jun 2015 07:14:50 -0700 Subject: RFR: JDK-8080915: [macosx] JDK 9 installation does not add java info to the java_home plist In-Reply-To: <558279E0.5050303@oracle.com> References: <558279E0.5050303@oracle.com> Message-ID: <5582D25A.8070507@oracle.com> Erik: > Please review this trivial fix for mac bundles. In JDK-8078058, the > logic for generating the Info.plist files was changed. The problem is > that when introducing the SetupTextProcessing macro for generating > these files, actually including the definition of the macro was > forgotten. The fix is to simply add the proper include. I have > verified that with this fix, Info.plist is build like before. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8080915 > > Patch inline: > diff -r 704d642602d3 make/MacBundles.gmk > --- a/make/MacBundles.gmk > +++ b/make/MacBundles.gmk > @@ -25,6 +25,7 @@ > > include $(SPEC) > include MakeBase.gmk > +include TextFileProcessing.gmk > > default: bundles Looks good to me. /Tim From david.dehaven at oracle.com Thu Jun 18 22:06:17 2015 From: david.dehaven at oracle.com (David DeHaven) Date: Thu, 18 Jun 2015 15:06:17 -0700 Subject: Error: SPEC mismatch! Current working directory does not match either TOPDIR, ORIGINAL_TOPDIR or CANONICAL_TOPDIR In-Reply-To: <55814BDB.9050004@oracle.com> References: <55814BDB.9050004@oracle.com> Message-ID: <4F7099E7-EB48-4D44-B17F-78CE4F8826F1@oracle.com> > I believe this is a problem of string comparisons of file paths and character case. The file system on Macosx is case insensitive, but we aren't treating it as such properly. Filesystem is not (it's optional in HFS+ actually, defaulting to insensitive), but tools might be, specifically those of Unix-y origins. -DrD- From masayoshi.okutsu at oracle.com Fri Jun 19 08:53:43 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Fri, 19 Jun 2015 17:53:43 +0900 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <557601F7.5060209@oracle.com> References: <557601F7.5060209@oracle.com> Message-ID: <5583D897.30605@oracle.com> Sorry for taking time. Here are my comments. src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: - The year range of the first line of the copyright header should be "2015," for the new ones and "2013, 2015," for the updated ones. - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines because some line spacing is wide in the webrev. (hard to determine that from the webrev.) src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: - applyParentLocales() needs to be thread-safe with parentLocalesMap? src/java.base/share/classes/sun/util/resources/LocaleData.java: - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() implementations should return an optimized candidate list rather than removing unsupported Locales from the list there. test/sun/text/resources/LocaleDataTest.java: + * -cldr option specifies to test CLDR locale data. The default data file name for this + * option is "CLDRLocaleData". - The file name should be "LocaleData.cldr"? test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: - added the bug id, but no changes to the test? Thanks, Masayoshi On 6/9/2015 5:58 AM, Naoto Sato wrote: > Hello, > > Please review the proposed changes for 8008577[1], the implementation > of the JEP-252[2]. The proposed changes are located at: > > http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ > > Here are the very high level summary of changes: > > - Now the default locale provider order is CLDR,JRE,SPI. > - The CLDR data is upgraded from 21.0.1 to 27.0.0 > - According the CLDR upgrade, the converter tool and the runtime are > now capable of "alias" and "parentLocales" tags. > - Regression tests that are specific to the existing JRE locale data > are now run specifically with "JRE,SPI" providers. > > I would like the build group to review the build changes mainly with > the CLDR changes, and i18n group for the rest. > > Naoto > -- > [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 > [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 From claes.redestad at oracle.com Tue Jun 9 13:26:27 2015 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 09 Jun 2015 15:26:27 +0200 Subject: RFR: JDK-8085822 JEP 223: New Version-String Scheme (initial integration) In-Reply-To: <5576E633.9050503@oracle.com> References: <5571AD18.7080701@oracle.com> <557625C8.5050200@oracle.com> <5576E633.9050503@oracle.com> Message-ID: <5576E983.5020902@oracle.com> On 2015-06-09 15:12, Magnus Ihse Bursie wrote: >> langtools/src/java.compiler/share/classes/javax/lang/model/SourceVersion.java >> >> old L171: case "1.9": >> new L171: case "9": >> Should this logic support both versions? Will dropping >> "1.9" here prevent a pre-version changeset JVM from >> being dropped into a JDK for triage purposes? >> >> Granted we don't often triage 'javac' with different JVMs, >> but... > I'll defer that question to Kumar, who wrote that piece of code. My > guess is that when Hotspot express was dropped, the ability to use a > JVM from another JDK release bit rotteded away. > > /Magnus While we know there's no guarantee that swapping in an older VM will work, in the face of a regression in a promoted build we still routinely (automatically, even) swap out the VM with a recent VM to get a rough estimate of whether the regression was caused by a HotSpot or JDK/tools change, mostly since this currently saves us time in narrowing down the changes to bisect over/investigate. So, there's at least some value in not intentionally breaking build-to-build backwards compatibility, but we don't expect it to always work and wouldn't make much fuss about it breaking. If an extra case "1.9" is all it takes to make it work with last week's VM, however... /Claes From erik.joelsson at oracle.com Mon Jun 22 08:25:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 22 Jun 2015 10:25:21 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5582D4CB.9090109@oracle.com> References: <5582D4CB.9090109@oracle.com> Message-ID: <5587C671.1040508@oracle.com> Hello Jan, Build changes look mostly ok. Some notes: * "$(CFLAGS_WARNINGS_ARE_ERRORS)", which should not be used anymore. Warnings are already treated as errors globally. * There should not be a need to add "-I$(INCLUDEDIR) -I$(JDK_OUTPUTDIR)/include/$(OPENJDK_TARGET_OS)" to cflags. INCLUDEDIR is undefined AFAIK, and the other dir is already in CFLAGS_JDKLIB. I'm guessing that you copied Lib-jdk.jdi.gmk as a template. Is the -DUSE_MMAP just an artifact of that copy or do you know that it is needed? /Erik On 2015-06-18 16:25, Jan Lahoda wrote: > Hello, > > I am proposing to add JLine 2.12.1 into the jdk repository for use by > the Java and Nashorn REPLs. Full patch is available here: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ > > To aid the review, I've split this patch into to smaller patches: > -a patch that only adds unmodified jline sources at appropriate places > in the jdk repository: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ > > -a patch that shows the additional changes I've done: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ > > This split is intended solely to simplify reviewing, my plan is to > integrate this as a single patch. > > The main additional changes are: > -plugging the new module, jdk.jline, into the JDK build. Currently, > the JLine packages are exported only to jdk.scripting.nashorn (the > plan is to also export them to the future jdk.jshell module). (The > patch is not adding the dependency from jdk.scripting.nashorn to > jdk.jline, though - I expect that to be added when needed.) > -the sources are re-packaged from package "jline" to "jdk.internal.jline" > -removing trailing whitespace, adding newlines at the end of the > files, encoding characters that are not ASCII > -avoiding the dependency on another library, jansi, by reimplementing > two elements that were used from the other library. These are mainly > the changes in WindowsTerminal and ConsoleReader.java. This also > includes the WindowsTerminal.cpp native library. The native part is > heavily inspired by: > http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html > > As I am not experienced in native programming, comments to the native > part would be particularly useful. > -changes to resolve javac warnings in JLine. > -tests for some of the added functionality. > > Any comments are welcome! > > Thanks, > Jan From jan.lahoda at oracle.com Mon Jun 22 11:23:39 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Mon, 22 Jun 2015 13:23:39 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5587C671.1040508@oracle.com> References: <5582D4CB.9090109@oracle.com> <5587C671.1040508@oracle.com> Message-ID: <5587F03B.8000505@oracle.com> Hi Erik, Thanks for the comments. Yes, I copied an existing file, and -DUSE_MMAP seems unnecessary. I'll implement your suggestions. Thanks, Jan On 22.6.2015 10:25, Erik Joelsson wrote: > Hello Jan, > > Build changes look mostly ok. Some notes: > > * "$(CFLAGS_WARNINGS_ARE_ERRORS)", which should not be used anymore. > Warnings are already treated as errors globally. > > * There should not be a need to add "-I$(INCLUDEDIR) > -I$(JDK_OUTPUTDIR)/include/$(OPENJDK_TARGET_OS)" to cflags. INCLUDEDIR > is undefined AFAIK, and the other dir is already in CFLAGS_JDKLIB. > > I'm guessing that you copied Lib-jdk.jdi.gmk as a template. Is the > -DUSE_MMAP just an artifact of that copy or do you know that it is needed? > > /Erik > > On 2015-06-18 16:25, Jan Lahoda wrote: >> Hello, >> >> I am proposing to add JLine 2.12.1 into the jdk repository for use by >> the Java and Nashorn REPLs. Full patch is available here: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ >> >> To aid the review, I've split this patch into to smaller patches: >> -a patch that only adds unmodified jline sources at appropriate places >> in the jdk repository: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ >> >> -a patch that shows the additional changes I've done: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ >> >> This split is intended solely to simplify reviewing, my plan is to >> integrate this as a single patch. >> >> The main additional changes are: >> -plugging the new module, jdk.jline, into the JDK build. Currently, >> the JLine packages are exported only to jdk.scripting.nashorn (the >> plan is to also export them to the future jdk.jshell module). (The >> patch is not adding the dependency from jdk.scripting.nashorn to >> jdk.jline, though - I expect that to be added when needed.) >> -the sources are re-packaged from package "jline" to "jdk.internal.jline" >> -removing trailing whitespace, adding newlines at the end of the >> files, encoding characters that are not ASCII >> -avoiding the dependency on another library, jansi, by reimplementing >> two elements that were used from the other library. These are mainly >> the changes in WindowsTerminal and ConsoleReader.java. This also >> includes the WindowsTerminal.cpp native library. The native part is >> heavily inspired by: >> http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html >> >> As I am not experienced in native programming, comments to the native >> part would be particularly useful. >> -changes to resolve javac warnings in JLine. >> -tests for some of the added functionality. >> >> Any comments are welcome! >> >> Thanks, >> Jan > From erik.joelsson at oracle.com Tue Jun 23 08:07:27 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 23 Jun 2015 10:07:27 +0200 Subject: RFR: JDK-8129503: The SOURCE value in release file of JDK 9 doesn't contain changesets since b49 Message-ID: <558913BF.1090007@oracle.com> Hello, Please review this small fix for the source-tips generation, which is used in the release file to identify the exact sources a build was made from. In JDK-8065576, we added "-e -o pipefail" to the default shell args. This causes shell expressions which are chained with ';' to abort when a sub expression fails. In the definition for REPO_LIST, the first 'ls' would fail if there were no .hg files to be found and so the second 'ls' would never be run to find the .hgtip files. I see no reason for separate calls to 'ls'. The -d flag does not hurt when looking for the .hgtip files. Bug: https://bugs.openjdk.java.net/browse/JDK-8129503 Patch: diff -r eed77fcd7771 make/common/MakeBase.gmk --- a/make/common/MakeBase.gmk +++ b/make/common/MakeBase.gmk @@ -369,8 +369,9 @@ HGTIP_FILENAME=.hgtip HG_SEARCH = ./REPO ./*/REPO ./*/*/REPO ./*/*/*/REPO REPO_LIST = $(patsubst ./%,%,$(patsubst %/,%,$(sort $(dir \ - $(shell $(CD) $(SRC_ROOT) ; ( $(LS) -d $(HG_SEARCH:%/REPO=%/$(HG_DIRECTORY)) ; \ - $(LS) $(HG_SEARCH:%/REPO=%/$(HGTIP_FILENAME)) ) \ + $(shell $(CD) $(SRC_ROOT) ; \ + $(LS) -d $(HG_SEARCH:%/REPO=%/$(HG_DIRECTORY)) \ + $(HG_SEARCH:%/REPO=%/$(HGTIP_FILENAME)) \ 2> /dev/null))))) # Emit the repo:tip pairs to $@ /Erik From tim.bell at oracle.com Tue Jun 23 12:55:16 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 23 Jun 2015 05:55:16 -0700 Subject: RFR: JDK-8129503: The SOURCE value in release file of JDK 9 doesn't contain changesets since b49 In-Reply-To: <558913BF.1090007@oracle.com> References: <558913BF.1090007@oracle.com> Message-ID: <55895734.4070804@oracle.com> Erik: > Please review this small fix for the source-tips generation, which is > used in the release file to identify the exact sources a build was > made from. > > In JDK-8065576, we added "-e -o pipefail" to the default shell args. > This causes shell expressions which are chained with ';' to abort when > a sub expression fails. In the definition for REPO_LIST, the first > 'ls' would fail if there were no .hg files to be found and so the > second 'ls' would never be run to find the .hgtip files. I see no > reason for separate calls to 'ls'. The -d flag does not hurt when > looking for the .hgtip files. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129503 > > Patch: > diff -r eed77fcd7771 make/common/MakeBase.gmk > --- a/make/common/MakeBase.gmk > +++ b/make/common/MakeBase.gmk > @@ -369,8 +369,9 @@ > HGTIP_FILENAME=.hgtip > HG_SEARCH = ./REPO ./*/REPO ./*/*/REPO ./*/*/*/REPO > REPO_LIST = $(patsubst ./%,%,$(patsubst %/,%,$(sort $(dir \ > - $(shell $(CD) $(SRC_ROOT) ; ( $(LS) -d > $(HG_SEARCH:%/REPO=%/$(HG_DIRECTORY)) ; \ > - $(LS) $(HG_SEARCH:%/REPO=%/$(HGTIP_FILENAME)) ) \ > + $(shell $(CD) $(SRC_ROOT) ; \ > + $(LS) -d $(HG_SEARCH:%/REPO=%/$(HG_DIRECTORY)) \ > + $(HG_SEARCH:%/REPO=%/$(HGTIP_FILENAME)) \ > 2> /dev/null))))) > > # Emit the repo:tip pairs to $@ Looks good to me. Tim From naoto.sato at oracle.com Tue Jun 23 21:56:35 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 23 Jun 2015 14:56:35 -0700 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <5583D897.30605@oracle.com> References: <557601F7.5060209@oracle.com> <5583D897.30605@oracle.com> Message-ID: <5589D613.308@oracle.com> Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8008577/webrev.01/ As to the 3rd comment below, I did not modify it because that would simply duplicate the same piece of code in each getCandidateLocales() implementation (from the current location). Naoto On 6/19/15 1:53 AM, Masayoshi Okutsu wrote: > Sorry for taking time. Here are my comments. > > src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: > > - The year range of the first line of the copyright header should be > "2015," for the new ones and "2013, 2015," for the updated ones. > - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines > because some line spacing is wide in the webrev. (hard to determine that > from the webrev.) > > src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: > - applyParentLocales() needs to be thread-safe with parentLocalesMap? > > src/java.base/share/classes/sun/util/resources/LocaleData.java: > - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() > implementations should return an optimized candidate list rather than > removing unsupported Locales from the list there. > > test/sun/text/resources/LocaleDataTest.java: > > + * -cldr option specifies to test CLDR locale data. The default data > file name for this > + * option is "CLDRLocaleData". > > - The file name should be "LocaleData.cldr"? > > test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: > - added the bug id, but no changes to the test? > > Thanks, > Masayoshi > > On 6/9/2015 5:58 AM, Naoto Sato wrote: >> Hello, >> >> Please review the proposed changes for 8008577[1], the implementation >> of the JEP-252[2]. The proposed changes are located at: >> >> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >> >> Here are the very high level summary of changes: >> >> - Now the default locale provider order is CLDR,JRE,SPI. >> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >> - According the CLDR upgrade, the converter tool and the runtime are >> now capable of "alias" and "parentLocales" tags. >> - Regression tests that are specific to the existing JRE locale data >> are now run specifically with "JRE,SPI" providers. >> >> I would like the build group to review the build changes mainly with >> the CLDR changes, and i18n group for the rest. >> >> Naoto >> -- >> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 > From masayoshi.okutsu at oracle.com Wed Jun 24 09:16:54 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Wed, 24 Jun 2015 18:16:54 +0900 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <5589D613.308@oracle.com> References: <557601F7.5060209@oracle.com> <5583D897.30605@oracle.com> <5589D613.308@oracle.com> Message-ID: <558A7586.1080603@oracle.com> applyParentLocales() sets parentLocalesMap before populating the map with data. It's possible that other threads look up the map without the (full) data. So, a Map (local variable) should be populated and then parentLocalesMap should be set to the Map. Also, parentLocalesMap needs to be volatile or synchronized should be used when setting it. I don't think it's necessary to use ConcurrentHashMap if the map is not modified after its initialization. Otherwise, the changes look good to me. Masayoshi On 6/24/2015 6:56 AM, Naoto Sato wrote: > Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8008577/webrev.01/ > > As to the 3rd comment below, I did not modify it because that would > simply duplicate the same piece of code in each getCandidateLocales() > implementation (from the current location). > > Naoto > > On 6/19/15 1:53 AM, Masayoshi Okutsu wrote: >> Sorry for taking time. Here are my comments. >> >> src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: >> >> >> - The year range of the first line of the copyright header should be >> "2015," for the new ones and "2013, 2015," for the updated ones. >> - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines >> because some line spacing is wide in the webrev. (hard to determine that >> from the webrev.) >> >> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: >> >> - applyParentLocales() needs to be thread-safe with parentLocalesMap? >> >> src/java.base/share/classes/sun/util/resources/LocaleData.java: >> - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() >> implementations should return an optimized candidate list rather than >> removing unsupported Locales from the list there. >> >> test/sun/text/resources/LocaleDataTest.java: >> >> + * -cldr option specifies to test CLDR locale data. The default data >> file name for this >> + * option is "CLDRLocaleData". >> >> - The file name should be "LocaleData.cldr"? >> >> test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: >> - added the bug id, but no changes to the test? >> >> Thanks, >> Masayoshi >> >> On 6/9/2015 5:58 AM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the proposed changes for 8008577[1], the implementation >>> of the JEP-252[2]. The proposed changes are located at: >>> >>> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >>> >>> Here are the very high level summary of changes: >>> >>> - Now the default locale provider order is CLDR,JRE,SPI. >>> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >>> - According the CLDR upgrade, the converter tool and the runtime are >>> now capable of "alias" and "parentLocales" tags. >>> - Regression tests that are specific to the existing JRE locale data >>> are now run specifically with "JRE,SPI" providers. >>> >>> I would like the build group to review the build changes mainly with >>> the CLDR changes, and i18n group for the rest. >>> >>> Naoto >>> -- >>> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >>> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 >> From jan.lahoda at oracle.com Wed Jun 24 13:13:15 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 24 Jun 2015 15:13:15 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556DDEEC.2000505@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> Message-ID: <558AACEB.8030006@oracle.com> Hello, After some offline discussions, I've somewhat changed the internal API for plugging in the platforms (based on Jon's advices). An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.05/langtools/ How does this look? Thanks for all the comments! Jan On 2.6.2015 18:50, Jan Lahoda wrote: > Hello Eric, > > Thanks for the change, this seems definitely better to me. I've folded > your change that into my patch. An updated version (just langtools this > time): > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ > > Thanks! > > Jan > > On 2.6.2015 16:04, Erik Joelsson wrote: >> Hello Jan, >> >> Sorry to bother you with even more build changes, but with these file >> moves, I realized that this new file, ct.sym, is really a part of the >> jdk.compiler module and really not a special case at all. Because of >> this, it should be generated as part of the jdk.compiler-gendata target. >> This also eliminates all the changes in the top level repo and only >> leaves one new makefile in the langtools repo. >> >> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >> >> /Erik >> >> On 2015-06-01 17:56, Jan Lahoda wrote: >>> Hi, >>> >>> I made a somewhat bigger update (partially based on other feedback). >>> Summary of changes: >>> -the history data has been moved into langtools (I also moved the >>> Ctsym.gmk) >>> -there are JDK 6 data now >>> -renamed the "-platform" option to "-release". Code/tests directly >>> related to the option has been also changed as well. I kept the >>> internal PlatformProvider API in javac as is, and also kept related >>> code. >>> -added a note that the is generated by >>> CreateSymbols. >>> >>> Webrevs: >>> top-level: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>> langtools: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>> >>> Delta webrevs are also available. >>> >>> How does this look? >>> >>> Thanks for the comments so far! >>> >>> Jan >>> >>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>> Ah, yes, I did not realize that. Thanks, will fix. >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>> don't mention the fact that a side effect of the sym.txt generation is >>>>> the mentioned earlier in the same >>>>> comments >>>>> (so one might wonder where does that come from). >>>>> >>>>> Maurizio >>>>> >>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I've uploaded another iteration, with these changes: >>>>>> -the "symbols" file is now generated automatically (for the typical >>>>>> OpenJDK case). >>>>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>>>> description into wrong a file (the "break" -> "break OUTER;" change). >>>>>> -jdk.management module has been split out from java.management >>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>> java.management and jdk.management as well. >>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>> >>>>>> Webrevs: >>>>>> -top-level: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>> -langtools (no changes against the last webrev): >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>> >>>>>> Delta webrevs against the previous iteration are included under >>>>>> "Author comments". >>>>>> >>>>>> Thanks for the comments so far! >>>>>> >>>>>> Jan >>>>>> >>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>> Excellent work. >>>>>>>> >>>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>>> Probe >>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>> >>>>>>>> /bin/java Probe --> classes-8 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> >>>>>>>> etc. >>>>>>> >>>>>>> Sure, will do. >>>>>>> >>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>> descriptions >>>>>>> automatically, per our offline discussion. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>> top-level repository: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>> langtools: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>> >>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>> differences >>>>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>>>> "Author's comments") >>>>>>>>> >>>>>>>>> Summary of changes: >>>>>>>>> -applied Eric's build changes >>>>>>>>> -moved CreateSymbols into >>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> great work - couple of comments below: >>>>>>>>>> >>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>> simplified >>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>> checkOptionAllowed >>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>> commonalities >>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>> this a >>>>>>>>>> bit? >>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>> specified >>>>>>>>>> and >>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>> that, >>>>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>> logic in >>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>> CreateSymbols >>>>>>>>>> with >>>>>>>>>> how the files were laid out. I think in the end, what you mean is >>>>>>>>>> that >>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>> (i.e. 8) >>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>> that's the >>>>>>>>>> use >>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>> order to >>>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>>> the >>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>> seem to be typically all >>>>>>>>>> identical >>>>>>>>>> but one which is set to - the one for the baseline). Maybe >>>>>>>>>> the >>>>>>>>>> inference logic should be different (i.e. use 8 as a baseline for >>>>>>>>>> 7 and >>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>> should be >>>>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>>>> there >>>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>> >>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>> >>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>> >>>>>>>>>>> These changes also require additional langtools changes as their >>>>>>>>>>> prerequisite: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>> effect as >>>>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>>>> values >>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>> correspond to >>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>> >>>>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>>>> N. The >>>>>>>>>>> proposal is to include history data in the textual format inside >>>>>>>>>>> the >>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>> time >>>>>>>>>>> and >>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>> javac >>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>> lib/ct.sym >>>>>>>>>>> file. The input history data are placed >>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>> This >>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>> public >>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>> >>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>> checkout and >>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>> significantly >>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>> would >>>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>>> >>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>> them as >>>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>>> Code >>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>> named >>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>> bootclasspath >>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>> 'N' in >>>>>>>>>>> their name. >>>>>>>>>>> >>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>>> Concise >>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> I am sending this as one review, as the changes together make >>>>>>>>>>> one >>>>>>>>>>> feature, but the langtools and top-level changes are independent >>>>>>>>>>> to a >>>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>>> and the >>>>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>>>> ct.sym >>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>> independently. >>>>>>>>>>> >>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>> Alan >>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>> matter >>>>>>>>>>> before. >>>>>>>>>>> >>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jan >>>>>>>>>> >>>>>>>> >>>>> >> From naoto.sato at oracle.com Wed Jun 24 16:15:09 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 24 Jun 2015 09:15:09 -0700 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <558A7586.1080603@oracle.com> References: <557601F7.5060209@oracle.com> <5583D897.30605@oracle.com> <5589D613.308@oracle.com> <558A7586.1080603@oracle.com> Message-ID: <558AD78D.1010407@oracle.com> Thanks. Here is the diff from "webrev.01" to address your comment: http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/b8faab65bb62 Naoto On 6/24/15 2:16 AM, Masayoshi Okutsu wrote: > applyParentLocales() sets parentLocalesMap before populating the map > with data. It's possible that other threads look up the map without the > (full) data. So, a Map (local variable) should be populated and then > parentLocalesMap should be set to the Map. Also, parentLocalesMap needs > to be volatile or synchronized should be used when setting it. I don't > think it's necessary to use ConcurrentHashMap if the map is not modified > after its initialization. > > Otherwise, the changes look good to me. > > Masayoshi > > On 6/24/2015 6:56 AM, Naoto Sato wrote: >> Here is the updated webrev: >> >> http://cr.openjdk.java.net/~naoto/8008577/webrev.01/ >> >> As to the 3rd comment below, I did not modify it because that would >> simply duplicate the same piece of code in each getCandidateLocales() >> implementation (from the current location). >> >> Naoto >> >> On 6/19/15 1:53 AM, Masayoshi Okutsu wrote: >>> Sorry for taking time. Here are my comments. >>> >>> src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: >>> >>> >>> - The year range of the first line of the copyright header should be >>> "2015," for the new ones and "2013, 2015," for the updated ones. >>> - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines >>> because some line spacing is wide in the webrev. (hard to determine that >>> from the webrev.) >>> >>> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: >>> >>> - applyParentLocales() needs to be thread-safe with parentLocalesMap? >>> >>> src/java.base/share/classes/sun/util/resources/LocaleData.java: >>> - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() >>> implementations should return an optimized candidate list rather than >>> removing unsupported Locales from the list there. >>> >>> test/sun/text/resources/LocaleDataTest.java: >>> >>> + * -cldr option specifies to test CLDR locale data. The default data >>> file name for this >>> + * option is "CLDRLocaleData". >>> >>> - The file name should be "LocaleData.cldr"? >>> >>> test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: >>> - added the bug id, but no changes to the test? >>> >>> Thanks, >>> Masayoshi >>> >>> On 6/9/2015 5:58 AM, Naoto Sato wrote: >>>> Hello, >>>> >>>> Please review the proposed changes for 8008577[1], the implementation >>>> of the JEP-252[2]. The proposed changes are located at: >>>> >>>> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >>>> >>>> Here are the very high level summary of changes: >>>> >>>> - Now the default locale provider order is CLDR,JRE,SPI. >>>> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >>>> - According the CLDR upgrade, the converter tool and the runtime are >>>> now capable of "alias" and "parentLocales" tags. >>>> - Regression tests that are specific to the existing JRE locale data >>>> are now run specifically with "JRE,SPI" providers. >>>> >>>> I would like the build group to review the build changes mainly with >>>> the CLDR changes, and i18n group for the rest. >>>> >>>> Naoto >>>> -- >>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >>>> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 >>> > From masayoshi.okutsu at oracle.com Wed Jun 24 23:14:11 2015 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 25 Jun 2015 08:14:11 +0900 Subject: [9] RFR: 8008577: Use CLDR Locale Data by Default (JEP-252) In-Reply-To: <558AD78D.1010407@oracle.com> References: <557601F7.5060209@oracle.com> <5583D897.30605@oracle.com> <5589D613.308@oracle.com> <558A7586.1080603@oracle.com> <558AD78D.1010407@oracle.com> Message-ID: <558B39C3.5060400@oracle.com> Looks good to me. Masayoshi On 6/25/2015 1:15 AM, Naoto Sato wrote: > Thanks. Here is the diff from "webrev.01" to address your comment: > > http://hg.openjdk.java.net/jdk9/sandbox/jdk/rev/b8faab65bb62 > > Naoto > > On 6/24/15 2:16 AM, Masayoshi Okutsu wrote: >> applyParentLocales() sets parentLocalesMap before populating the map >> with data. It's possible that other threads look up the map without the >> (full) data. So, a Map (local variable) should be populated and then >> parentLocalesMap should be set to the Map. Also, parentLocalesMap needs >> to be volatile or synchronized should be used when setting it. I don't >> think it's necessary to use ConcurrentHashMap if the map is not modified >> after its initialization. >> >> Otherwise, the changes look good to me. >> >> Masayoshi >> >> On 6/24/2015 6:56 AM, Naoto Sato wrote: >>> Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~naoto/8008577/webrev.01/ >>> >>> As to the 3rd comment below, I did not modify it because that would >>> simply duplicate the same piece of code in each getCandidateLocales() >>> implementation (from the current location). >>> >>> Naoto >>> >>> On 6/19/15 1:53 AM, Masayoshi Okutsu wrote: >>>> Sorry for taking time. Here are my comments. >>>> >>>> src/jdk.localedata/share/classes/sun/text/resources/*JavaTimeSupplementary*.java: >>>> >>>> >>>> >>>> - The year range of the first line of the copyright header should be >>>> "2015," for the new ones and "2013, 2015," for the updated ones. >>>> - I wonder if JavaTimeSupplementary*.java contain some CR-LF lines >>>> because some line spacing is wide in the webrev. (hard to determine >>>> that >>>> from the webrev.) >>>> >>>> src/java.base/share/classes/sun/util/cldr/CLDRLocaleProviderAdapter.java: >>>> >>>> >>>> - applyParentLocales() needs to be thread-safe with >>>> parentLocalesMap? >>>> >>>> src/java.base/share/classes/sun/util/resources/LocaleData.java: >>>> - I wonder if the ResourceBundleBasedAdapter.getCandidateLocales() >>>> implementations should return an optimized candidate list rather than >>>> removing unsupported Locales from the list there. >>>> >>>> test/sun/text/resources/LocaleDataTest.java: >>>> >>>> + * -cldr option specifies to test CLDR locale data. The default data >>>> file name for this >>>> + * option is "CLDRLocaleData". >>>> >>>> - The file name should be "LocaleData.cldr"? >>>> >>>> test/java/text/Format/DecimalFormat/RoundingAndPropertyTest.java: >>>> - added the bug id, but no changes to the test? >>>> >>>> Thanks, >>>> Masayoshi >>>> >>>> On 6/9/2015 5:58 AM, Naoto Sato wrote: >>>>> Hello, >>>>> >>>>> Please review the proposed changes for 8008577[1], the implementation >>>>> of the JEP-252[2]. The proposed changes are located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8008577/webrev.00/ >>>>> >>>>> Here are the very high level summary of changes: >>>>> >>>>> - Now the default locale provider order is CLDR,JRE,SPI. >>>>> - The CLDR data is upgraded from 21.0.1 to 27.0.0 >>>>> - According the CLDR upgrade, the converter tool and the runtime are >>>>> now capable of "alias" and "parentLocales" tags. >>>>> - Regression tests that are specific to the existing JRE locale data >>>>> are now run specifically with "JRE,SPI" providers. >>>>> >>>>> I would like the build group to review the build changes mainly with >>>>> the CLDR changes, and i18n group for the rest. >>>>> >>>>> Naoto >>>>> -- >>>>> [1]: https://bugs.openjdk.java.net/browse/JDK-8008577 >>>>> [2]: https://bugs.openjdk.java.net/browse/JDK-8043554 >>>> >> From aph at redhat.com Thu Jun 25 12:52:37 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jun 2015 13:52:37 +0100 Subject: Building on Solaris Message-ID: <558BF995.8080709@redhat.com> Sorry to bother you, but I'm really stuck. I'm trying to build on Solaris 11. I've installed solarisstudio12.3 and added it to my path, and all the dependencies. Configured like this: sh ./configure --with-debug-level=slowdebug --with-jvm-variants=server --disable-zip-debug-info --with-boot-jdk=/usr/jdk/latest --disable-warnings-as-errors ... using configure arguments '--with-debug-level=slowdebug --with-jvm-variants=server --disable-zip-debug-info --with-boot-jdk=/usr/jdk/latest --disable-warnings-as-errors'. Configuration summary: * Debug level: slowdebug * HS debug level: debug * JDK variant: normal * JVM variants: server * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 64 Tools summary: * Boot JDK: java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) (at /usr/jdk/latest) * Toolchain: solstudio (Oracle Solaris Studio) * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) Build performance summary: * Cores to use: 5 * Memory limit: 8192 MB But: $ gmake wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp: No such file or directory Compiling files for BUILD_GENMODULESLIST javac: file not found: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp (No such file or directory) Building target 'default' in configuration 'solaris-x86_64-normal-server-slowdebug' wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp: No such file or directory Compiling files for BUILD_GENMODULESLIST javac: file not found: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp (No such file or directory) wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp: No such file or directory wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp: No such file or directory Compiling files for BUILD_GENMODULESLIST Compiling 8 files for BUILD_TOOLS_LANGTOOLS Compiling files for BUILD_GENMODULESLIST javac: file not found: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp (No such file or directory) javac: file not found: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp (No such file or directory) Compiling 5 files for java.annotations.common Compiling 24 files for java.activation Error: Could not find or load main class com.sun.tools.javac.Main gmake[3]: *** [/export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/jdk/modules/java.annotations.common/_the.java.annotations.common_batch] Error 1 gmake[2]: *** [java.annotations.common-java] Error 1 gmake[2]: *** Waiting for unfinished jobs.... Error: Could not find or load main class com.sun.tools.javac.Main gmake[3]: *** [/export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/jdk/modules/java.activation/_the.java.activation_batch] Error 1 gmake[2]: *** [java.activation-java] Error 1 I've been building OpenJDK for years on Linux, but this problem has me completely baffled. Is there any special advice for building on Solaris? I expected it would just work. I'm guessing that this point in the build is the failure: gmake[3]: Entering directory `/export/home/aph/hs-comp-latest/make' /usr/bin/mkdir -p /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist /usr/bin/rm -f /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp /usr/bin/echo Writing 0 paths to ' >> /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp' Writing 0 paths to >> /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp /usr/bin/echo Compiling `/usr/bin/wc /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp | /usr/bin/tr -s ' ' | /usr/bin/cut -f 2 -d ' '` files for BUILD_GENMODULESLIST wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_G "Writing 0 paths" must be wrong. Thanks, Andrew. From erik.joelsson at oracle.com Thu Jun 25 13:03:34 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Jun 2015 15:03:34 +0200 Subject: Building on Solaris In-Reply-To: <558BF995.8080709@redhat.com> References: <558BF995.8080709@redhat.com> Message-ID: <558BFC26.2000607@oracle.com> Hello Andrew, You are correct in that it "should just work". What's failing here is part of bootstrapping the top level makefile targets. The logic for this can be found in make/common/Modules.gmk. What happens there is that a java tool is built and then used to convert modules.xml into a list of module dependencies that the makefiles can interpret. The failure you see is in trying to build this tool. The makefile is trying to find the tool classes, but finds none: Writing 0 paths to >> /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp Then javac fails when the @file that should contain the classes to compile doesn't exist. Can you check that you have $(JDK_TOPDIR)/make/src/classes/build/tools/module in your source tree? /Erik On 2015-06-25 14:52, Andrew Haley wrote: > Sorry to bother you, but I'm really stuck. > > I'm trying to build on Solaris 11. I've installed solarisstudio12.3 and > added it to my path, and all the dependencies. > > Configured like this: > > sh ./configure --with-debug-level=slowdebug --with-jvm-variants=server --disable-zip-debug-info --with-boot-jdk=/usr/jdk/latest --disable-warnings-as-errors > > ... > using configure arguments '--with-debug-level=slowdebug --with-jvm-variants=server --disable-zip-debug-info --with-boot-jdk=/usr/jdk/latest --disable-warnings-as-errors'. > > Configuration summary: > * Debug level: slowdebug > * HS debug level: debug > * JDK variant: normal > * JVM variants: server > * OpenJDK target: OS: solaris, CPU architecture: x86, address length: 64 > > Tools summary: > * Boot JDK: java version "1.8.0_05" Java(TM) SE Runtime Environment (build 1.8.0_05-b13) Java HotSpot(TM) 64-Bit Server VM (build 25.5-b02, mixed mode) (at /usr/jdk/latest) > * Toolchain: solstudio (Oracle Solaris Studio) > * C Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/cc) > * C++ Compiler: Version 5.12 (at /opt/solarisstudio12.3/bin/CC) > > Build performance summary: > * Cores to use: 5 > * Memory limit: 8192 MB > > > But: > > $ gmake > wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp: No such file or directory > Compiling files for BUILD_GENMODULESLIST > javac: file not found: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp (No such file or directory) > Building target 'default' in configuration 'solaris-x86_64-normal-server-slowdebug' > wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp: No such file or directory > Compiling files for BUILD_GENMODULESLIST > javac: file not found: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp (No such file or directory) > wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp: No such file or directory > wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp: No such file or directory > Compiling files for BUILD_GENMODULESLIST > Compiling 8 files for BUILD_TOOLS_LANGTOOLS > Compiling files for BUILD_GENMODULESLIST > javac: file not found: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp (No such file or directory) > javac: file not found: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp (No such file or directory) > Compiling 5 files for java.annotations.common > Compiling 24 files for java.activation > Error: Could not find or load main class com.sun.tools.javac.Main > gmake[3]: *** [/export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/jdk/modules/java.annotations.common/_the.java.annotations.common_batch] Error 1 > gmake[2]: *** [java.annotations.common-java] Error 1 > gmake[2]: *** Waiting for unfinished jobs.... > Error: Could not find or load main class com.sun.tools.javac.Main > gmake[3]: *** [/export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/jdk/modules/java.activation/_the.java.activation_batch] Error 1 > gmake[2]: *** [java.activation-java] Error 1 > > I've been building OpenJDK for years on Linux, but this problem has me > completely baffled. Is there any special advice for building on > Solaris? I expected it would just work. > > I'm guessing that this point in the build is the failure: > > gmake[3]: Entering directory `/export/home/aph/hs-comp-latest/make' > /usr/bin/mkdir -p /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist > /usr/bin/rm -f /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp > /usr/bin/echo Writing 0 paths to ' >> /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp' > Writing 0 paths to >> /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp > /usr/bin/echo Compiling `/usr/bin/wc /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_GENMODULESLIST_batch.tmp | /usr/bin/tr -s ' ' | /usr/bin/cut -f 2 -d ' '` files for BUILD_GENMODULESLIST > wc: /export/home/aph/hs-comp-latest/build/solaris-x86_64-normal-server-slowdebug/make-support/bt_classes_moduleslist/_the.BUILD_G > > "Writing 0 paths" must be wrong. > > Thanks, > Andrew. From aph at redhat.com Thu Jun 25 13:15:02 2015 From: aph at redhat.com (Andrew Haley) Date: Thu, 25 Jun 2015 14:15:02 +0100 Subject: Building on Solaris In-Reply-To: <558BFC26.2000607@oracle.com> References: <558BF995.8080709@redhat.com> <558BFC26.2000607@oracle.com> Message-ID: <558BFED6.4040301@redhat.com> On 06/25/2015 02:03 PM, Erik Joelsson wrote: > Can you check that you have > $(JDK_TOPDIR)/make/src/classes/build/tools/module in your source tree? Ah yes, that's a problem. Somehow a ton of files is missing in there. I'll rebuild from a clean tree. Thanks, Andrew. From erik.joelsson at oracle.com Thu Jun 25 13:25:30 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Jun 2015 15:25:30 +0200 Subject: RFR: JDK-8087328: Move debuglevel info in version string from PRE to OPT Message-ID: <558C014A.5030807@oracle.com> Hello, Please review this change to the new build number implementation in project Verona. This change is intended to go into the verona forest for now until it's time for integration into jdk9. In Magnus' original version string implementation, the debuglevel information is encoded into the PRE string. According to the latest status of JEP-223, it should rather be a part of the OPT string. In this patch, I have made that move. This means that the (relevant) configure options have changed from: --with-version-pre-base --with-version-pre-debuglevel --with-version-opt into: --with-version-pre --with-version-opt-base --with-version-opt-debuglevel I also had to introduce some way of telling the OPT_BASE string apart from the OPT_DEBUGLEVEL string when parsing a full version string. In the PRE string, the separator was a '.' but since that character is a valid part of the OPT string, something else is needed. I went with underscore '_' for now. Bug: https://bugs.openjdk.java.net/browse/JDK-8087328 Webrev: http://cr.openjdk.java.net/~erikj/8087328/webrev.01/ /Erik From erik.joelsson at oracle.com Thu Jun 25 14:09:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 25 Jun 2015 16:09:02 +0200 Subject: RFR: JDK-8087329: Introduce VERSION_IS_GA Message-ID: <558C0B7E.3060102@oracle.com> Hello, Please review this change to the new build number implementation in project Verona. This change is intended to go into the Verona forest for now until it's time for integration into jdk9. By definition, the way to determine from the version string if a release is a GA release or a pre-release is to check if the PRE string is empty. If it is empty, it's a GA release, otherwise it's not. While this is logical from a theoretical point of view, it is not immediately obvious to developers. One place in the OpenJDK where such a check is done is make/Javadoc.gmk. In this patch, a new make variable is introduced: VERSION_IS_GA, which can be either true or false. Bug: https://bugs.openjdk.java.net/browse/JDK-8087329 Webrev: http://cr.openjdk.java.net/~erikj/8087329/webrev.01/ /Erik From jan.lahoda at oracle.com Thu Jun 25 16:25:04 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Thu, 25 Jun 2015 18:25:04 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <5582D4CB.9090109@oracle.com> References: <5582D4CB.9090109@oracle.com> Message-ID: <558C2B60.6060502@oracle.com> Hello, Based on the feedback I've received so far, I've uploaded an updated version of the patch: http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ Notable changes: -avoided the dependency on java.desktop and java.datatransfer -adjusted the native library build script as per Erik's recommendations -the module name is now changed to jdk.internal.le Any comments are welcome! Thanks, Jan On 18.6.2015 16:25, Jan Lahoda wrote: > Hello, > > I am proposing to add JLine 2.12.1 into the jdk repository for use by > the Java and Nashorn REPLs. Full patch is available here: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ > > To aid the review, I've split this patch into to smaller patches: > -a patch that only adds unmodified jline sources at appropriate places > in the jdk repository: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ > > -a patch that shows the additional changes I've done: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ > > This split is intended solely to simplify reviewing, my plan is to > integrate this as a single patch. > > The main additional changes are: > -plugging the new module, jdk.jline, into the JDK build. Currently, the > JLine packages are exported only to jdk.scripting.nashorn (the plan is > to also export them to the future jdk.jshell module). (The patch is not > adding the dependency from jdk.scripting.nashorn to jdk.jline, though - > I expect that to be added when needed.) > -the sources are re-packaged from package "jline" to "jdk.internal.jline" > -removing trailing whitespace, adding newlines at the end of the files, > encoding characters that are not ASCII > -avoiding the dependency on another library, jansi, by reimplementing > two elements that were used from the other library. These are mainly the > changes in WindowsTerminal and ConsoleReader.java. This also includes > the WindowsTerminal.cpp native library. The native part is heavily > inspired by: > http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html > > As I am not experienced in native programming, comments to the native > part would be particularly useful. > -changes to resolve javac warnings in JLine. > -tests for some of the added functionality. > > Any comments are welcome! > > Thanks, > Jan From Alan.Bateman at oracle.com Thu Jun 25 16:38:08 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 25 Jun 2015 17:38:08 +0100 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <558C2B60.6060502@oracle.com> References: <5582D4CB.9090109@oracle.com> <558C2B60.6060502@oracle.com> Message-ID: <558C2E70.4050704@oracle.com> On 25/06/2015 17:25, Jan Lahoda wrote: > Hello, > > Based on the feedback I've received so far, I've uploaded an updated > version of the patch: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ > > Notable changes: > -avoided the dependency on java.desktop and java.datatransfer > -adjusted the native library build script as per Erik's recommendations > -the module name is now changed to jdk.internal.le > > Any comments are welcome! The new home and the dropping of the dependences on java.desktop & java.datatransfer look good. Since there only 2 tests then it might be better to add jdk/internal/jline to the mixed bag that is jdk_other. That way you don't need to update update jprt.properties and other places where the groups are used. The native method readKeyEvent seems to do a FindClass per key event. Maybe this is from the upstream project but I would think it would be more efficient to cache this in a global ref. It would also be more efficient if the INPUT_RECORD were just returned and avoid the upstream to create the object but that might be too much to change when you are trying to keep the code in sync with upstream. -Alan From jonathan.gibbons at oracle.com Thu Jun 25 21:32:42 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 25 Jun 2015 14:32:42 -0700 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <558AACEB.8030006@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> <558AACEB.8030006@oracle.com> Message-ID: <558C737A.6010405@oracle.com> Looks good to me :-) -- Jon On 06/24/2015 06:13 AM, Jan Lahoda wrote: > Hello, > > After some offline discussions, I've somewhat changed the internal API > for plugging in the platforms (based on Jon's advices). An updated > webrev is here: > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.05/langtools/ > > How does this look? > > Thanks for all the comments! > > Jan > > On 2.6.2015 18:50, Jan Lahoda wrote: >> Hello Eric, >> >> Thanks for the change, this seems definitely better to me. I've folded >> your change that into my patch. An updated version (just langtools this >> time): >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ >> >> Thanks! >> >> Jan >> >> On 2.6.2015 16:04, Erik Joelsson wrote: >>> Hello Jan, >>> >>> Sorry to bother you with even more build changes, but with these file >>> moves, I realized that this new file, ct.sym, is really a part of the >>> jdk.compiler module and really not a special case at all. Because of >>> this, it should be generated as part of the jdk.compiler-gendata >>> target. >>> This also eliminates all the changes in the top level repo and only >>> leaves one new makefile in the langtools repo. >>> >>> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >>> >>> /Erik >>> >>> On 2015-06-01 17:56, Jan Lahoda wrote: >>>> Hi, >>>> >>>> I made a somewhat bigger update (partially based on other feedback). >>>> Summary of changes: >>>> -the history data has been moved into langtools (I also moved the >>>> Ctsym.gmk) >>>> -there are JDK 6 data now >>>> -renamed the "-platform" option to "-release". Code/tests directly >>>> related to the option has been also changed as well. I kept the >>>> internal PlatformProvider API in javac as is, and also kept related >>>> code. >>>> -added a note that the is generated by >>>> CreateSymbols. >>>> >>>> Webrevs: >>>> top-level: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>>> langtools: >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>>> >>>> Delta webrevs are also available. >>>> >>>> How does this look? >>>> >>>> Thanks for the comments so far! >>>> >>>> Jan >>>> >>>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>>> Ah, yes, I did not realize that. Thanks, will fix. >>>>> >>>>> Thanks, >>>>> Jan >>>>> >>>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>>> don't mention the fact that a side effect of the sym.txt >>>>>> generation is >>>>>> the mentioned earlier in the same >>>>>> comments >>>>>> (so one might wonder where does that come from). >>>>>> >>>>>> Maurizio >>>>>> >>>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>>> Hi, >>>>>>> >>>>>>> I've uploaded another iteration, with these changes: >>>>>>> -the "symbols" file is now generated automatically (for the typical >>>>>>> OpenJDK case). >>>>>>> -fixed a minor issue in CreateSymbols that could cause putting >>>>>>> class >>>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>>> change). >>>>>>> -jdk.management module has been split out from java.management >>>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>>> java.management and jdk.management as well. >>>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>>> >>>>>>> Webrevs: >>>>>>> -top-level: >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>>> -langtools (no changes against the last webrev): >>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>>> >>>>>>> Delta webrevs against the previous iteration are included under >>>>>>> "Author comments". >>>>>>> >>>>>>> Thanks for the comments so far! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>>> Excellent work. >>>>>>>>> >>>>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>>>> Probe >>>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>>> >>>>>>>>> /bin/java Probe --> classes-8 >>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>> >>>>>>>>> etc. >>>>>>>> >>>>>>>> Sure, will do. >>>>>>>> >>>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>>> descriptions >>>>>>>> automatically, per our offline discussion. >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>>> >>>>>>>>> Maurizio >>>>>>>>> >>>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>>> top-level repository: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>>> langtools: >>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>>> >>>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>>> differences >>>>>>>>>> between .00 and .01 available - see the "Delta webrev" link >>>>>>>>>> under >>>>>>>>>> "Author's comments") >>>>>>>>>> >>>>>>>>>> Summary of changes: >>>>>>>>>> -applied Eric's build changes >>>>>>>>>> -moved CreateSymbols into >>>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>>> Hi Jan, >>>>>>>>>>> great work - couple of comments below: >>>>>>>>>>> >>>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>>> simplified >>>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>>> checkOptionAllowed >>>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>>> commonalities >>>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>>> this a >>>>>>>>>>> bit? >>>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>>> specified >>>>>>>>>>> and >>>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>>> that, >>>>>>>>>>> ignore the platform settings and issue a Lint 'options' >>>>>>>>>>> warning? >>>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>>> logic in >>>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>>> CreateSymbols >>>>>>>>>>> with >>>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>>> mean is >>>>>>>>>>> that >>>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>>> (i.e. 8) >>>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>>> that's the >>>>>>>>>>> use >>>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>>> order to >>>>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>>>> the >>>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>>> seem to be typically all >>>>>>>>>>> identical >>>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>>> Maybe >>>>>>>>>>> the >>>>>>>>>>> inference logic should be different (i.e. use 8 as a >>>>>>>>>>> baseline for >>>>>>>>>>> 7 and >>>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>>> should be >>>>>>>>>>> chosen once and for all, and live implicitly in the tool? Or >>>>>>>>>>> are >>>>>>>>>>> there >>>>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>>>> >>>>>>>>>>> Maurizio >>>>>>>>>>> >>>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>>> >>>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>>> their >>>>>>>>>>>> prerequisite: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>>> >>>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>>> effect as >>>>>>>>>>>> '-source N -target N -bootclasspath '. The >>>>>>>>>>>> possible >>>>>>>>>>>> values >>>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>>> correspond to >>>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>>> >>>>>>>>>>>> A tricky problem to solve is where to get the APIs for >>>>>>>>>>>> platform >>>>>>>>>>>> N. The >>>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>>> inside >>>>>>>>>>>> the >>>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>>> time >>>>>>>>>>>> and >>>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>>> javac >>>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>>> lib/ct.sym >>>>>>>>>>>> file. The input history data are placed >>>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>>> This >>>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>>> public >>>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>>> >>>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>>> checkout and >>>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>>> significantly >>>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>>> would >>>>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>>>> >>>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>>> them as >>>>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>>>> Code >>>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>>> named >>>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>>> bootclasspath >>>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>>> 'N' in >>>>>>>>>>>> their name. >>>>>>>>>>>> >>>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>>>> Concise >>>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>>> >>>>>>>>>>>> I am sending this as one review, as the changes together make >>>>>>>>>>>> one >>>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>>> independent >>>>>>>>>>>> to a >>>>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>>>> and the >>>>>>>>>>>> top-level changes add the history data and ability to build >>>>>>>>>>>> the >>>>>>>>>>>> ct.sym >>>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>>> independently. >>>>>>>>>>>> >>>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>>> Alan >>>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>>> matter >>>>>>>>>>>> before. >>>>>>>>>>>> >>>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jan >>>>>>>>>>> >>>>>>>>> >>>>>> >>> From magnus.ihse.bursie at oracle.com Thu Jun 25 22:41:13 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 26 Jun 2015 00:41:13 +0200 Subject: RFR: JDK-8087329: Introduce VERSION_IS_GA In-Reply-To: <558C0B7E.3060102@oracle.com> References: <558C0B7E.3060102@oracle.com> Message-ID: <558C8389.6000403@oracle.com> On 2015-06-25 16:09, Erik Joelsson wrote: > Hello, > > Please review this change to the new build number implementation in > project Verona. This change is intended to go into the Verona forest > for now until it's time for integration into jdk9. > > By definition, the way to determine from the version string if a > release is a GA release or a pre-release is to check if the PRE string > is empty. If it is empty, it's a GA release, otherwise it's not. While > this is logical from a theoretical point of view, it is not > immediately obvious to developers. One place in the OpenJDK where such > a check is done is make/Javadoc.gmk. > > In this patch, a new make variable is introduced: VERSION_IS_GA, which > can be either true or false. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087329 > Webrev: http://cr.openjdk.java.net/~erikj/8087329/webrev.01/ > > /Erik Looks good to me. /Magnus From magnus.ihse.bursie at oracle.com Thu Jun 25 22:46:19 2015 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 26 Jun 2015 00:46:19 +0200 Subject: RFR: JDK-8087328: Move debuglevel info in version string from PRE to OPT In-Reply-To: <558C014A.5030807@oracle.com> References: <558C014A.5030807@oracle.com> Message-ID: <558C84BB.1030601@oracle.com> On 2015-06-25 15:25, Erik Joelsson wrote: > Hello, > > Please review this change to the new build number implementation in > project Verona. This change is intended to go into the verona forest > for now until it's time for integration into jdk9. > > In Magnus' original version string implementation, the debuglevel > information is encoded into the PRE string. According to the latest > status of JEP-223, it should rather be a part of the OPT string. In > this patch, I have made that move. > > This means that the (relevant) configure options have changed from: > > --with-version-pre-base > --with-version-pre-debuglevel > --with-version-opt > > into: > > --with-version-pre > --with-version-opt-base > --with-version-opt-debuglevel > > I also had to introduce some way of telling the OPT_BASE string apart > from the OPT_DEBUGLEVEL string when parsing a full version string. In > the PRE string, the separator was a '.' but since that character is a > valid part of the OPT string, something else is needed. I went with > underscore '_' for now. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8087328 > Webrev: http://cr.openjdk.java.net/~erikj/8087328/webrev.01/ Looks good to me. Note that this solution will require an update to the JEP-223 spec, to allow underscore (_) to be an allowed character in the OPT string. (Since, from the spec's point, both OPT_BASE and OPT_DEBUGLEVEL are arbitrary divisions of the formal OPT string.) /Magnus From david.holmes at oracle.com Fri Jun 26 05:34:34 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 15:34:34 +1000 Subject: Building on Solaris In-Reply-To: <558BFED6.4040301@redhat.com> References: <558BF995.8080709@redhat.com> <558BFC26.2000607@oracle.com> <558BFED6.4040301@redhat.com> Message-ID: <558CE46A.6080203@oracle.com> On 25/06/2015 11:15 PM, Andrew Haley wrote: > On 06/25/2015 02:03 PM, Erik Joelsson wrote: >> Can you check that you have >> $(JDK_TOPDIR)/make/src/classes/build/tools/module in your source tree? > > Ah yes, that's a problem. Somehow a ton of files is missing in there. > > I'll rebuild from a clean tree. Also note that we use a devkit from Solaris 10u10 when building on S11. Building natively on S11 make not work. David > Thanks, > Andrew. > From erik.joelsson at oracle.com Fri Jun 26 07:34:34 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jun 2015 09:34:34 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <558C2B60.6060502@oracle.com> References: <5582D4CB.9090109@oracle.com> <558C2B60.6060502@oracle.com> Message-ID: <558D008A.5050205@oracle.com> Hello Jan, Build changes look good. /Erik On 2015-06-25 18:25, Jan Lahoda wrote: > Hello, > > Based on the feedback I've received so far, I've uploaded an updated > version of the patch: > http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ > > Notable changes: > -avoided the dependency on java.desktop and java.datatransfer > -adjusted the native library build script as per Erik's recommendations > -the module name is now changed to jdk.internal.le > > Any comments are welcome! > > Thanks, > Jan > > On 18.6.2015 16:25, Jan Lahoda wrote: >> Hello, >> >> I am proposing to add JLine 2.12.1 into the jdk repository for use by >> the Java and Nashorn REPLs. Full patch is available here: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/full/ >> >> To aid the review, I've split this patch into to smaller patches: >> -a patch that only adds unmodified jline sources at appropriate places >> in the jdk repository: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/clean-jline/ >> >> -a patch that shows the additional changes I've done: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.00/additional/ >> >> This split is intended solely to simplify reviewing, my plan is to >> integrate this as a single patch. >> >> The main additional changes are: >> -plugging the new module, jdk.jline, into the JDK build. Currently, the >> JLine packages are exported only to jdk.scripting.nashorn (the plan is >> to also export them to the future jdk.jshell module). (The patch is not >> adding the dependency from jdk.scripting.nashorn to jdk.jline, though - >> I expect that to be added when needed.) >> -the sources are re-packaged from package "jline" to >> "jdk.internal.jline" >> -removing trailing whitespace, adding newlines at the end of the files, >> encoding characters that are not ASCII >> -avoiding the dependency on another library, jansi, by reimplementing >> two elements that were used from the other library. These are mainly the >> changes in WindowsTerminal and ConsoleReader.java. This also includes >> the WindowsTerminal.cpp native library. The native part is heavily >> inspired by: >> http://cr.openjdk.java.net/~sherman/rl/src/java.base/windows/native/libjava/Console_md.c.html >> >> >> As I am not experienced in native programming, comments to the native >> part would be particularly useful. >> -changes to resolve javac warnings in JLine. >> -tests for some of the added functionality. >> >> Any comments are welcome! >> >> Thanks, >> Jan From erik.joelsson at oracle.com Fri Jun 26 07:35:21 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jun 2015 09:35:21 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <556DDEEC.2000505@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> Message-ID: <558D00B9.7090706@oracle.com> This looks good to me now. /Erik On 2015-06-02 18:50, Jan Lahoda wrote: > Hello Eric, > > Thanks for the change, this seems definitely better to me. I've folded > your change that into my patch. An updated version (just langtools > this time): > http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ > > Thanks! > > Jan > > On 2.6.2015 16:04, Erik Joelsson wrote: >> Hello Jan, >> >> Sorry to bother you with even more build changes, but with these file >> moves, I realized that this new file, ct.sym, is really a part of the >> jdk.compiler module and really not a special case at all. Because of >> this, it should be generated as part of the jdk.compiler-gendata target. >> This also eliminates all the changes in the top level repo and only >> leaves one new makefile in the langtools repo. >> >> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >> >> /Erik >> >> On 2015-06-01 17:56, Jan Lahoda wrote: >>> Hi, >>> >>> I made a somewhat bigger update (partially based on other feedback). >>> Summary of changes: >>> -the history data has been moved into langtools (I also moved the >>> Ctsym.gmk) >>> -there are JDK 6 data now >>> -renamed the "-platform" option to "-release". Code/tests directly >>> related to the option has been also changed as well. I kept the >>> internal PlatformProvider API in javac as is, and also kept related >>> code. >>> -added a note that the is generated by >>> CreateSymbols. >>> >>> Webrevs: >>> top-level: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>> langtools: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>> >>> Delta webrevs are also available. >>> >>> How does this look? >>> >>> Thanks for the comments so far! >>> >>> Jan >>> >>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>> Ah, yes, I did not realize that. Thanks, will fix. >>>> >>>> Thanks, >>>> Jan >>>> >>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>> don't mention the fact that a side effect of the sym.txt >>>>> generation is >>>>> the mentioned earlier in the same >>>>> comments >>>>> (so one might wonder where does that come from). >>>>> >>>>> Maurizio >>>>> >>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I've uploaded another iteration, with these changes: >>>>>> -the "symbols" file is now generated automatically (for the typical >>>>>> OpenJDK case). >>>>>> -fixed a minor issue in CreateSymbols that could cause putting class >>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>> change). >>>>>> -jdk.management module has been split out from java.management >>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>> java.management and jdk.management as well. >>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>> >>>>>> Webrevs: >>>>>> -top-level: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>> -langtools (no changes against the last webrev): >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>> >>>>>> Delta webrevs against the previous iteration are included under >>>>>> "Author comments". >>>>>> >>>>>> Thanks for the comments so far! >>>>>> >>>>>> Jan >>>>>> >>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>> Excellent work. >>>>>>>> >>>>>>>> I think the comment in CreateSymbols could be made clearer w.r.t. >>>>>>>> Probe >>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>> >>>>>>>> /bin/java Probe --> classes-8 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> /bin/java Probe --> classes-7 >>>>>>>> >>>>>>>> etc. >>>>>>> >>>>>>> Sure, will do. >>>>>>> >>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>> descriptions >>>>>>> automatically, per our offline discussion. >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Jan >>>>>>> >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>> top-level repository: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>> langtools: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>> >>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>> differences >>>>>>>>> between .00 and .01 available - see the "Delta webrev" link under >>>>>>>>> "Author's comments") >>>>>>>>> >>>>>>>>> Summary of changes: >>>>>>>>> -applied Eric's build changes >>>>>>>>> -moved CreateSymbols into >>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>> Hi Jan, >>>>>>>>>> great work - couple of comments below: >>>>>>>>>> >>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>> simplified >>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>> checkOptionAllowed >>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>> commonalities >>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>> this a >>>>>>>>>> bit? >>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>> specified >>>>>>>>>> and >>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>> that, >>>>>>>>>> ignore the platform settings and issue a Lint 'options' warning? >>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>> logic in >>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>> CreateSymbols >>>>>>>>>> with >>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>> mean is >>>>>>>>>> that >>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>> (i.e. 8) >>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>> that's the >>>>>>>>>> use >>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>> order to >>>>>>>>>> explicitly state which of the platform is the baseline one, and >>>>>>>>>> the >>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>> seem to be typically all >>>>>>>>>> identical >>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>> Maybe >>>>>>>>>> the >>>>>>>>>> inference logic should be different (i.e. use 8 as a baseline >>>>>>>>>> for >>>>>>>>>> 7 and >>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>> should be >>>>>>>>>> chosen once and for all, and live implicitly in the tool? Or are >>>>>>>>>> there >>>>>>>>>> reasons as to why it might be handy to customize the baselines? >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>> >>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>> their >>>>>>>>>>> prerequisite: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>> >>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>> effect as >>>>>>>>>>> '-source N -target N -bootclasspath '. The possible >>>>>>>>>>> values >>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>> correspond to >>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>> >>>>>>>>>>> A tricky problem to solve is where to get the APIs for platform >>>>>>>>>>> N. The >>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>> inside >>>>>>>>>>> the >>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>> time >>>>>>>>>>> and >>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>> javac >>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>> lib/ct.sym >>>>>>>>>>> file. The input history data are placed >>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>> This >>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>> public >>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>> >>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>> checkout and >>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>> significantly >>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>> would >>>>>>>>>>> need to be included). The lib/ct.sym file is currently ~4.5MB. >>>>>>>>>>> >>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>> them as >>>>>>>>>>> classfiles), but are missing some attributes, most notably the >>>>>>>>>>> Code >>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>> named >>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>> bootclasspath >>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>> 'N' in >>>>>>>>>>> their name. >>>>>>>>>>> >>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The same file can also be used to construct the sym.txt files. >>>>>>>>>>> Concise >>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>> >>>>>>>>>>> I am sending this as one review, as the changes together >>>>>>>>>>> make one >>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>> independent >>>>>>>>>>> to a >>>>>>>>>>> great degree: the langtools changes add the "-platform" javac; >>>>>>>>>>> and the >>>>>>>>>>> top-level changes add the history data and ability to build the >>>>>>>>>>> ct.sym >>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>> independently. >>>>>>>>>>> >>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>> Alan >>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>> matter >>>>>>>>>>> before. >>>>>>>>>>> >>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jan >>>>>>>>>> >>>>>>>> >>>>> >> From jan.lahoda at oracle.com Fri Jun 26 07:58:17 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 26 Jun 2015 09:58:17 +0200 Subject: RFR: JDK-8080679: Include jline in JDK for Java and JavaScript REPLs In-Reply-To: <558C2E70.4050704@oracle.com> References: <5582D4CB.9090109@oracle.com> <558C2B60.6060502@oracle.com> <558C2E70.4050704@oracle.com> Message-ID: <558D0619.7090108@oracle.com> Hi Alan, Thanks for the comments! A question inline. On 25.6.2015 18:38, Alan Bateman wrote: > > > On 25/06/2015 17:25, Jan Lahoda wrote: >> Hello, >> >> Based on the feedback I've received so far, I've uploaded an updated >> version of the patch: >> http://cr.openjdk.java.net/~jlahoda/8080679/webrev.01/full/ >> >> Notable changes: >> -avoided the dependency on java.desktop and java.datatransfer >> -adjusted the native library build script as per Erik's recommendations >> -the module name is now changed to jdk.internal.le >> >> Any comments are welcome! > The new home and the dropping of the dependences on java.desktop & > java.datatransfer look good. > > Since there only 2 tests then it might be better to add > jdk/internal/jline to the mixed bag that is jdk_other. That way you > don't need to update update jprt.properties and other places where the > groups are used. > > The native method readKeyEvent seems to do a FindClass per key event. > Maybe this is from the upstream project but I would think it would be > more efficient to cache this in a global ref. It would also be more I will work on this. > efficient if the INPUT_RECORD were just returned and avoid the upstream > to create the object but that might be too much to change when you are I am sorry, but I don't follow - I don't have much experience with native programing for JDK. Are there some more details on what I should do? > trying to keep the code in sync with upstream. This part of the code is not from the upstream, so I can change it as needed. Thanks! Jan > > -Alan > > > From aph at redhat.com Fri Jun 26 08:05:01 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Jun 2015 09:05:01 +0100 Subject: Building on Solaris In-Reply-To: <558CE46A.6080203@oracle.com> References: <558BF995.8080709@redhat.com> <558BFC26.2000607@oracle.com> <558BFED6.4040301@redhat.com> <558CE46A.6080203@oracle.com> Message-ID: <558D07AD.3090006@redhat.com> On 26/06/15 06:34, David Holmes wrote: > On 25/06/2015 11:15 PM, Andrew Haley wrote: >> On 06/25/2015 02:03 PM, Erik Joelsson wrote: >>> Can you check that you have >>> $(JDK_TOPDIR)/make/src/classes/build/tools/module in your source tree? >> >> Ah yes, that's a problem. Somehow a ton of files is missing in there. >> >> I'll rebuild from a clean tree. > > Also note that we use a devkit from Solaris 10u10 when building on S11. > Building natively on S11 make not work. I am trying to duplicate your setup so that I can test on Solaris. If you could let me know exactly what tools y'all use that would help me a great deal. Thanks, Andrew. From erik.joelsson at oracle.com Fri Jun 26 09:29:02 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jun 2015 11:29:02 +0200 Subject: Building on Solaris In-Reply-To: <558D07AD.3090006@redhat.com> References: <558BF995.8080709@redhat.com> <558BFC26.2000607@oracle.com> <558BFED6.4040301@redhat.com> <558CE46A.6080203@oracle.com> <558D07AD.3090006@redhat.com> Message-ID: <558D1B5E.307@oracle.com> Hello Andrew, The current devkits basically contain the SS12u3 installation and a sysroot from a Solaris 10u10 machine. It should still compile on a pure Solaris 11 machine, but it's not tested as often. If you are able to construct a sysroot from a Solaris 10 machine and want to use it, just point to it using configure option --with-sysroot. I might be able to dig up some more detailed instructions of how this was created if you like to. I'm in the process of updating the compilers we use for jdk9 and it's currently looking to happen around September. The current intention is to use SS12u4 with a sysroot from Solaris 11.1 for Solaris builds. This time I also intend to supply the scripts used to create the devkit in the openjdk source, so you should be able to replicate that work if you wish to. /Erik On 2015-06-26 10:05, Andrew Haley wrote: > On 26/06/15 06:34, David Holmes wrote: >> On 25/06/2015 11:15 PM, Andrew Haley wrote: >>> On 06/25/2015 02:03 PM, Erik Joelsson wrote: >>>> Can you check that you have >>>> $(JDK_TOPDIR)/make/src/classes/build/tools/module in your source tree? >>> Ah yes, that's a problem. Somehow a ton of files is missing in there. >>> >>> I'll rebuild from a clean tree. >> Also note that we use a devkit from Solaris 10u10 when building on S11. >> Building natively on S11 make not work. > I am trying to duplicate your setup so that I can test on Solaris. If > you could let me know exactly what tools y'all use that would help me > a great deal. > > Thanks, > Andrew. From aph at redhat.com Fri Jun 26 09:40:11 2015 From: aph at redhat.com (Andrew Haley) Date: Fri, 26 Jun 2015 10:40:11 +0100 Subject: Building on Solaris In-Reply-To: <558D1B5E.307@oracle.com> References: <558BF995.8080709@redhat.com> <558BFC26.2000607@oracle.com> <558BFED6.4040301@redhat.com> <558CE46A.6080203@oracle.com> <558D07AD.3090006@redhat.com> <558D1B5E.307@oracle.com> Message-ID: <558D1DFB.5000402@redhat.com> On 06/26/2015 10:29 AM, Erik Joelsson wrote: > he current devkits basically contain the SS12u3 installation and a > sysroot from a Solaris 10u10 machine. It should still compile on a pure > Solaris 11 machine, but it's not tested as often. If you are able to > construct a sysroot from a Solaris 10 machine and want to use it, just > point to it using configure option --with-sysroot. I might be able to > dig up some more detailed instructions of how this was created if you > like to. > > I'm in the process of updating the compilers we use for jdk9 and it's > currently looking to happen around September. The current intention is > to use SS12u4 with a sysroot from Solaris 11.1 for Solaris builds. This > time I also intend to supply the scripts used to create the devkit in > the openjdk source, so you should be able to replicate that work if you > wish to. Thank you for a very helpful and detailed answer. Andrew. From maurizio.cimadamore at oracle.com Fri Jun 26 09:49:49 2015 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Fri, 26 Jun 2015 10:49:49 +0100 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <558C737A.6010405@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> <558AACEB.8030006@oracle.com> <558C737A.6010405@oracle.com> Message-ID: <558D203D.7090205@oracle.com> Looks good to me too; I like the name choice of the new Provider/Description pair. Maurizio On 25/06/15 22:32, Jonathan Gibbons wrote: > Looks good to me :-) > > -- Jon > > On 06/24/2015 06:13 AM, Jan Lahoda wrote: >> Hello, >> >> After some offline discussions, I've somewhat changed the internal >> API for plugging in the platforms (based on Jon's advices). An >> updated webrev is here: >> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.05/langtools/ >> >> How does this look? >> >> Thanks for all the comments! >> >> Jan >> >> On 2.6.2015 18:50, Jan Lahoda wrote: >>> Hello Eric, >>> >>> Thanks for the change, this seems definitely better to me. I've folded >>> your change that into my patch. An updated version (just langtools this >>> time): >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ >>> >>> Thanks! >>> >>> Jan >>> >>> On 2.6.2015 16:04, Erik Joelsson wrote: >>>> Hello Jan, >>>> >>>> Sorry to bother you with even more build changes, but with these file >>>> moves, I realized that this new file, ct.sym, is really a part of the >>>> jdk.compiler module and really not a special case at all. Because of >>>> this, it should be generated as part of the jdk.compiler-gendata >>>> target. >>>> This also eliminates all the changes in the top level repo and only >>>> leaves one new makefile in the langtools repo. >>>> >>>> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >>>> >>>> /Erik >>>> >>>> On 2015-06-01 17:56, Jan Lahoda wrote: >>>>> Hi, >>>>> >>>>> I made a somewhat bigger update (partially based on other feedback). >>>>> Summary of changes: >>>>> -the history data has been moved into langtools (I also moved the >>>>> Ctsym.gmk) >>>>> -there are JDK 6 data now >>>>> -renamed the "-platform" option to "-release". Code/tests directly >>>>> related to the option has been also changed as well. I kept the >>>>> internal PlatformProvider API in javac as is, and also kept related >>>>> code. >>>>> -added a note that the is generated by >>>>> CreateSymbols. >>>>> >>>>> Webrevs: >>>>> top-level: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>>>> langtools: >>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>>>> >>>>> Delta webrevs are also available. >>>>> >>>>> How does this look? >>>>> >>>>> Thanks for the comments so far! >>>>> >>>>> Jan >>>>> >>>>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>>>> Ah, yes, I did not realize that. Thanks, will fix. >>>>>> >>>>>> Thanks, >>>>>> Jan >>>>>> >>>>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>>>> don't mention the fact that a side effect of the sym.txt >>>>>>> generation is >>>>>>> the mentioned earlier in the same >>>>>>> comments >>>>>>> (so one might wonder where does that come from). >>>>>>> >>>>>>> Maurizio >>>>>>> >>>>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> I've uploaded another iteration, with these changes: >>>>>>>> -the "symbols" file is now generated automatically (for the >>>>>>>> typical >>>>>>>> OpenJDK case). >>>>>>>> -fixed a minor issue in CreateSymbols that could cause putting >>>>>>>> class >>>>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>>>> change). >>>>>>>> -jdk.management module has been split out from java.management >>>>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>>>> java.management and jdk.management as well. >>>>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>>>> >>>>>>>> Webrevs: >>>>>>>> -top-level: >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>>>> -langtools (no changes against the last webrev): >>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>>>> >>>>>>>> Delta webrevs against the previous iteration are included under >>>>>>>> "Author comments". >>>>>>>> >>>>>>>> Thanks for the comments so far! >>>>>>>> >>>>>>>> Jan >>>>>>>> >>>>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>>>> Excellent work. >>>>>>>>>> >>>>>>>>>> I think the comment in CreateSymbols could be made clearer >>>>>>>>>> w.r.t. >>>>>>>>>> Probe >>>>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>>>> >>>>>>>>>> /bin/java Probe --> classes-8 >>>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>>> >>>>>>>>>> etc. >>>>>>>>> >>>>>>>>> Sure, will do. >>>>>>>>> >>>>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>>>> descriptions >>>>>>>>> automatically, per our offline discussion. >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Jan >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Maurizio >>>>>>>>>> >>>>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>>>> top-level repository: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>>>> >>>>>>>>>>> langtools: >>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>>>> differences >>>>>>>>>>> between .00 and .01 available - see the "Delta webrev" link >>>>>>>>>>> under >>>>>>>>>>> "Author's comments") >>>>>>>>>>> >>>>>>>>>>> Summary of changes: >>>>>>>>>>> -applied Eric's build changes >>>>>>>>>>> -moved CreateSymbols into >>>>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>>>> >>>>>>>>>>> Thanks, >>>>>>>>>>> Jan >>>>>>>>>>> >>>>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>>>> Hi Jan, >>>>>>>>>>>> great work - couple of comments below: >>>>>>>>>>>> >>>>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>>>> simplified >>>>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>>>> checkOptionAllowed >>>>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>>>> commonalities >>>>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>>>> this a >>>>>>>>>>>> bit? >>>>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>>>> specified >>>>>>>>>>>> and >>>>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>>>> that, >>>>>>>>>>>> ignore the platform settings and issue a Lint 'options' >>>>>>>>>>>> warning? >>>>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>>>> logic in >>>>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>>>> CreateSymbols >>>>>>>>>>>> with >>>>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>>>> mean is >>>>>>>>>>>> that >>>>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>>>> (i.e. 8) >>>>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>>>> that's the >>>>>>>>>>>> use >>>>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>>>> order to >>>>>>>>>>>> explicitly state which of the platform is the baseline one, >>>>>>>>>>>> and >>>>>>>>>>>> the >>>>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>>>> seem to be typically all >>>>>>>>>>>> identical >>>>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>>>> Maybe >>>>>>>>>>>> the >>>>>>>>>>>> inference logic should be different (i.e. use 8 as a >>>>>>>>>>>> baseline for >>>>>>>>>>>> 7 and >>>>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>>>> should be >>>>>>>>>>>> chosen once and for all, and live implicitly in the tool? >>>>>>>>>>>> Or are >>>>>>>>>>>> there >>>>>>>>>>>> reasons as to why it might be handy to customize the >>>>>>>>>>>> baselines? >>>>>>>>>>>> >>>>>>>>>>>> Maurizio >>>>>>>>>>>> >>>>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>>>> >>>>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>>>> their >>>>>>>>>>>>> prerequisite: >>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>>>> >>>>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>>>> effect as >>>>>>>>>>>>> '-source N -target N -bootclasspath '. The >>>>>>>>>>>>> possible >>>>>>>>>>>>> values >>>>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>>>> correspond to >>>>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>>>> >>>>>>>>>>>>> A tricky problem to solve is where to get the APIs for >>>>>>>>>>>>> platform >>>>>>>>>>>>> N. The >>>>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>>>> inside >>>>>>>>>>>>> the >>>>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>>>> time >>>>>>>>>>>>> and >>>>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>>>> javac >>>>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>>>> lib/ct.sym >>>>>>>>>>>>> file. The input history data are placed >>>>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>>>> This >>>>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>>>> public >>>>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>>>> >>>>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>>>> checkout and >>>>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>>>> significantly >>>>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>>>> would >>>>>>>>>>>>> need to be included). The lib/ct.sym file is currently >>>>>>>>>>>>> ~4.5MB. >>>>>>>>>>>>> >>>>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>>>> them as >>>>>>>>>>>>> classfiles), but are missing some attributes, most notably >>>>>>>>>>>>> the >>>>>>>>>>>>> Code >>>>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>>>> named >>>>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>>>> bootclasspath >>>>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>>>> 'N' in >>>>>>>>>>>>> their name. >>>>>>>>>>>>> >>>>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The same file can also be used to construct the sym.txt >>>>>>>>>>>>> files. >>>>>>>>>>>>> Concise >>>>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>>>> >>>>>>>>>>>>> I am sending this as one review, as the changes together make >>>>>>>>>>>>> one >>>>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>>>> independent >>>>>>>>>>>>> to a >>>>>>>>>>>>> great degree: the langtools changes add the "-platform" >>>>>>>>>>>>> javac; >>>>>>>>>>>>> and the >>>>>>>>>>>>> top-level changes add the history data and ability to >>>>>>>>>>>>> build the >>>>>>>>>>>>> ct.sym >>>>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>>>> independently. >>>>>>>>>>>>> >>>>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>>>> Alan >>>>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>>>> matter >>>>>>>>>>>>> before. >>>>>>>>>>>>> >>>>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks, >>>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>> >>>>>>> >>>> > From david.holmes at oracle.com Fri Jun 26 12:10:47 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 22:10:47 +1000 Subject: [8u60] RFR: 8129850: java.util.Properties.loadFromXML fails on compact1 profile Message-ID: <558D4147.4020006@oracle.com> Apologies as the bug report is not public. When I added cross-platform support for compact profiles under JDK-8038189. I had to add a check for an empty variable but added it in the wrong place in CreateJars.gmk when creating the resource.jar: ifneq ($(PROFILE), ) + ifneq ($(strip $(PROFILE_INCLUDE_METAINF_SERVICES)), ) # Strip out all META-INF/services/ entries $(GREP) -v -e 'META-INF/services/' $@.tmp > $@.tmp2 # Add back the required services for service in $(PROFILE_INCLUDE_METAINF_SERVICES) ; do \ $(ECHO) $$service >> $@.tmp2; \ done $(MV) $@.tmp2 $@.tmp + endif For compact1 the variable is empty which means we skipped stripping out the META-INF/services entries from resource.jar. Consequently those services would be found and the library code would then try to use a service for which no implementation existed - and hence we get failures. The fix is of course to move the if block so that it only surrounds the for loop. webrev: http://cr.openjdk.java.net/~dholmes/8129850/webrev/ Thanks, David From erik.joelsson at oracle.com Fri Jun 26 12:22:46 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jun 2015 14:22:46 +0200 Subject: RFR: JDK-8114822: debug build with --disable-debug-symbols fails: java.io.UncheckedIOException Message-ID: <558D4416.3010503@oracle.com> Hello, Please review this small fix for a build break on Macosx. Note that the debugsymbols/stripping solution with StripBinaries.gmk is messy and should ideally be fixed in a better way. For now, this is the simplest way of fixing this problem. In StripBinaries.gmk, all the lib and bin files are either copied or copied-and-stripped. This patch makes the list of files to be copied simply defined as all the files that aren't being stripped. The old find expression would not find the libjsig.dylib file inside the libjsig.dylib.dSYM directory. Bug: https://bugs.openjdk.java.net/browse/JDK-8114822 Webrev: http://cr.openjdk.java.net/~erikj/8114822/webrev.01/ /Erik From erik.joelsson at oracle.com Fri Jun 26 12:26:36 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jun 2015 14:26:36 +0200 Subject: [8u60] RFR: 8129850: java.util.Properties.loadFromXML fails on compact1 profile In-Reply-To: <558D4147.4020006@oracle.com> References: <558D4147.4020006@oracle.com> Message-ID: <558D44FC.3070802@oracle.com> Hello David, Looks good to me. /Erik On 2015-06-26 14:10, David Holmes wrote: > Apologies as the bug report is not public. > > When I added cross-platform support for compact profiles under > JDK-8038189. I had to add a check for an empty variable but added it > in the wrong place in CreateJars.gmk when creating the resource.jar: > > ifneq ($(PROFILE), ) > + ifneq ($(strip $(PROFILE_INCLUDE_METAINF_SERVICES)), ) > # Strip out all META-INF/services/ entries > $(GREP) -v -e 'META-INF/services/' $@.tmp > $@.tmp2 > # Add back the required services > for service in $(PROFILE_INCLUDE_METAINF_SERVICES) ; do \ > $(ECHO) $$service >> $@.tmp2; \ > done > $(MV) $@.tmp2 $@.tmp > + endif > > For compact1 the variable is empty which means we skipped stripping > out the META-INF/services entries from resource.jar. Consequently > those services would be found and the library code would then try to > use a service for which no implementation existed - and hence we get > failures. > > The fix is of course to move the if block so that it only surrounds > the for loop. > > webrev: http://cr.openjdk.java.net/~dholmes/8129850/webrev/ > > Thanks, > David From david.holmes at oracle.com Fri Jun 26 12:26:26 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 22:26:26 +1000 Subject: RFR: JDK-8114822: debug build with --disable-debug-symbols fails: java.io.UncheckedIOException In-Reply-To: <558D4416.3010503@oracle.com> References: <558D4416.3010503@oracle.com> Message-ID: <558D44F2.7090509@oracle.com> HI Erik, On 26/06/2015 10:22 PM, Erik Joelsson wrote: > Hello, > > Please review this small fix for a build break on Macosx. Note that the > debugsymbols/stripping solution with StripBinaries.gmk is messy and > should ideally be fixed in a better way. For now, this is the simplest > way of fixing this problem. > > In StripBinaries.gmk, all the lib and bin files are either copied or > copied-and-stripped. This patch makes the list of files to be copied > simply defined as all the files that aren't being stripped. The old find > expression would not find the libjsig.dylib file inside the > libjsig.dylib.dSYM directory. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8114822 > Webrev: http://cr.openjdk.java.net/~erikj/8114822/webrev.01/ Seems a reasonable approach. Thanks, David > /Erik From Alan.Bateman at oracle.com Fri Jun 26 12:36:11 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 26 Jun 2015 13:36:11 +0100 Subject: [8u60] RFR: 8129850: java.util.Properties.loadFromXML fails on compact1 profile In-Reply-To: <558D4147.4020006@oracle.com> References: <558D4147.4020006@oracle.com> Message-ID: <558D473B.3020504@oracle.com> On 26/06/2015 13:10, David Holmes wrote: > : > > webrev: http://cr.openjdk.java.net/~dholmes/8129850/webrev/ This looks okay to me. -Alan From david.holmes at oracle.com Fri Jun 26 12:38:52 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 26 Jun 2015 22:38:52 +1000 Subject: [8u60] RFR: 8129850: java.util.Properties.loadFromXML fails on compact1 profile In-Reply-To: <558D473B.3020504@oracle.com> References: <558D4147.4020006@oracle.com> <558D473B.3020504@oracle.com> Message-ID: <558D47DC.50802@oracle.com> On 26/06/2015 10:36 PM, Alan Bateman wrote: > > > On 26/06/2015 13:10, David Holmes wrote: >> : >> >> webrev: http://cr.openjdk.java.net/~dholmes/8129850/webrev/ > This looks okay to me. Thanks Alan, and Erik, David > -Alan From jan.lahoda at oracle.com Fri Jun 26 13:20:34 2015 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Fri, 26 Jun 2015 15:20:34 +0200 Subject: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version In-Reply-To: <558D203D.7090205@oracle.com> References: <555D82CC.9070105@oracle.com> <555DB419.6020301@oracle.com> <555F232E.1060105@oracle.com> <555F2692.5030002@oracle.com> <555F2D9F.2090505@oracle.com> <5565906D.1050400@oracle.com> <5565958A.1040807@oracle.com> <5565B730.5030602@oracle.com> <556C8094.3050800@oracle.com> <556DB7E9.7090709@oracle.com> <556DDEEC.2000505@oracle.com> <558AACEB.8030006@oracle.com> <558C737A.6010405@oracle.com> <558D203D.7090205@oracle.com> Message-ID: <558D51A2.7000706@oracle.com> Based on additional Jon's feedback, I made some minor tweaks to the patch. An updated webrev is here: http://cr.openjdk.java.net/~jlahoda/8072480/webrev.06/langtools/ A delta webrev is available under "Author comments". Unless there are objections, I'll work on pushing this to jdk9/dev. Thanks for all the comments! Jan On 26.6.2015 11:49, Maurizio Cimadamore wrote: > Looks good to me too; I like the name choice of the new > Provider/Description pair. > > Maurizio > > On 25/06/15 22:32, Jonathan Gibbons wrote: >> Looks good to me :-) >> >> -- Jon >> >> On 06/24/2015 06:13 AM, Jan Lahoda wrote: >>> Hello, >>> >>> After some offline discussions, I've somewhat changed the internal >>> API for plugging in the platforms (based on Jon's advices). An >>> updated webrev is here: >>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.05/langtools/ >>> >>> How does this look? >>> >>> Thanks for all the comments! >>> >>> Jan >>> >>> On 2.6.2015 18:50, Jan Lahoda wrote: >>>> Hello Eric, >>>> >>>> Thanks for the change, this seems definitely better to me. I've folded >>>> your change that into my patch. An updated version (just langtools this >>>> time): >>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.04/langtools/ >>>> >>>> Thanks! >>>> >>>> Jan >>>> >>>> On 2.6.2015 16:04, Erik Joelsson wrote: >>>>> Hello Jan, >>>>> >>>>> Sorry to bother you with even more build changes, but with these file >>>>> moves, I realized that this new file, ct.sym, is really a part of the >>>>> jdk.compiler module and really not a special case at all. Because of >>>>> this, it should be generated as part of the jdk.compiler-gendata >>>>> target. >>>>> This also eliminates all the changes in the top level repo and only >>>>> leaves one new makefile in the langtools repo. >>>>> >>>>> http://cr.openjdk.java.net/~erikj/8072480/webrev.02/ >>>>> >>>>> /Erik >>>>> >>>>> On 2015-06-01 17:56, Jan Lahoda wrote: >>>>>> Hi, >>>>>> >>>>>> I made a somewhat bigger update (partially based on other feedback). >>>>>> Summary of changes: >>>>>> -the history data has been moved into langtools (I also moved the >>>>>> Ctsym.gmk) >>>>>> -there are JDK 6 data now >>>>>> -renamed the "-platform" option to "-release". Code/tests directly >>>>>> related to the option has been also changed as well. I kept the >>>>>> internal PlatformProvider API in javac as is, and also kept related >>>>>> code. >>>>>> -added a note that the is generated by >>>>>> CreateSymbols. >>>>>> >>>>>> Webrevs: >>>>>> top-level: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/top-level/ >>>>>> langtools: >>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.03/langtools/ >>>>>> >>>>>> Delta webrevs are also available. >>>>>> >>>>>> How does this look? >>>>>> >>>>>> Thanks for the comments so far! >>>>>> >>>>>> Jan >>>>>> >>>>>> On 27.5.2015 14:23, Jan Lahoda wrote: >>>>>>> Ah, yes, I did not realize that. Thanks, will fix. >>>>>>> >>>>>>> Thanks, >>>>>>> Jan >>>>>>> >>>>>>> On 27.5.2015 11:59, Maurizio Cimadamore wrote: >>>>>>>> Looks great. The only nitpick is that the comments in CreateSymbols >>>>>>>> don't mention the fact that a side effect of the sym.txt >>>>>>>> generation is >>>>>>>> the mentioned earlier in the same >>>>>>>> comments >>>>>>>> (so one might wonder where does that come from). >>>>>>>> >>>>>>>> Maurizio >>>>>>>> >>>>>>>> On 27/05/15 10:37, Jan Lahoda wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I've uploaded another iteration, with these changes: >>>>>>>>> -the "symbols" file is now generated automatically (for the >>>>>>>>> typical >>>>>>>>> OpenJDK case). >>>>>>>>> -fixed a minor issue in CreateSymbols that could cause putting >>>>>>>>> class >>>>>>>>> description into wrong a file (the "break" -> "break OUTER;" >>>>>>>>> change). >>>>>>>>> -jdk.management module has been split out from java.management >>>>>>>>> recently, so splitting the corresponding .sym.txt files into >>>>>>>>> java.management and jdk.management as well. >>>>>>>>> -updating the copyright year in CreateSymbols, as noted by Magnus. >>>>>>>>> >>>>>>>>> Webrevs: >>>>>>>>> -top-level: >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/top-level/ >>>>>>>>> -langtools (no changes against the last webrev): >>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.02/langtools/ >>>>>>>>> >>>>>>>>> Delta webrevs against the previous iteration are included under >>>>>>>>> "Author comments". >>>>>>>>> >>>>>>>>> Thanks for the comments so far! >>>>>>>>> >>>>>>>>> Jan >>>>>>>>> >>>>>>>>> On 22.5.2015 15:22, Jan Lahoda wrote: >>>>>>>>>> On 22.5.2015 14:52, Maurizio Cimadamore wrote: >>>>>>>>>>> Excellent work. >>>>>>>>>>> >>>>>>>>>>> I think the comment in CreateSymbols could be made clearer >>>>>>>>>>> w.r.t. >>>>>>>>>>> Probe >>>>>>>>>>> - i.e. that Probe should be ran on top of the JDK N - i.e. >>>>>>>>>>> >>>>>>>>>>> /bin/java Probe --> classes-8 >>>>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>>>> /bin/java Probe --> classes-7 >>>>>>>>>>> >>>>>>>>>>> etc. >>>>>>>>>> >>>>>>>>>> Sure, will do. >>>>>>>>>> >>>>>>>>>> I'll also look at generating the make/data/symbols/symbols >>>>>>>>>> descriptions >>>>>>>>>> automatically, per our offline discussion. >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Maurizio >>>>>>>>>>> >>>>>>>>>>> On 22/05/15 13:38, Jan Lahoda wrote: >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I've uploaded a new iteration of the patch(es): >>>>>>>>>>>> top-level repository: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/top-level/ >>>>>>>>>>>> >>>>>>>>>>>> langtools: >>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.01/langtools/ >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> (besides full webrevs, there are also webrevs showing the >>>>>>>>>>>> differences >>>>>>>>>>>> between .00 and .01 available - see the "Delta webrev" link >>>>>>>>>>>> under >>>>>>>>>>>> "Author's comments") >>>>>>>>>>>> >>>>>>>>>>>> Summary of changes: >>>>>>>>>>>> -applied Eric's build changes >>>>>>>>>>>> -moved CreateSymbols into >>>>>>>>>>>> make/src/classes/build/tools/symbolgenerator >>>>>>>>>>>> -tried to improve the specification of base platforms in >>>>>>>>>>>> CreateSymbols, per Maurizio's comment >>>>>>>>>>>> -other cleanup in langtools per Maurizio's comments. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> Jan >>>>>>>>>>>> >>>>>>>>>>>> On 21.5.2015 12:31, Maurizio Cimadamore wrote: >>>>>>>>>>>>> Hi Jan, >>>>>>>>>>>>> great work - couple of comments below: >>>>>>>>>>>>> >>>>>>>>>>>>> * it seems like some of the routines in Arguments can be >>>>>>>>>>>>> simplified >>>>>>>>>>>>> using lambdas - especially lookupPlatformProvider and >>>>>>>>>>>>> checkOptionAllowed >>>>>>>>>>>>> * Why JDKPlatformProvider is not called >>>>>>>>>>>>> JDKPlatformProvider*Factory* ? >>>>>>>>>>>>> * JavacProcessingEnvironment.JoiningIterator seems to have >>>>>>>>>>>>> commonalities >>>>>>>>>>>>> with CompoundScopeIterator - any chance that we might refactor >>>>>>>>>>>>> this a >>>>>>>>>>>>> bit? >>>>>>>>>>>>> * What's the rationale for giving an error if -platform is >>>>>>>>>>>>> specified >>>>>>>>>>>>> and >>>>>>>>>>>>> a non-StandardFileManager is provided? Can't we simply swallow >>>>>>>>>>>>> that, >>>>>>>>>>>>> ignore the platform settings and issue a Lint 'options' >>>>>>>>>>>>> warning? >>>>>>>>>>>>> * Would it make sense for some of the classfile generation >>>>>>>>>>>>> logic in >>>>>>>>>>>>> CreateSymbols to be moved under the classfile API ? >>>>>>>>>>>>> * I had hard time reconciling some of the comments in >>>>>>>>>>>>> CreateSymbols >>>>>>>>>>>>> with >>>>>>>>>>>>> how the files were laid out. I think in the end, what you >>>>>>>>>>>>> mean is >>>>>>>>>>>>> that >>>>>>>>>>>>> if you have platforms 7, 8, 9 - you should pick one baseline >>>>>>>>>>>>> (i.e. 8) >>>>>>>>>>>>> and then generate diffs for 9 and 7 against the 8 one. If >>>>>>>>>>>>> that's the >>>>>>>>>>>>> use >>>>>>>>>>>>> case, I think the command line can be simplified a bit in >>>>>>>>>>>>> order to >>>>>>>>>>>>> explicitly state which of the platform is the baseline one, >>>>>>>>>>>>> and >>>>>>>>>>>>> the >>>>>>>>>>>>> remaining parameters can be inferred from the tool (as the >>>>>>>>>>>>> seem to be typically all >>>>>>>>>>>>> identical >>>>>>>>>>>>> but one which is set to - the one for the baseline). >>>>>>>>>>>>> Maybe >>>>>>>>>>>>> the >>>>>>>>>>>>> inference logic should be different (i.e. use 8 as a >>>>>>>>>>>>> baseline for >>>>>>>>>>>>> 7 and >>>>>>>>>>>>> 7 as a baseline for 6) - but - whatever the logic, I think it >>>>>>>>>>>>> should be >>>>>>>>>>>>> chosen once and for all, and live implicitly in the tool? >>>>>>>>>>>>> Or are >>>>>>>>>>>>> there >>>>>>>>>>>>> reasons as to why it might be handy to customize the >>>>>>>>>>>>> baselines? >>>>>>>>>>>>> >>>>>>>>>>>>> Maurizio >>>>>>>>>>>>> >>>>>>>>>>>>> On 21/05/15 08:01, Jan Lahoda wrote: >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> This is a patch adding a new option, -platform, to javac. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Patch for the top-level repository is here: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/top-level/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Patch for the langtools repository is here: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8072480/webrev.00/langtools/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> These changes also require additional langtools changes as >>>>>>>>>>>>>> their >>>>>>>>>>>>>> prerequisite: >>>>>>>>>>>>>> http://cr.openjdk.java.net/~jlahoda/8080675/webrev.00/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> Overall, one can imagine '-platform N' to have the same >>>>>>>>>>>>>> effect as >>>>>>>>>>>>>> '-source N -target N -bootclasspath '. The >>>>>>>>>>>>>> possible >>>>>>>>>>>>>> values >>>>>>>>>>>>>> for 'N' are pluggable in a limited way, though (see >>>>>>>>>>>>>> langtools/src/jdk.compiler/share/classes/com/sun/tools/javac/platform/PlatformProvider.java). >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Note that this patch only introduces N=7 and N=8, which >>>>>>>>>>>>>> correspond to >>>>>>>>>>>>>> Open JDK 7 and 8 GA. >>>>>>>>>>>>>> >>>>>>>>>>>>>> A tricky problem to solve is where to get the APIs for >>>>>>>>>>>>>> platform >>>>>>>>>>>>>> N. The >>>>>>>>>>>>>> proposal is to include history data in the textual format >>>>>>>>>>>>>> inside >>>>>>>>>>>>>> the >>>>>>>>>>>>>> OpenJDK repositories (the input data), process them at build >>>>>>>>>>>>>> time >>>>>>>>>>>>>> and >>>>>>>>>>>>>> create a lib/ct.sym file holding the data in the JDK image. >>>>>>>>>>>>>> javac >>>>>>>>>>>>>> running with the -platform option then compiles against the >>>>>>>>>>>>>> lib/ct.sym >>>>>>>>>>>>>> file. The input history data are placed >>>>>>>>>>>>>> /make/data/symbols (the sym.txt files). >>>>>>>>>>>>>> This >>>>>>>>>>>>>> patches only includes data for OpenJDK 7 and 8, and only for >>>>>>>>>>>>>> public >>>>>>>>>>>>>> APIs (more or less Java SE and JDK @Exported APIs). >>>>>>>>>>>>>> >>>>>>>>>>>>>> The size of the history data is currently ~6MB in the JDK >>>>>>>>>>>>>> checkout and >>>>>>>>>>>>>> ~650kB inside the .hg directory (the size could change >>>>>>>>>>>>>> significantly >>>>>>>>>>>>>> if additional classes/elements, like non-public API classes, >>>>>>>>>>>>>> would >>>>>>>>>>>>>> need to be included). The lib/ct.sym file is currently >>>>>>>>>>>>>> ~4.5MB. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The ct.sym file is a zip file containing signature files. The >>>>>>>>>>>>>> signature files are similar to classfiles (so javac can read >>>>>>>>>>>>>> them as >>>>>>>>>>>>>> classfiles), but are missing some attributes, most notably >>>>>>>>>>>>>> the >>>>>>>>>>>>>> Code >>>>>>>>>>>>>> attribute. On the top-level, the ct.sym contains directories >>>>>>>>>>>>>> named >>>>>>>>>>>>>> "7", "78" and "8". When compiling for version 'N', the >>>>>>>>>>>>>> bootclasspath >>>>>>>>>>>>>> for that version is obtained by using directories which have >>>>>>>>>>>>>> 'N' in >>>>>>>>>>>>>> their name. >>>>>>>>>>>>>> >>>>>>>>>>>>>> The sigfiles for ct.sym are created by >>>>>>>>>>>>>> /make/tools/symbolgenerator/CreateSymbols.java. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> The same file can also be used to construct the sym.txt >>>>>>>>>>>>>> files. >>>>>>>>>>>>>> Concise >>>>>>>>>>>>>> instructions are part of the CreateSymbols.java. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I am sending this as one review, as the changes together make >>>>>>>>>>>>>> one >>>>>>>>>>>>>> feature, but the langtools and top-level changes are >>>>>>>>>>>>>> independent >>>>>>>>>>>>>> to a >>>>>>>>>>>>>> great degree: the langtools changes add the "-platform" >>>>>>>>>>>>>> javac; >>>>>>>>>>>>>> and the >>>>>>>>>>>>>> top-level changes add the history data and ability to >>>>>>>>>>>>>> build the >>>>>>>>>>>>>> ct.sym >>>>>>>>>>>>>> file. If desired, these could be pushed and/or reviewed >>>>>>>>>>>>>> independently. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Many thanks go to Jon Gibbons, Joe Darcy, Magnus Ihse Bursie, >>>>>>>>>>>>>> Alan >>>>>>>>>>>>>> Bateman and others who have provided advices and help on the >>>>>>>>>>>>>> matter >>>>>>>>>>>>>> before. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any insights/comments are wholeheartedly welcome. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> Jan >>>>>>>>>>>>> >>>>>>>>>>> >>>>>>>> >>>>> >> > From volker.simonis at gmail.com Fri Jun 26 13:43:17 2015 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 26 Jun 2015 15:43:17 +0200 Subject: Building on Solaris In-Reply-To: <558D07AD.3090006@redhat.com> References: <558BF995.8080709@redhat.com> <558BFC26.2000607@oracle.com> <558BFED6.4040301@redhat.com> <558CE46A.6080203@oracle.com> <558D07AD.3090006@redhat.com> Message-ID: Hi Andrew, we are building nightly on Solaris 11 / SPARC with SS 12u3 (see http://cr.openjdk.java.net/~simonis/ppc-aix-port/ - you can click on the traffic lights to download the complete build logs). And I've just verified that I can build jdk9-dev myself. Assuming you have the compiler (SS12u3) in your path this is my configure line: configure -with-boot-jdk=/sun_64/last_known_good/output-jdk8/images/j2sdk-image --with-jvm-variants=server --with-freetype=/usr/work/openjdk/tools/sun_64/freetype --with-cups=/usr/work/openjdk/tools/cups-1.6.1 --with-target-bits=64 --with-debug-level=slowdebug --disable-zip-debug-info --disable-warnings-as-errors Essential is that you use "--disable-warnings-as-errors" because of this problem: "/jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c", line 384: error: statement not reached (E_STATEMENT_NOT_REACHED) cc: acomp failed for /jdk9/client/jdk/src/java.base/unix/native/libjava/childproc.c gmake[3]: *** [/jdk9/client/build/solaris-x86_64-normal-server-fastdebug/support/native/java.base/libjava/childproc.o] Error 2 gmake[3]: *** Waiting for unfinished jobs.... gmake[2]: *** [java.base-libs] Error 1 If you search the build-dev list for "childproc.c" you'll find the exact reason for the problem. Regards, Volker On Fri, Jun 26, 2015 at 10:05 AM, Andrew Haley wrote: > On 26/06/15 06:34, David Holmes wrote: >> On 25/06/2015 11:15 PM, Andrew Haley wrote: >>> On 06/25/2015 02:03 PM, Erik Joelsson wrote: >>>> Can you check that you have >>>> $(JDK_TOPDIR)/make/src/classes/build/tools/module in your source tree? >>> >>> Ah yes, that's a problem. Somehow a ton of files is missing in there. >>> >>> I'll rebuild from a clean tree. >> >> Also note that we use a devkit from Solaris 10u10 when building on S11. >> Building natively on S11 make not work. > > I am trying to duplicate your setup so that I can test on Solaris. If > you could let me know exactly what tools y'all use that would help me > a great deal. > > Thanks, > Andrew. From erik.joelsson at oracle.com Fri Jun 26 13:53:05 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 26 Jun 2015 15:53:05 +0200 Subject: RFR: JDK-8129969: Switch JPRT configuration to use devkits for Windows and Macosx Message-ID: <558D5941.2000706@oracle.com> Hello, Please review this change for the Oracle internal JPRT configuration for building jdk9. This change flips the switch for JPRT to start using devkits for building jdk9 on Windows and Macosx, instead of preinstalled versions of Visual Studio and Xcode. The versions of the compilers stay the same for now, so nothing should really change in the product. Making this change will make it much easier to change compiler versions in the future. Bug: https://bugs.openjdk.java.net/browse/JDK-8129969 Patch: diff -r 2f143b1e68d5 make/jprt.properties --- a/make/jprt.properties +++ b/make/jprt.properties @@ -123,11 +123,13 @@ ${my.i586.default.build.configure.args} \ ${jprt.productOpen.build.configure.args} -jprt.windows_i586_6.2.build.configure.args= \ - --with-toolchain-version=2013 \ +jprt.windows_i586.build.configure.args= \ + --with-devkit=$VS2013_HOME \ ${jprt.i586.build.configure.args} -jprt.windows_x64_6.2.build.configure.args= \ - --with-toolchain-version=2013 +jprt.windows_x64.build.configure.args= \ + --with-devkit=$VS2013_HOME +jprt.macosx_x64.build.configure.args= \ + --with-devkit=$XCODE_511_HOME ######## # From tim.bell at oracle.com Fri Jun 26 14:12:38 2015 From: tim.bell at oracle.com (Tim Bell) Date: Fri, 26 Jun 2015 07:12:38 -0700 Subject: RFR: JDK-8129969: Switch JPRT configuration to use devkits for Windows and Macosx In-Reply-To: <558D5941.2000706@oracle.com> References: <558D5941.2000706@oracle.com> Message-ID: <558D5DD6.20109@oracle.com> Erik: > Please review this change for the Oracle internal JPRT configuration > for building jdk9. This change flips the switch for JPRT to start > using devkits for building jdk9 on Windows and Macosx, instead of > preinstalled versions of Visual Studio and Xcode. The versions of the > compilers stay the same for now, so nothing should really change in > the product. Making this change will make it much easier to change > compiler versions in the future. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129969 Very nice. Looks good to me. Tim > Patch: > > diff -r 2f143b1e68d5 make/jprt.properties > --- a/make/jprt.properties > +++ b/make/jprt.properties > @@ -123,11 +123,13 @@ > ${my.i586.default.build.configure.args} \ > ${jprt.productOpen.build.configure.args} > > -jprt.windows_i586_6.2.build.configure.args= \ > - --with-toolchain-version=2013 \ > +jprt.windows_i586.build.configure.args= \ > + --with-devkit=$VS2013_HOME \ > ${jprt.i586.build.configure.args} > -jprt.windows_x64_6.2.build.configure.args= \ > - --with-toolchain-version=2013 > +jprt.windows_x64.build.configure.args= \ > + --with-devkit=$VS2013_HOME > +jprt.macosx_x64.build.configure.args= \ > + --with-devkit=$XCODE_511_HOME > > ######## > # > From david.holmes at oracle.com Sat Jun 27 01:52:22 2015 From: david.holmes at oracle.com (David Holmes) Date: Sat, 27 Jun 2015 11:52:22 +1000 Subject: RFR: JDK-8129969: Switch JPRT configuration to use devkits for Windows and Macosx In-Reply-To: <558D5941.2000706@oracle.com> References: <558D5941.2000706@oracle.com> Message-ID: <558E01D6.5070002@oracle.com> Looks okay to me. Thanks, David On 26/06/2015 11:53 PM, Erik Joelsson wrote: > Hello, > > Please review this change for the Oracle internal JPRT configuration for > building jdk9. This change flips the switch for JPRT to start using > devkits for building jdk9 on Windows and Macosx, instead of preinstalled > versions of Visual Studio and Xcode. The versions of the compilers stay > the same for now, so nothing should really change in the product. Making > this change will make it much easier to change compiler versions in the > future. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129969 > Patch: > > diff -r 2f143b1e68d5 make/jprt.properties > --- a/make/jprt.properties > +++ b/make/jprt.properties > @@ -123,11 +123,13 @@ > ${my.i586.default.build.configure.args} \ > ${jprt.productOpen.build.configure.args} > > -jprt.windows_i586_6.2.build.configure.args= \ > - --with-toolchain-version=2013 \ > +jprt.windows_i586.build.configure.args= \ > + --with-devkit=$VS2013_HOME \ > ${jprt.i586.build.configure.args} > -jprt.windows_x64_6.2.build.configure.args= \ > - --with-toolchain-version=2013 > +jprt.windows_x64.build.configure.args= \ > + --with-devkit=$VS2013_HOME > +jprt.macosx_x64.build.configure.args= \ > + --with-devkit=$XCODE_511_HOME > > ######## > # > From erik.joelsson at oracle.com Mon Jun 29 13:26:08 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 29 Jun 2015 15:26:08 +0200 Subject: RFR: JDK-8130060: Revert use of devkit on macosx in JPRT In-Reply-To: <558D5941.2000706@oracle.com> References: <558D5941.2000706@oracle.com> Message-ID: <55914770.3020508@oracle.com> I discovered an issue with using devkits for Macosx in certain configurations. While it currently works fine in JPRT, I would rather disable it for now until the issue can be resolved. Bug: https://bugs.openjdk.java.net/browse/JDK-8130060 Patch: diff -r f50c05d4dcd5 make/jprt.properties --- a/make/jprt.properties +++ b/make/jprt.properties @@ -128,8 +128,6 @@ ${jprt.i586.build.configure.args} jprt.windows_x64.build.configure.args= \ --with-devkit=$VS2013_HOME -jprt.macosx_x64.build.configure.args= \ - --with-devkit=$XCODE_511_HOME ######## # /Erik On 2015-06-26 15:53, Erik Joelsson wrote: > Hello, > > Please review this change for the Oracle internal JPRT configuration > for building jdk9. This change flips the switch for JPRT to start > using devkits for building jdk9 on Windows and Macosx, instead of > preinstalled versions of Visual Studio and Xcode. The versions of the > compilers stay the same for now, so nothing should really change in > the product. Making this change will make it much easier to change > compiler versions in the future. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8129969 > Patch: > > diff -r 2f143b1e68d5 make/jprt.properties > --- a/make/jprt.properties > +++ b/make/jprt.properties > @@ -123,11 +123,13 @@ > ${my.i586.default.build.configure.args} \ > ${jprt.productOpen.build.configure.args} > > -jprt.windows_i586_6.2.build.configure.args= \ > - --with-toolchain-version=2013 \ > +jprt.windows_i586.build.configure.args= \ > + --with-devkit=$VS2013_HOME \ > ${jprt.i586.build.configure.args} > -jprt.windows_x64_6.2.build.configure.args= \ > - --with-toolchain-version=2013 > +jprt.windows_x64.build.configure.args= \ > + --with-devkit=$VS2013_HOME > +jprt.macosx_x64.build.configure.args= \ > + --with-devkit=$XCODE_511_HOME > > ######## > # > From tim.bell at oracle.com Mon Jun 29 15:04:17 2015 From: tim.bell at oracle.com (Tim Bell) Date: Mon, 29 Jun 2015 08:04:17 -0700 Subject: RFR: JDK-8130060: Revert use of devkit on macosx in JPRT In-Reply-To: <55914770.3020508@oracle.com> References: <558D5941.2000706@oracle.com> <55914770.3020508@oracle.com> Message-ID: <55915E71.1090102@oracle.com> Hi Erik: > I discovered an issue with using devkits for Macosx in certain > configurations. While it currently works fine in JPRT, I would rather > disable it for now until the issue can be resolved. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130060 > Patch: > diff -r f50c05d4dcd5 make/jprt.properties > --- a/make/jprt.properties > +++ b/make/jprt.properties > @@ -128,8 +128,6 @@ > ${jprt.i586.build.configure.args} > jprt.windows_x64.build.configure.args= \ > --with-devkit=$VS2013_HOME > -jprt.macosx_x64.build.configure.args= \ > - --with-devkit=$XCODE_511_HOME Looks good. Tim > /Erik > > On 2015-06-26 15:53, Erik Joelsson wrote: >> Hello, >> >> Please review this change for the Oracle internal JPRT configuration >> for building jdk9. This change flips the switch for JPRT to start >> using devkits for building jdk9 on Windows and Macosx, instead of >> preinstalled versions of Visual Studio and Xcode. The versions of the >> compilers stay the same for now, so nothing should really change in >> the product. Making this change will make it much easier to change >> compiler versions in the future. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8129969 >> Patch: >> >> diff -r 2f143b1e68d5 make/jprt.properties >> --- a/make/jprt.properties >> +++ b/make/jprt.properties >> @@ -123,11 +123,13 @@ >> ${my.i586.default.build.configure.args} \ >> ${jprt.productOpen.build.configure.args} >> >> -jprt.windows_i586_6.2.build.configure.args= \ >> - --with-toolchain-version=2013 \ >> +jprt.windows_i586.build.configure.args= \ >> + --with-devkit=$VS2013_HOME \ >> ${jprt.i586.build.configure.args} >> -jprt.windows_x64_6.2.build.configure.args= \ >> - --with-toolchain-version=2013 >> +jprt.windows_x64.build.configure.args= \ >> + --with-devkit=$VS2013_HOME >> +jprt.macosx_x64.build.configure.args= \ >> + --with-devkit=$XCODE_511_HOME >> >> ######## >> # >> > From joe.darcy at oracle.com Mon Jun 29 19:16:44 2015 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 29 Jun 2015 12:16:44 -0700 Subject: JDK 9 RFR of JDK-8080722: Revisit how to check for doclint reference warning during the build Message-ID: <5591999C.8070707@oracle.com> Hello, A fix for JDK-8129909: Add -Xdoclint/packages: to javadoc https://bugs.openjdk.java.net/browse/JDK-8129909 is working its way through the system, in anticipation of that fix, please view my fix for JDK-8080722: Revisit how to check for doclint reference warning during the build Patch below: --- a/make/Javadoc.gmk Tue Jun 23 15:11:56 2015 +0200 +++ b/make/Javadoc.gmk Mon Jun 29 12:11:03 2015 -0700 @@ -410,7 +410,8 @@ $(prep-target) @($(call COMMON_JAVADOCFLAGS) ; \ $(call COMMON_JAVADOCTAGS) ; \ - $(call OptionOnly,-Xdoclint:none) ; \ + $(call OptionOnly,-Xdoclint:reference) ; \ + $(call OptionOnly,-Xdoclint/package:-org.omg.*) ; \ $(call OptionPair,-sourcepath,$(RELEASEDOCS_SOURCEPATH)) ; \ $(call OptionPair,-encoding,ISO-8859-1) ; \ $(call OptionOnly,-splitIndex) ; \ As discussed on jdk9-dev, this fix will allow JEP 212 to be completed. http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002343.html Just to be clear, I would not push the fix for JDK-8080722 until the fix for JDK-8080722 is in the jdk 9 dev forest. Additionally, I'll verify the build still works at that point with the patch above. Thanks, -Joe From alejandro.murillo at oracle.com Tue Jun 30 00:31:34 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 29 Jun 2015 18:31:34 -0600 Subject: RFR JDK-8130092: Backout Update jprt.properties with property listing tests subtrees Message-ID: <5591E366.6050608@oracle.com> We need to backout this change JDK-8098834: https://bugs.openjdk.java.net/browse/JDK-8098834 as it is impeding the execution of some jprt tests for control jobs and hence the integration of jdk9/hs into jdk9/dev Webrev: http://cr.openjdk.java.net/~amurillo/9/8130092/ CR: https://bugs.openjdk.java.net/browse/JDK-8130092 Thanks -- Alejandro From david.holmes at oracle.com Tue Jun 30 00:34:00 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jun 2015 10:34:00 +1000 Subject: RFR JDK-8130092: Backout Update jprt.properties with property listing tests subtrees In-Reply-To: <5591E366.6050608@oracle.com> References: <5591E366.6050608@oracle.com> Message-ID: <5591E3F8.5000806@oracle.com> Looks good Alejandro! We'll work with Dmitry to figure out the problem. Thanks, David On 30/06/2015 10:31 AM, Alejandro E Murillo wrote: > > We need to backout this change JDK-8098834: > https://bugs.openjdk.java.net/browse/JDK-8098834 > > as it is impeding the execution of some jprt tests for > control jobs and hence the integration of jdk9/hs into jdk9/dev > > Webrev: http://cr.openjdk.java.net/~amurillo/9/8130092/ > > CR: https://bugs.openjdk.java.net/browse/JDK-8130092 > > Thanks > From alejandro.murillo at oracle.com Tue Jun 30 00:39:32 2015 From: alejandro.murillo at oracle.com (Alejandro E Murillo) Date: Mon, 29 Jun 2015 18:39:32 -0600 Subject: RFR JDK-8130092: Backout Update jprt.properties with property listing tests subtrees In-Reply-To: <5591E3F8.5000806@oracle.com> References: <5591E366.6050608@oracle.com> <5591E3F8.5000806@oracle.com> Message-ID: <5591E544.7000000@oracle.com> sounds good David Thanks Alejandro On 6/29/2015 6:34 PM, David Holmes wrote: > Looks good Alejandro! > > We'll work with Dmitry to figure out the problem. > > Thanks, > David > > On 30/06/2015 10:31 AM, Alejandro E Murillo wrote: >> >> We need to backout this change JDK-8098834: >> https://bugs.openjdk.java.net/browse/JDK-8098834 >> >> as it is impeding the execution of some jprt tests for >> control jobs and hence the integration of jdk9/hs into jdk9/dev >> >> Webrev: http://cr.openjdk.java.net/~amurillo/9/8130092/ >> >> CR: https://bugs.openjdk.java.net/browse/JDK-8130092 >> >> Thanks >> -- Alejandro From david.holmes at oracle.com Tue Jun 30 02:03:49 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jun 2015 12:03:49 +1000 Subject: [8u60] RFR: 8129926: Sub-packages in jdk.* are present in all Compact Profiles when they should not be Message-ID: <5591F905.40306@oracle.com> This is a non-public bug as it pertains to our closed sources, but the remedy is in the open file make/profile-rtjar-includes.txt A new package, jdk.internal.instrumentation, was appearing in the compact 1 profile when it should only be in the full JRE - so we add it to the list of packages only in the full JRE. This exposed another package that was being included in compact 2, when it also should only be in a full JRE. http://cr.openjdk.java.net/~dholmes/8129926/webrev/ *** 205,214 **** --- 205,216 ---- javax/sound \ javax/swing \ javax/xml/bind \ javax/xml/soap \ javax/xml/ws \ + jdk/internal/instrumentation \ + jdk/management/resource \ org/omg \ Thanks, David From Alan.Bateman at oracle.com Tue Jun 30 06:48:19 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Jun 2015 07:48:19 +0100 Subject: [8u60] RFR: 8129926: Sub-packages in jdk.* are present in all Compact Profiles when they should not be In-Reply-To: <5591F905.40306@oracle.com> References: <5591F905.40306@oracle.com> Message-ID: <55923BB3.8070301@oracle.com> On 30/06/2015 03:03, David Holmes wrote: > : > > http://cr.openjdk.java.net/~dholmes/8129926/webrev/ > > *** 205,214 **** > --- 205,216 ---- > javax/sound \ > javax/swing \ > javax/xml/bind \ > javax/xml/soap \ > javax/xml/ws \ > + jdk/internal/instrumentation \ > + jdk/management/resource \ > org/omg \ This looks okay. -Alan From david.holmes at oracle.com Tue Jun 30 07:07:25 2015 From: david.holmes at oracle.com (David Holmes) Date: Tue, 30 Jun 2015 17:07:25 +1000 Subject: [8u60] RFR: 8129926: Sub-packages in jdk.* are present in all Compact Profiles when they should not be In-Reply-To: <55923BB3.8070301@oracle.com> References: <5591F905.40306@oracle.com> <55923BB3.8070301@oracle.com> Message-ID: <5592402D.8030608@oracle.com> Thanks Alan! David On 30/06/2015 4:48 PM, Alan Bateman wrote: > > > On 30/06/2015 03:03, David Holmes wrote: >> : >> >> http://cr.openjdk.java.net/~dholmes/8129926/webrev/ >> >> *** 205,214 **** >> --- 205,216 ---- >> javax/sound \ >> javax/swing \ >> javax/xml/bind \ >> javax/xml/soap \ >> javax/xml/ws \ >> + jdk/internal/instrumentation \ >> + jdk/management/resource \ >> org/omg \ > This looks okay. > > -Alan From erik.joelsson at oracle.com Tue Jun 30 07:49:57 2015 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Tue, 30 Jun 2015 09:49:57 +0200 Subject: RFR: JDK-8130109: Incremental build of java.base-gensrc broken Message-ID: <55924A25.70403@oracle.com> Hello, Please review this small patch which fixes the incremental build of java.base-gensrc. There is a slight mistake in jdk/make/gensrc/GensrcCLDR.gmk where the target file of a rule has the wrong path, so make will always think it needs to be generated. Bug: https://bugs.openjdk.java.net/browse/JDK-8130109 Patch: diff -r 68ce12551103 make/gensrc/GensrcCLDR.gmk --- a/make/gensrc/GensrcCLDR.gmk +++ b/make/gensrc/GensrcCLDR.gmk @@ -29,7 +29,7 @@ GENSRC_BASEDIR := $(SUPPORT_OUTPUTDIR)/gensrc/java.base GENSRC_DIR := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata -CLDR_BASEMETAINFO_FILE := $(GENSRC_DIR)/sun/util/cldr/CLDRBaseLocaleDataMetaInfo.java +CLDR_BASEMETAINFO_FILE := $(GENSRC_BASEDIR)/sun/util/cldr/CLDRBaseLocaleDataMetaInfo.java CLDR_METAINFO_FILE := $(GENSRC_DIR)/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java CLDR_BASE_LOCALES := "en-US" /Erik From tim.bell at oracle.com Tue Jun 30 14:08:49 2015 From: tim.bell at oracle.com (Tim Bell) Date: Tue, 30 Jun 2015 07:08:49 -0700 Subject: RFR: JDK-8130109: Incremental build of java.base-gensrc broken In-Reply-To: <55924A25.70403@oracle.com> References: <55924A25.70403@oracle.com> Message-ID: <5592A2F1.80804@oracle.com> Hi Erik: > Please review this small patch which fixes the incremental build of > java.base-gensrc. There is a slight mistake in > jdk/make/gensrc/GensrcCLDR.gmk where the target file of a rule has the > wrong path, so make will always think it needs to be generated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130109 > > Patch: > > diff -r 68ce12551103 make/gensrc/GensrcCLDR.gmk > --- a/make/gensrc/GensrcCLDR.gmk > +++ b/make/gensrc/GensrcCLDR.gmk > @@ -29,7 +29,7 @@ > GENSRC_BASEDIR := $(SUPPORT_OUTPUTDIR)/gensrc/java.base > GENSRC_DIR := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata > > -CLDR_BASEMETAINFO_FILE := > $(GENSRC_DIR)/sun/util/cldr/CLDRBaseLocaleDataMetaInfo.java > +CLDR_BASEMETAINFO_FILE := > $(GENSRC_BASEDIR)/sun/util/cldr/CLDRBaseLocaleDataMetaInfo.java > CLDR_METAINFO_FILE := > $(GENSRC_DIR)/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java > > CLDR_BASE_LOCALES := "en-US" Looks good to me. /Tim From naoto.sato at oracle.com Tue Jun 30 16:39:36 2015 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 30 Jun 2015 09:39:36 -0700 Subject: RFR: JDK-8130109: Incremental build of java.base-gensrc broken In-Reply-To: <55924A25.70403@oracle.com> References: <55924A25.70403@oracle.com> Message-ID: <5592C648.1000005@oracle.com> +1 Naoto On 6/30/15 12:49 AM, Erik Joelsson wrote: > Hello, > > Please review this small patch which fixes the incremental build of > java.base-gensrc. There is a slight mistake in > jdk/make/gensrc/GensrcCLDR.gmk where the target file of a rule has the > wrong path, so make will always think it needs to be generated. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8130109 > > Patch: > > diff -r 68ce12551103 make/gensrc/GensrcCLDR.gmk > --- a/make/gensrc/GensrcCLDR.gmk > +++ b/make/gensrc/GensrcCLDR.gmk > @@ -29,7 +29,7 @@ > GENSRC_BASEDIR := $(SUPPORT_OUTPUTDIR)/gensrc/java.base > GENSRC_DIR := $(SUPPORT_OUTPUTDIR)/gensrc/jdk.localedata > > -CLDR_BASEMETAINFO_FILE := > $(GENSRC_DIR)/sun/util/cldr/CLDRBaseLocaleDataMetaInfo.java > +CLDR_BASEMETAINFO_FILE := > $(GENSRC_BASEDIR)/sun/util/cldr/CLDRBaseLocaleDataMetaInfo.java > CLDR_METAINFO_FILE := > $(GENSRC_DIR)/sun/util/resources/cldr/provider/CLDRLocaleDataMetaInfo_jdk_localedata.java > > > CLDR_BASE_LOCALES := "en-US" > > /Erik