Re: RFR: JDK-8072732 Regression in configure due to JDK-8069057
Magnus: Looks good to me as well. Tim On 02/10/15 14:48, Erik Joelsson wrote: Looks good. /Erik On 2015-02-10 15:46, Magnus Ihse Bursie wrote: The fix for JDK-8069057 caused the configure script to respawn due to autoconf entry code. This causes all sorts of weird behaviour, especially when running “make reconfigure”. We need to tell autoconf not to respawn, since we have already figured out the correct shell. * Bug: https://bugs.openjdk.java.net/browse/JDK-8072732 * Patch inline: |diff --git a/common/autoconf/configure b/common/autoconf/configure --- a/common/autoconf/configure +++ b/common/autoconf/configure @@ -40,8 +40,9 @@ echo "Error: This script must be run using bash." 1>&2 exit 1 fi -# Force autoconf to use bash +# Force autoconf to use bash. This also means we must disable autoconf re-exec. export CONFIG_SHELL=$BASH +export _as_can_reexec=no conf_script_dir="$TOPDIR/common/autoconf" | /Magnus
Re: RFR: JDK-8072132 filter out additional files when stripping
Magnus: Looks good to me as well. Tim On 02/10/15 14:49, Erik Joelsson wrote: Looks good. /Erik On 2015-02-10 15:43, Magnus Ihse Bursie wrote: It turned out that an internal Oracle tool produces *.bc files in the build support directories. When trying to strip those files, we fail. This fix will filter out such files in StripBinaries.gmk: diff --git a/make/StripBinaries.gmk b/make/StripBinaries.gmk --- a/make/StripBinaries.gmk +++ b/make/StripBinaries.gmk @@ -53,7 +53,7 @@ endif # Don't include debug info for executables. -ALL_CMDS_SRC := $(filter-out %.debuginfo %.diz %.map %.pdb, \ +ALL_CMDS_SRC := $(filter-out %.bc %.debuginfo %.diz %.map %.pdb, \ $(shell $(FIND) $(SUPPORT_OUTPUTDIR)/modules_cmds -type f -o -type l)) COPY_CMDS_SRC := $(filter %.cgi, $(ALL_CMDS_SRC)) STRIP_CMDS_SRC := $(filter-out $(COPY_CMDS_SRC), $(ALL_CMDS_SRC)) /Magnus
Re: RFR: JDK-8072842 Add support for building native JTReg tests
Hi Magnus, On 11/02/2015 12:23 AM, Magnus Ihse Bursie wrote: Here is an addition to the build system, that will compile native libraries and executables and make them available for JTReg tests written in Java. Sorry I'm missing the basics here: when does this compilation take place? As part of a normal build? Where will the build artifacts go? Thanks, David H. This patch is the result of the work (in serial, mostly) of Staffan Larsen, David Simms and me. (And possible more that I don't know about.) In it current form, the patch only provides the framework on which to attach real tests. To prove the concept, some initial dummy tests are present. These are supposed to be removed as soon as real tests starts to propagate into the jdk and hotspot jtreg test suites. The behavior is based on the following design: For directories with native jtreg compilation enabled, the build system searches for native files prefixed with either "lib" or "exe", and compiles a free-standing library or an executable, respectively, for each such file. Since all compiled files are placed in a single directory (this is currently a requirement from the jtreg native support), there is the additional requirement that all files have unique names. My personal opinion is that a better long-term approach is to compile all tests into a single library, if possible. (I realize some tests need to be separate to test library loading, etc.) For that to work, however, JTReg needs to be changed. The build framework in the patch is designed in such a way that it will be easy to add compilation to a common library in the future, if that restriction is lifted from JTReg. This patch also lays the foundation for building additional tests, not only native jtreg tests, by the build system in the future. For instance, it codifies the suggested correspondence between make targets, intermediate test output and test image final build results. With the on-going test co-location project, we expect a stream of tests to be added to the build system in the future, and we hope this project can serve as an example of a suitable way of integration. The patch modifies hotspot code, but it's mostly due to the addition of the new dummy tests. My preference would be to integrate this patch via jdk9-dev, since it modifies the build system most of all, but I'm open for discussion. Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 /Magnus
Re: Build jdk9 on os x, No compiler1
On 11/02/2015 4:43 AM, Mihail Stoynov wrote: Hi, I'm trying to build jdk9 on osx, without any customizations: $ hg clone http://hg.openjdk.java.net/jdk9/dev jdk9.hg $ cd jdk9.hg $ chmod u+x get_source.sh $ ./get_source.sh $ chmod u+x configure $ ./configure $ make clean images And it fails with: *No compiler1 (product1) for ARCH_DATA_MODEL=64*warning: [options] bootstrap class path not set in conjunction with -source 1.6 1 warning Generating bsd_amd64_docs/jvmti.html make[1]: *** [main-wrapper] Error 2 make: *** [clean] Error 2 real 5m9.066s Something not right there - we shouldn't be generating anything during a clean phase, and the clean is a sequential target. Can you do "make LOG_LEVEL=debug" clean images" The configure script shows only server VM being requested. Thanks, David user 8m56.232s sys 0m55.382s ma:jdk9.hg c00l$ From what I've seen "64-bit client VM is not supported" http://mail.openjdk.java.net/pipermail/build-dev/2013-April/008633.html I don't want 64-bit client if it is not supported. But how do I say that? Any issue how to solve it? Best regards, Mihail Bulgarian JUG
Correct way to copy os specific files over general shared files
Hello, build team. I would like to know how to correctly replace some file in the shared folder by more specific file from windows/macosx/unix folder during the build. Will magic works automatically if I place in CompileJavaModules.gmk: java.desktop_COPY := SOME_FILE.gif Or there is some other way? Thanks.
Re: Build jdk9 on os x, No compiler1
Sure, Here you go: http://bgjug.sty.bz/bgjug/misc/configure.log Mihail Bulgarian JUG On Tue, Feb 10, 2015 at 11:27 PM, Magnus Ihse Bursie < magnus.ihse.bur...@oracle.com> wrote: > Mihail, > > Can you post the output of the configure script here? > > /Magnus > > > 10 feb 2015 kl. 19:43 skrev Mihail Stoynov : > > > > Hi, > > I'm trying to build jdk9 on osx, without any customizations: > > > > $ hg clone http://hg.openjdk.java.net/jdk9/dev jdk9.hg > > > > $ cd jdk9.hg > > $ chmod u+x get_source.sh > > $ ./get_source.sh > > > > $ chmod u+x configure > > > > $ ./configure > > $ make clean images > > > > > > And it fails with: > > > > > > > >> *No compiler1 (product1) for ARCH_DATA_MODEL=64*warning: [options] > >> bootstrap class path not set in conjunction with -source 1.6 > >> 1 warning > >> Generating bsd_amd64_docs/jvmti.html > >> make[1]: *** [main-wrapper] Error 2 > >> make: *** [clean] Error 2 real 5m9.066s > >> user 8m56.232s > >> sys 0m55.382s > >> ma:jdk9.hg c00l$ > > > > > > From what I've seen "64-bit client VM is not supported" > > http://mail.openjdk.java.net/pipermail/build-dev/2013-April/008633.html > > > > I don't want 64-bit client if it is not supported. But how do I say that? > > > > Any issue how to solve it? > > > > Best regards, > > Mihail > > Bulgarian JUG >
Re: Build jdk9 on os x, No compiler1
Mihail, Can you post the output of the configure script here? /Magnus > 10 feb 2015 kl. 19:43 skrev Mihail Stoynov : > > Hi, > I'm trying to build jdk9 on osx, without any customizations: > > $ hg clone http://hg.openjdk.java.net/jdk9/dev jdk9.hg > > $ cd jdk9.hg > $ chmod u+x get_source.sh > $ ./get_source.sh > > $ chmod u+x configure > > $ ./configure > $ make clean images > > > And it fails with: > > > >> *No compiler1 (product1) for ARCH_DATA_MODEL=64*warning: [options] >> bootstrap class path not set in conjunction with -source 1.6 >> 1 warning >> Generating bsd_amd64_docs/jvmti.html >> make[1]: *** [main-wrapper] Error 2 >> make: *** [clean] Error 2 real 5m9.066s >> user 8m56.232s >> sys 0m55.382s >> ma:jdk9.hg c00l$ > > > From what I've seen "64-bit client VM is not supported" > http://mail.openjdk.java.net/pipermail/build-dev/2013-April/008633.html > > I don't want 64-bit client if it is not supported. But how do I say that? > > Any issue how to solve it? > > Best regards, > Mihail > Bulgarian JUG
Build jdk9 on os x, No compiler1
Hi, I'm trying to build jdk9 on osx, without any customizations: $ hg clone http://hg.openjdk.java.net/jdk9/dev jdk9.hg $ cd jdk9.hg $ chmod u+x get_source.sh $ ./get_source.sh $ chmod u+x configure $ ./configure $ make clean images And it fails with: > *No compiler1 (product1) for ARCH_DATA_MODEL=64*warning: [options] > bootstrap class path not set in conjunction with -source 1.6 > 1 warning > Generating bsd_amd64_docs/jvmti.html > make[1]: *** [main-wrapper] Error 2 > make: *** [clean] Error 2 real 5m9.066s > user 8m56.232s > sys 0m55.382s > ma:jdk9.hg c00l$ >From what I've seen "64-bit client VM is not supported" http://mail.openjdk.java.net/pipermail/build-dev/2013-April/008633.html I don't want 64-bit client if it is not supported. But how do I say that? Any issue how to solve it? Best regards, Mihail Bulgarian JUG
Re: JDK6 security updates
On 02/10/2015 05:40 PM, Andrew Haley wrote: > On 02/10/2015 05:36 PM, matchew wrote: >> Is JDK6 still maintained and provides security updates > > Yes. OpenJDK 6, that is. Andrew.
Re: JDK6 security updates
On 02/10/2015 05:36 PM, matchew wrote: > Is JDK6 still maintained and provides security updates Yes. Andrew.
JDK6 security updates
Is JDK6 still maintained and provides security updates or has it reached end of life already / will reach soon (when)?
Re: RFR: JDK-8072842 Add support for building native JTReg tests
> 10 feb 2015 kl. 16:10 skrev Staffan Larsen : > > >> On 10 feb 2015, at 15:23, Magnus Ihse Bursie >> wrote: >> >> Here is an addition to the build system, that will compile native libraries >> and executables and make them available for JTReg tests written in Java. >> >> This patch is the result of the work (in serial, mostly) of Staffan Larsen, >> David Simms and me. (And possible more that I don't know about.) >> >> In it current form, the patch only provides the framework on which to attach >> real tests. To prove the concept, some initial dummy tests are present. >> These are supposed to be removed as soon as real tests starts to propagate >> into the jdk and hotspot jtreg test suites. >> >> The behavior is based on the following design: For directories with native >> jtreg compilation enabled, the build system searches for native files >> prefixed with either "lib" or "exe", and compiles a free-standing library or >> an executable, respectively, for each such file. Since all compiled files >> are placed in a single directory (this is currently a requirement from the >> jtreg native support), there is the additional requirement that all files >> have unique names. >> >> My personal opinion is that a better long-term approach is to compile all >> tests into a single library, if possible. (I realize some tests need to be >> separate to test library loading, etc.) For that to work, however, JTReg >> needs to be changed. The build framework in the patch is designed in such a >> way that it will be easy to add compilation to a common library in the >> future, if that restriction is lifted from JTReg. > > To clarify: The restriction in jtreg is that all tests are loaded in separate > class loaders (when running in samevm mode). A native library can only be > loaded in one class loader at a time. So if two tests tries to load the same > library we get errors. It would be possible to change this if samevm mode is > removed from jtreg. I thought the problem was that we try to load the same library multiple times by different classloaders, and that the solution was to load the library only once, e.g. by the jtreg framework before launching samevm tests. However, if the library has to be loaded by the class loader in which the test executes, this will not work. :( Nevertheless, this discussion is tangential to the current review. If it is possible to add a singe-library approach to jtreg without sacrificing functionality, I believe that is a good thing, and this patch supports such an extension. If not, the current patch works anyway. /Magnus > > /Staffan > >> >> This patch also lays the foundation for building additional tests, not only >> native jtreg tests, by the build system in the future. For instance, it >> codifies the suggested correspondence between make targets, intermediate >> test output and test image final build results. With the on-going test >> co-location project, we expect a stream of tests to be added to the build >> system in the future, and we hope this project can serve as an example of a >> suitable way of integration. >> >> The patch modifies hotspot code, but it's mostly due to the addition of the >> new dummy tests. My preference would be to integrate this patch via >> jdk9-dev, since it modifies the build system most of all, but I'm open for >> discussion. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 >> WebRev: >> http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 >> >> /Magnus >
Re: Build error with javac Main not being found when building java.transaction module on Mac OS X
Hi Magnus,
I had been working on the README-build.html file, but apart from that
nothing else.
Cheers,
Martijn
On 10 February 2015 at 08:53, Magnus Ihse Bursie <
magnus.ihse.bur...@oracle.com> wrote:
> That sounds a bit weird. get_source should do a pull and update on the
> top-level repo as well, so a separate hg update should not be needed.
>
> Did you have local changes requiring a merge?
>
> /Magnus
>
> > 9 feb 2015 kl. 12:46 skrev Martijn Verburg :
> >
> > @Erik and everyone else,
> >
> > , my sincere apologies and thank you for your
> > patience! Indeed the modules.xml file was out of date. My script which
> > executes 'hg update' each morning had been silently failing for some
> time.
> > This is a good lesson for the build guide though, I'll add a note to
> remind
> > people that once they clone the top level repository that they should
> also
> > hg update as well as ./get_source.sh.
> >
> > I now have separate build errors (of course!), these ones seem a little
> > more genuine, around the compilation / linking of desktop code with Mac
> > native libs. There are too many to list, but here's an example of one
> below
> >
> > ===
> >
> > Creating libjsound.dylib from 17 file(s)
> > In file included from /usr/include/dispatch/dispatch.h:51:0,
> > from
> >
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
> > from
> >
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
> > from
> >
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
> > from
> > /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6,
> > from
> > /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
> > from
> >
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.desktop/macosx/native/libosxapp/AWT_debug.h:29,
> > from
> >
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.desktop/macosx/native/libosxapp/AWT_debug.m:26:
> > /usr/include/dispatch/object.h:143:15: error: expected identifier or '('
> > before '^' token
> > typedef void (^dispatch_block_t)(void);
> > ^
> > /usr/include/dispatch/object.h:362:3: error: unknown type name
> > 'dispatch_block_t'
> > dispatch_block_t notification_block);
> > ^
> >
> > Is this perhaps me using an unsupported compiler? My C/C++ toolchain is:
> >
> > ...
> > * Toolchain: clang (clang/LLVM)
> > * C Compiler: Version Apple LLVM version 6.0 (clang-600.0.56) (based
> on
> > LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
> > /usr/bin/clang)
> > * C++ Compiler: Version Apple LLVM version 6.0 (clang-600.0.56) (based
> on
> > LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
> > /usr/bin/clang++)
> > ...
> >
> >
> >
> > Cheers,
> > Martijn
> >
> >> On 9 February 2015 at 10:35, Erik Joelsson
> wrote:
> >>
> >> Then please check that your top level repo is properly up to date. It
> >> should contain:
> >>
> >>
> >>java.transaction
> >>java.base
> >>java.rmi
> >>
> >> javax.transaction
> >>
> >>
> >>
> >> /Erik
> >>
> >>
> >> On 2015-02-09 11:32, Martijn Verburg wrote:
> >>
> >> Hi Erik,
> >>
> >> You're correct, the module-deps.gmk file does not have java.transaction
> >> in there.
> >>
> >> modules.xml does contain it as an export for java.corba (which depends
> >> on java.base), i.e.
> >>
> >>
> >>java.corba
> >>java.base
> >>java.desktop
> >>java.logging
> >>java.naming
> >>java.rmi
> >> ...
> >>
> >> javax.transaction
> >>
> >> ...
> >>
> >> I'm also going to try Magnus's suggestion.
> >>
> >> Cheers,
> >> Martijn
> >>
> >> On 9 February 2015 at 09:32, Erik Joelsson
> >> wrote:
> >>
> >>> So you have the source files for java.transaction in your jdk repo.
> Does
> >>> your modules.xml list that module? At the start of the build, we
> generate
> >>> build//make-support/module-deps.gmk from modules.xml from
> which
> >>> we construct the correct make dependencies between module targets. I'm
> >>> guessing java.transaction is not showing up in your module-deps.gmk.
> >>>
> >>> If java.transaction doesn't show up in modules-deps.gmk, we are missing
> >>> that java.transaction-java depends on java.base-java, so make will
> start
> >>> running java.transaction-java earlier than it should.
> >>>
> >>> /Erik
> >>>
> >>>
> On 2015-02-06 16:45, Martijn Verburg wrote:
>
> Hi Erik/Alan,
>
> Not sure if this information is useful at all but the following tmp
> file
> was left behind:
>
>
>
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-
> x86_64-normal-server-release/jdk/modules/java.transaction/_
> the.java.transaction_batch.tmp
>
> It contains:
>
>
>
> /Users/karianna/
Re: RFR: JDK-8072842 Add support for building native JTReg tests
> On 10 feb 2015, at 15:23, Magnus Ihse Bursie > wrote: > > Here is an addition to the build system, that will compile native libraries > and executables and make them available for JTReg tests written in Java. > > This patch is the result of the work (in serial, mostly) of Staffan Larsen, > David Simms and me. (And possible more that I don't know about.) > > In it current form, the patch only provides the framework on which to attach > real tests. To prove the concept, some initial dummy tests are present. These > are supposed to be removed as soon as real tests starts to propagate into the > jdk and hotspot jtreg test suites. > > The behavior is based on the following design: For directories with native > jtreg compilation enabled, the build system searches for native files > prefixed with either "lib" or "exe", and compiles a free-standing library or > an executable, respectively, for each such file. Since all compiled files are > placed in a single directory (this is currently a requirement from the jtreg > native support), there is the additional requirement that all files have > unique names. > > My personal opinion is that a better long-term approach is to compile all > tests into a single library, if possible. (I realize some tests need to be > separate to test library loading, etc.) For that to work, however, JTReg > needs to be changed. The build framework in the patch is designed in such a > way that it will be easy to add compilation to a common library in the > future, if that restriction is lifted from JTReg. To clarify: The restriction in jtreg is that all tests are loaded in separate class loaders (when running in samevm mode). A native library can only be loaded in one class loader at a time. So if two tests tries to load the same library we get errors. It would be possible to change this if samevm mode is removed from jtreg. /Staffan > > This patch also lays the foundation for building additional tests, not only > native jtreg tests, by the build system in the future. For instance, it > codifies the suggested correspondence between make targets, intermediate test > output and test image final build results. With the on-going test co-location > project, we expect a stream of tests to be added to the build system in the > future, and we hope this project can serve as an example of a suitable way of > integration. > > The patch modifies hotspot code, but it's mostly due to the addition of the > new dummy tests. My preference would be to integrate this patch via jdk9-dev, > since it modifies the build system most of all, but I'm open for discussion. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 > > /Magnus
Re: RFR: JDK-8072132 filter out additional files when stripping
Looks good. /Erik On 2015-02-10 15:43, Magnus Ihse Bursie wrote: It turned out that an internal Oracle tool produces *.bc files in the build support directories. When trying to strip those files, we fail. This fix will filter out such files in StripBinaries.gmk: diff --git a/make/StripBinaries.gmk b/make/StripBinaries.gmk --- a/make/StripBinaries.gmk +++ b/make/StripBinaries.gmk @@ -53,7 +53,7 @@ endif # Don't include debug info for executables. -ALL_CMDS_SRC := $(filter-out %.debuginfo %.diz %.map %.pdb, \ +ALL_CMDS_SRC := $(filter-out %.bc %.debuginfo %.diz %.map %.pdb, \ $(shell $(FIND) $(SUPPORT_OUTPUTDIR)/modules_cmds -type f -o -type l)) COPY_CMDS_SRC := $(filter %.cgi, $(ALL_CMDS_SRC)) STRIP_CMDS_SRC := $(filter-out $(COPY_CMDS_SRC), $(ALL_CMDS_SRC)) /Magnus
Re: RFR: JDK-8072732 Regression in configure due to JDK-8069057
Looks good. /Erik On 2015-02-10 15:46, Magnus Ihse Bursie wrote: The fix for JDK-8069057 caused the configure script to respawn due to autoconf entry code. This causes all sorts of weird behaviour, especially when running “make reconfigure”. We need to tell autoconf not to respawn, since we have already figured out the correct shell. * Bug: https://bugs.openjdk.java.net/browse/JDK-8072732 * Patch inline: |diff --git a/common/autoconf/configure b/common/autoconf/configure --- a/common/autoconf/configure +++ b/common/autoconf/configure @@ -40,8 +40,9 @@ echo "Error: This script must be run using bash." 1>&2 exit 1 fi -# Force autoconf to use bash +# Force autoconf to use bash. This also means we must disable autoconf re-exec. export CONFIG_SHELL=$BASH +export _as_can_reexec=no conf_script_dir="$TOPDIR/common/autoconf" | /Magnus
RFR: JDK-8072732 Regression in configure due to JDK-8069057
The fix for JDK-8069057 caused the configure script to respawn due to autoconf entry code. This causes all sorts of weird behaviour, especially when running “make reconfigure”. We need to tell autoconf not to respawn, since we have already figured out the correct shell. * Bug: https://bugs.openjdk.java.net/browse/JDK-8072732 * Patch inline: |diff --git a/common/autoconf/configure b/common/autoconf/configure --- a/common/autoconf/configure +++ b/common/autoconf/configure @@ -40,8 +40,9 @@ echo "Error: This script must be run using bash." 1>&2 exit 1 fi -# Force autoconf to use bash +# Force autoconf to use bash. This also means we must disable autoconf re-exec. export CONFIG_SHELL=$BASH +export _as_can_reexec=no conf_script_dir="$TOPDIR/common/autoconf" | /Magnus
RFR: JDK-8072132 filter out additional files when stripping
It turned out that an internal Oracle tool produces *.bc files in the build support directories. When trying to strip those files, we fail. This fix will filter out such files in StripBinaries.gmk: diff --git a/make/StripBinaries.gmk b/make/StripBinaries.gmk --- a/make/StripBinaries.gmk +++ b/make/StripBinaries.gmk @@ -53,7 +53,7 @@ endif # Don't include debug info for executables. -ALL_CMDS_SRC := $(filter-out %.debuginfo %.diz %.map %.pdb, \ +ALL_CMDS_SRC := $(filter-out %.bc %.debuginfo %.diz %.map %.pdb, \ $(shell $(FIND) $(SUPPORT_OUTPUTDIR)/modules_cmds -type f -o -type l)) COPY_CMDS_SRC := $(filter %.cgi, $(ALL_CMDS_SRC)) STRIP_CMDS_SRC := $(filter-out $(COPY_CMDS_SRC), $(ALL_CMDS_SRC)) /Magnus
RFR: JDK-8072842 Add support for building native JTReg tests
Here is an addition to the build system, that will compile native libraries and executables and make them available for JTReg tests written in Java. This patch is the result of the work (in serial, mostly) of Staffan Larsen, David Simms and me. (And possible more that I don't know about.) In it current form, the patch only provides the framework on which to attach real tests. To prove the concept, some initial dummy tests are present. These are supposed to be removed as soon as real tests starts to propagate into the jdk and hotspot jtreg test suites. The behavior is based on the following design: For directories with native jtreg compilation enabled, the build system searches for native files prefixed with either "lib" or "exe", and compiles a free-standing library or an executable, respectively, for each such file. Since all compiled files are placed in a single directory (this is currently a requirement from the jtreg native support), there is the additional requirement that all files have unique names. My personal opinion is that a better long-term approach is to compile all tests into a single library, if possible. (I realize some tests need to be separate to test library loading, etc.) For that to work, however, JTReg needs to be changed. The build framework in the patch is designed in such a way that it will be easy to add compilation to a common library in the future, if that restriction is lifted from JTReg. This patch also lays the foundation for building additional tests, not only native jtreg tests, by the build system in the future. For instance, it codifies the suggested correspondence between make targets, intermediate test output and test image final build results. With the on-going test co-location project, we expect a stream of tests to be added to the build system in the future, and we hope this project can serve as an example of a suitable way of integration. The patch modifies hotspot code, but it's mostly due to the addition of the new dummy tests. My preference would be to integrate this patch via jdk9-dev, since it modifies the build system most of all, but I'm open for discussion. Bug: https://bugs.openjdk.java.net/browse/JDK-8072842 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8072842-build-native-jtreg-tests/webrev.01 /Magnus
Re: RFR: JDK-8072834: jrt-fs.jar missing META-INF/services/java.nio.file.spi.FileSystemProvider
On 2015-02-10 11:54, Erik Joelsson wrote: Hello, Please review this fix for the missing META-INF/services/java.nio.file.spi.FileSystemProvider in jrt-fs.jar. In JDK-8071550, I changed the logic of INCLUDES and EXCLUDES parameters to SetupJavaCompilation to also affect META-INF files consistently. Since then, jrt-fs.jar is no longer including the file system provider. The fix is to explicitly copy that file. Due to how the EXCLUDES and INCLUDES rules work in that macro, there was no easy way of expressing inclusion of just that file. (When specifying both INCLUDES and INCLUDE_FILES, only the intersection between the two is included, not the union which one might expect.) I did contemplate changing the rules, but decided this was not the time. Bug: https://bugs.openjdk.java.net/browse/JDK-8072834 Webrev: http://cr.openjdk.java.net/~erikj/8072834/webrev.jdk.01/ Looks good to me. But, as I have expressed to you privately, we should really redesign the include/exclude interface. I'd like to see the logic for file selection (search dirs, include/exclude patterns, additional files) to be separated out of the individual SetupFoo macros, and into a separate helper function. We can then make sure that maximum power of expression and correctness is applied to all macros, and we'd get identical syntax. But as you say, this is probably not the time. /Magnus
RFR: JDK-8072834: jrt-fs.jar missing META-INF/services/java.nio.file.spi.FileSystemProvider
Hello, Please review this fix for the missing META-INF/services/java.nio.file.spi.FileSystemProvider in jrt-fs.jar. In JDK-8071550, I changed the logic of INCLUDES and EXCLUDES parameters to SetupJavaCompilation to also affect META-INF files consistently. Since then, jrt-fs.jar is no longer including the file system provider. The fix is to explicitly copy that file. Due to how the EXCLUDES and INCLUDES rules work in that macro, there was no easy way of expressing inclusion of just that file. (When specifying both INCLUDES and INCLUDE_FILES, only the intersection between the two is included, not the union which one might expect.) I did contemplate changing the rules, but decided this was not the time. Bug: https://bugs.openjdk.java.net/browse/JDK-8072834 Webrev: http://cr.openjdk.java.net/~erikj/8072834/webrev.jdk.01/ /Erik
Re: RFR: JDK-8062223: Upgrading to ccache 1.3.10 disables the use of ccache
On 2015-02-05 15:31, Erik Joelsson wrote: On 2015-01-30 12:01, Magnus Ihse Bursie wrote: On 2015-01-30 11:51, Erik Joelsson wrote: Hello, New webrev: http://cr.openjdk.java.net/~erikj/8062223/webrev.root.02/ Fixed the anti pattern. Sort of. :-) You still ignore the flag silently if it is not supported. I would prefer if a AC_MSG_WARN or AC_MSG_NOTICE in that case. If the user has explicitely given an argument, I think they deserves to know that is was to no effect. But then again, that's no regression so I accept if you will not fix it now. You are right, I think I got it right this time: http://cr.openjdk.java.net/~erikj/8062223/webrev.root.03/ Thank you! :-) Looks good. /Magnus
Re: Build error with javac Main not being found when building java.transaction module on Mac OS X
That sounds a bit weird. get_source should do a pull and update on the
top-level repo as well, so a separate hg update should not be needed.
Did you have local changes requiring a merge?
/Magnus
> 9 feb 2015 kl. 12:46 skrev Martijn Verburg :
>
> @Erik and everyone else,
>
> , my sincere apologies and thank you for your
> patience! Indeed the modules.xml file was out of date. My script which
> executes 'hg update' each morning had been silently failing for some time.
> This is a good lesson for the build guide though, I'll add a note to remind
> people that once they clone the top level repository that they should also
> hg update as well as ./get_source.sh.
>
> I now have separate build errors (of course!), these ones seem a little
> more genuine, around the compilation / linking of desktop code with Mac
> native libs. There are too many to list, but here's an example of one below
>
> ===
>
> Creating libjsound.dylib from 17 file(s)
> In file included from /usr/include/dispatch/dispatch.h:51:0,
> from
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFStream.h:15,
> from
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CFPropertyList.h:13,
> from
> /System/Library/Frameworks/CoreFoundation.framework/Headers/CoreFoundation.h:55,
> from
> /System/Library/Frameworks/Foundation.framework/Headers/Foundation.h:6,
> from
> /System/Library/Frameworks/Cocoa.framework/Headers/Cocoa.h:12,
> from
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.desktop/macosx/native/libosxapp/AWT_debug.h:29,
> from
> /Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.desktop/macosx/native/libosxapp/AWT_debug.m:26:
> /usr/include/dispatch/object.h:143:15: error: expected identifier or '('
> before '^' token
> typedef void (^dispatch_block_t)(void);
> ^
> /usr/include/dispatch/object.h:362:3: error: unknown type name
> 'dispatch_block_t'
> dispatch_block_t notification_block);
> ^
>
> Is this perhaps me using an unsupported compiler? My C/C++ toolchain is:
>
> ...
> * Toolchain: clang (clang/LLVM)
> * C Compiler: Version Apple LLVM version 6.0 (clang-600.0.56) (based on
> LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
> /usr/bin/clang)
> * C++ Compiler: Version Apple LLVM version 6.0 (clang-600.0.56) (based on
> LLVM 3.5svn) Target: x86_64-apple-darwin14.1.0 Thread model: posix (at
> /usr/bin/clang++)
> ...
>
>
>
> Cheers,
> Martijn
>
>> On 9 February 2015 at 10:35, Erik Joelsson wrote:
>>
>> Then please check that your top level repo is properly up to date. It
>> should contain:
>>
>>
>>java.transaction
>>java.base
>>java.rmi
>>
>> javax.transaction
>>
>>
>>
>> /Erik
>>
>>
>> On 2015-02-09 11:32, Martijn Verburg wrote:
>>
>> Hi Erik,
>>
>> You're correct, the module-deps.gmk file does not have java.transaction
>> in there.
>>
>> modules.xml does contain it as an export for java.corba (which depends
>> on java.base), i.e.
>>
>>
>>java.corba
>>java.base
>>java.desktop
>>java.logging
>>java.naming
>>java.rmi
>> ...
>>
>> javax.transaction
>>
>> ...
>>
>> I'm also going to try Magnus's suggestion.
>>
>> Cheers,
>> Martijn
>>
>> On 9 February 2015 at 09:32, Erik Joelsson
>> wrote:
>>
>>> So you have the source files for java.transaction in your jdk repo. Does
>>> your modules.xml list that module? At the start of the build, we generate
>>> build//make-support/module-deps.gmk from modules.xml from which
>>> we construct the correct make dependencies between module targets. I'm
>>> guessing java.transaction is not showing up in your module-deps.gmk.
>>>
>>> If java.transaction doesn't show up in modules-deps.gmk, we are missing
>>> that java.transaction-java depends on java.base-java, so make will start
>>> running java.transaction-java earlier than it should.
>>>
>>> /Erik
>>>
>>>
On 2015-02-06 16:45, Martijn Verburg wrote:
Hi Erik/Alan,
Not sure if this information is useful at all but the following tmp file
was left behind:
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/build/macosx-
x86_64-normal-server-release/jdk/modules/java.transaction/_
the.java.transaction_batch.tmp
It contains:
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/InvalidTransactionException.java
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/TransactionRequiredException.java
/Users/karianna/Documents/workspace/AdoptOpenJDK_projects/jdk9/jdk/src/java.transaction/share/classes/javax/transaction/TransactionRolledbackException.java
Ch
