Re: Solaris jdk9 build problem
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@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/s
Re: official compiler for Solaris jdk9 build?
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
Re: JDK 9 RFR of JDK-8072480: javac should support compilation for a specific platform version
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
Re: official compiler for Solaris jdk9 build?
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
RFR: JDK-8081692 Configure should verify that -fstack-protector is valid
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
Re: RFR: JDK-8081692 Configure should verify that -fstack-protector is valid
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
Re: RFR: JDK-8081692 Configure should verify that -fstack-protector is valid
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
dist-clean won't delete log files
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
Re: RFR 7191662: JCE providers should be located via ServiceLoader
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)
Re: dist-clean won't delete log files
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
Re: Request for guidance on fixing JDK-8075571: Support tier1 and tier2 make targets
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/MakefileThu May 28 11:31:40 2015 -0700 +++ b/test/MakefileTue 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
need to build a DLL for an openjdk test
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
Re: need to build a DLL for an openjdk test
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
Re: need to build a DLL for an openjdk test
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
Re: need to build a DLL for an openjdk test
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
Re: RFR: JDK-8081692 Configure should verify that -fstack-protector is valid
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
