From fredrik.ohrstrom at oracle.com Tue Nov 1 08:37:33 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 01 Nov 2011 15:37:33 +0000 Subject: hg: build-infra/jdk7/hotspot: Removed OS test. This should really be done in the configure script. Message-ID: <20111101153739.2C33A471EE@hg.openjdk.java.net> Changeset: 2348f320a522 Author: ohrstrom Date: 2011-11-01 16:26 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/hotspot/rev/2348f320a522 Removed OS test. This should really be done in the configure script. ! make/linux/Makefile From fredrik.ohrstrom at oracle.com Tue Nov 1 15:29:00 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 01 Nov 2011 22:29:00 +0000 Subject: hg: build-infra/jdk7: Added support for putting the libraries at the end of the ld. Message-ID: <20111101222900.4BDD5471F5@hg.openjdk.java.net> Changeset: 6e65b5becc20 Author: ohrstrom Date: 2011-11-01 23:22 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/6e65b5becc20 Added support for putting the libraries at the end of the ld. ! common/config/spec.gmk.in ! common/make/NativeCompilation.gmk ! configure ! configure.ac From fredrik.ohrstrom at oracle.com Tue Nov 1 15:29:21 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 01 Nov 2011 22:29:21 +0000 Subject: hg: build-infra/jdk7/jdk: Support adding the linked to libraries at the end of the command line to satisfy picky linkers. Message-ID: <20111101222948.A98CC471F6@hg.openjdk.java.net> Changeset: 2531dbb7c535 Author: ohrstrom Date: 2011-11-01 23:25 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/2531dbb7c535 Support adding the linked to libraries at the end of the command line to satisfy picky linkers. ! make/CompileLaunchers.gmk ! make/CompileNativeLibraries.gmk From erik.joelsson at oracle.com Wed Nov 2 05:27:05 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 02 Nov 2011 12:27:05 +0000 Subject: hg: build-infra/jdk7: 4 new changesets Message-ID: <20111102122705.BEE7B471FC@hg.openjdk.java.net> Changeset: 27aa555a677f Author: erikj Date: 2011-11-01 11:24 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/27aa555a677f Adding CXXFLAGS, LDCXX, LDEXECXX variables to support C++ compilation in the JDK. ! common/config/spec.gmk.in ! common/make/NativeCompilation.gmk ! configure ! configure.ac Changeset: 024b9dc292c9 Author: erikj Date: 2011-11-01 11:26 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/024b9dc292c9 merge ! configure ! configure.ac Changeset: 3ff329cb98e2 Author: erikj Date: 2011-11-02 12:53 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/3ff329cb98e2 Added support for running rc.exe on libraries and executables on windows. ! common/config/spec.gmk.in ! common/make/NativeCompilation.gmk ! configure ! configure.ac ! version.numbers Changeset: ad35e3c970f7 Author: erikj Date: 2011-11-02 13:25 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/ad35e3c970f7 merge ! common/config/spec.gmk.in ! common/make/NativeCompilation.gmk ! configure ! configure.ac From erik.joelsson at oracle.com Wed Nov 2 05:27:56 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 02 Nov 2011 12:27:56 +0000 Subject: hg: build-infra/jdk7/jdk: 4 new changesets Message-ID: <20111102122846.3440B471FD@hg.openjdk.java.net> Changeset: ecec5e815ca9 Author: erikj Date: 2011-11-01 11:25 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/ecec5e815ca9 Converted com/sun/java/pack. Works on linux, need to fix windows before pushing this. ! make/CompileLaunchers.gmk ! make/CompileNativeLibraries.gmk ! make/CopyIntoClasses.gmk ! make/GensrcProperties.gmk ! make/com/sun/java/pack/Makefile - make/com/sun/java/pack/prop/Makefile Changeset: bd3108c27d9a Author: erikj Date: 2011-11-02 12:54 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/bd3108c27d9a Added running of rc.exe on unpack.dll and unpack200.exe. Added manifest to unpack200.exe. Deactivated old build of pack. ! make/CompileLaunchers.gmk ! make/CompileNativeLibraries.gmk ! make/com/sun/Makefile Changeset: c3dc111d359f Author: erikj Date: 2011-11-02 12:55 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/c3dc111d359f Removed no longer used makefiles for 'pack'. - make/com/sun/java/Makefile - make/com/sun/java/pack/FILES_cpp.gmk - make/com/sun/java/pack/Makefile Changeset: 726cc1f46434 Author: erikj Date: 2011-11-02 13:25 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/726cc1f46434 merge ! make/CompileLaunchers.gmk ! make/CompileNativeLibraries.gmk From fredrik.ohrstrom at oracle.com Thu Nov 3 04:27:25 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 03 Nov 2011 11:27:25 +0000 Subject: hg: build-infra/jdk7: Fixes in dependency tracking. Message-ID: <20111103112725.E134E4721A@hg.openjdk.java.net> Changeset: 3a1bc9379941 Author: ohrstrom Date: 2011-11-03 12:26 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/3a1bc9379941 Fixes in dependency tracking. ! common/make/JavaCompilation.gmk ! common/make/NativeCompilation.gmk From erik.joelsson at oracle.com Thu Nov 3 09:57:54 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 03 Nov 2011 16:57:54 +0000 Subject: hg: build-infra/jdk7: 2 new changesets Message-ID: <20111103165754.6D8D24721D@hg.openjdk.java.net> Changeset: 4baa95daf804 Author: erikj Date: 2011-11-03 17:48 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/4baa95daf804 Only try to run JAVAH if SetupCompiler was setup for it. More restrictive matching in nativeapi-files to not get bogus lines which happen to contain the text "TYPE". ! common/make/JavaCompilation.gmk Changeset: 4f54172255b1 Author: erikj Date: 2011-11-03 17:57 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/4f54172255b1 merge ! common/make/JavaCompilation.gmk From erik.joelsson at oracle.com Thu Nov 3 09:58:43 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 03 Nov 2011 16:58:43 +0000 Subject: hg: build-infra/jdk7/jdk: Converted sctp. Required javah to be run on a class without native Message-ID: <20111103165903.93FFB4721E@hg.openjdk.java.net> Changeset: 3aaaaaf77a6e Author: erikj Date: 2011-11-03 17:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/3aaaaaf77a6e Converted sctp. Required javah to be run on a class without native methods. ! make/CompileNativeLibraries.gmk ! make/com/sun/Makefile - make/com/sun/nio/Makefile - make/com/sun/nio/sctp/Makefile From erik.joelsson at oracle.com Thu Nov 3 09:59:14 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 03 Nov 2011 16:59:14 +0000 Subject: hg: build-infra/jdk7/langtools: Added more info to pub api and native api files. Modifiers to methods, Message-ID: <20111103165916.971744721F@hg.openjdk.java.net> Changeset: e1493aa6e122 Author: erikj Date: 2011-11-03 17:50 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/e1493aa6e122 Added more info to pub api and native api files. Modifiers to methods, perhaps all are not needed, but several are. Added static final fields to native api as these are included in header files. We will need to find a way to filter this in make later. ! src/share/classes/com/sun/tools/javac/processing/ApiVisitor.java ! src/share/classes/com/sun/tools/javac/processing/NativeapiVisitor.java ! src/share/classes/com/sun/tools/javac/processing/PubapiVisitor.java From jonathan.gibbons at oracle.com Thu Nov 3 10:34:46 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 03 Nov 2011 10:34:46 -0700 Subject: javac changes Message-ID: <4EB2D0B6.30005@oracle.com> Fredrik and team, For the changes you are proposing to make to javac, how much can the work be broken into a series of standalone changesets, that can be reviewed and integrated separately? -- Jon From weijun.wang at oracle.com Thu Nov 3 20:35:39 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 04 Nov 2011 11:35:39 +0800 Subject: Improved build system In-Reply-To: <13e0743d-b7d4-4998-9ec7-bb3edcc57561@default> References: <13e0743d-b7d4-4998-9ec7-bb3edcc57561@default> Message-ID: <4EB35D8B.1080007@oracle.com> I just tried this on my Ubuntu 11.04 64-bit system: 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 2. get_source.sh 3. Download ccache 3.1.6 source and build it 4. Download the 3 files in common/config and mv one of them 5. ./configure --with-boot-jdk=$J6 6. make and soon see an error Compiling 10 files in package com/sun/source/util /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: error: duplicate class: com.sun.mirror.util.TypeVisitor public interface TypeVisitor { ^ -Max On 09/30/2011 08:33 AM, Fredrik ?hrstr?m wrote: > I pushed the current state of the improved build system > for the OpenJDK. > > It currently only builds successfully on 64bit GNU/Linux. > > The first thing you should do after you fetched the update. > > cd common/config > wget http://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.guess > wget http://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.sub > wget http://www.opensource.apple.com/source/libdispatch/libdispatch-187.5/m4/pkg.m4?txt > mv pkg.m4?txt pkg.m4 > > The paperwork has not yet cleared on these files, but as soon as it does, I will > commit them to the repository. > > Now run: > ./configure > > This will setup the build. If you are missing something it complains > and tries to give a helpful hint on what rpm/deb package to install. > > (For developers within Oracle, you can do: > wget ftp://buildtools.se.oracle.com/buildtools/openjdk/builddeps.conf > ./configure --with-builddeps-server=ftp://buildtools.se.oracle.com/buildtools/openjdk --with-builddeps-dir=/localhome/builddeps > you can change /localhome/builddeps to your own preference. > ) > > You can also run: > ./configure --help > to see the options if you need to set the paths exactly. > > If configure succeed, type make, or perhaps rather: > make 2>&1 | ./common/bin/hide_important_warnings_from_javac.sh > > The jdk sources are unfortunately stained with deprecated and > unchecked warnings. Previously these warnings were hidden > in the voluminous output from the build process. But now > the stand out, as they should. But since we are working on > the build process, using the above filter, we can hide them. > > If that succeed you can run openjdk like this: > ./build/linux-amd64-server-release/jdk/bin/java -version > > You can now do "make images" this will create the jdk/jre > images in ./build/linux-amd64-server-release/images > > And you can do "make install" which will try to install > into your prefix of choice, typically /usr/local/jvm/openjdk-1.7.0-internal > and create links from /usr/local/bin > > Now, assuming that your machine has a lot of RAM and a lot of CPUs, > the build will move be reasonably fast. So what has happened. > > The new build system offers: > 1) fast dependency tracking from class/obj to source > a re-make after the first successful make does nothing, > and it takes a short time for make to figure this out. > It does not need to start a jvm. Pure makefiles deal with > both C-code and Java-code. > > 2) incremental build, when you change a java source file. > Only the necessary package is recompiled > and the resulting jar is incrementally updated with new,changed > or deleted classes. > > 3) working dependency propagation from java source to > java class to jar to javah-headers to c-library. > E.g. if you add a new native method > in java/util/zip/CRC32.java and type make. > It will recompile the class files in the package. > Regenerate the javah-headers and recompile CRC32.c > then relink libzip.so. > > 4) working dependency propagation between java packages. > If you add a public void foo() method to > com/sun/naming/internal/ResourceManager.java and remake. > It will detect that the public api of that package had changed > and also recompile: javax/naming/ldap since the latter package > imports features from the first package. This dependency tracking > is currently grouped on packages, lest the meta data would be too large. > > Yes, it is true. Add public void foo() to Object.java, and watch > it recompile the whole jdk. Well, at least the jdk repository, it cant > do anything about the already compiled repos lt,corba,jaxp,jaxws and hotspot. > > 5) It uses all available cores by default, if you have enough RAM. > It uses a background javac server to avoid throwing away optimizations > made by the JVM running the javac server. > > I have not changed the hotspot makefiles. Only the minimum necessary to make > use of ccache and allow configure to the the compiler properly. > > The long pause when the hotspot makefiles tries to figure out that there is > nothing to be done, is a good reminder that the hotspot makefiles need to be > cleaned up as well. :-) > > To support these features, javac had to be improved. I added the options: > -XDserver.. spawns a background javac server, or reuses the existing one > -XDdeps.. generate a file with package dependencies (like -MF in gcc) > -XDpubapi... generate a file with the public api of the package > -XDnativeapi.. generate a file with the native api of the package > > Since javac is inherently serial, the multi core problem was solved > by creating (inside the javac server) one JavaCompiler for each core. > When a request for compilation reach the javac server, it is distributed > randomly to any of the JavaCompilers. By making sure that the > JavaCompiler is reusable between client calls and any compiled classes > are available to the next client call. As we continue to improve the > sharing of data between JavaCompilers in the javac server, ie essentially > making javac more and more parallell, we can reduce the number of time > a class is compiled (now some classes get compiled as many > times as you have cores). > > If we look at the bad boy, of the repositories, the corba repo. > It had 144 makefiles, now it has one (1). > It took 2 minutes and 20 seconds to compile on my workstation, > now it takes 15 seconds. > > This improvement was of course possible since its makefiles were > not good at all. For langtools,jaxp and jaxws, the new makefiles are > faster than the ant makefiles, but not that much. This is of course > due to the fact that the javac server still does not share much > of the data between the JavaCompilers. Thus we should be moving > towards getting almost linear speedup from the cores, since we > have soo many packages that can be distributed on the different cores. > > In the jdk, we have not yet had time to convert all the makefiles. > But several makefiles have been removed already. > > As you can see in the jdk/make/Makefile, there is a call to the legacy > makefile system. Thus there are still many calls to javac, the legacy way. > And then this is followed by a compile of all the classes again, using > the new system. Thus there is a lot of speedups left to do. > > Unfortunately almost every jdk makefile has some quirk in it. > It is sometimes platform specific code that is part of src/share/classes. > It is sometimes generated code that should be ignored. > It sometimes compile classes in the jdk using -target 6 to be run but > not be part of the final jdk. etc etc. > > So to convert a jdk makefile, you need to figure out what java files > does it create and move java source creation to GenerateJavaSources.gmk > and into a suitable Gensrc....gmk file, then the actual classes are > compiled already in CompileJavaClasses.gmk. If the makefile also generates > a c-library you have to update CompileNativeLibraries.gmk. > > (Notice, how I cleverly changed the pronoun from I/we to you in > the previous paragraph? :-) ) > > On windows, you need to install cygwin and Visual Studio 10. > ./configure will actively go looking for VS10 and setup the compiler > correctly for the build. Yay! Then, the build probably does not work > right now, for other reasons, most likely you have to increase > the timeout in JavacServer.java to wait longer before it shuts down. > This is probably necessary when building on slower computers. We will > have to figure out a better way to decide when to shutdown the javac server. > But we have successfully compiled langtools/corba/jaxp/jaxws and hotspot on windows. > > For solaris, there should be no significant hurdles either, just a lot of > quirks to deal with. Again langtools/corba/jaxp/jaxws and hotspot have > been compiled on Solaris. > > The ./configure runs on MacOSX with xcode installed. But fails quite early. > Well, no wonder, since neither the bsd-port nor the MacOSX native port is > part of build-infra, yet. > > I am very grateful for the enormous work made by the icedtea team! > Your configure script was very helpful! I tried to name options in the > same way as you did. > > Thanks to Erik,Kelly,Magnus,Maurizio and Robert for their extremely valuable > work and support! > > Many bugs fixed, many more bugs left to fix! > > //Fredrik From erik.joelsson at oracle.com Fri Nov 4 07:06:07 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 04 Nov 2011 14:06:07 +0000 Subject: hg: build-infra/jdk7: Guarding RC_FLAGS with ifndef to prevent it from overwriting additions to it in legacy makefiles (where spec is loaded multiple times). Message-ID: <20111104140608.032DE47240@hg.openjdk.java.net> Changeset: 7059bcf6b027 Author: erikj Date: 2011-11-04 15:01 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/7059bcf6b027 Guarding RC_FLAGS with ifndef to prevent it from overwriting additions to it in legacy makefiles (where spec is loaded multiple times). ! common/config/spec.gmk.in From erik.joelsson at oracle.com Fri Nov 4 07:06:56 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 04 Nov 2011 14:06:56 +0000 Subject: hg: build-infra/jdk7/jdk: Commented out RC_FLAGS from Defs-windows.gmk since it is now handled by configure. Message-ID: <20111104140719.79AEA47241@hg.openjdk.java.net> Changeset: 410a490a9cc0 Author: erikj Date: 2011-11-04 15:00 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/410a490a9cc0 Commented out RC_FLAGS from Defs-windows.gmk since it is now handled by configure. ! make/common/Defs-windows.gmk From fredrik.ohrstrom at oracle.com Fri Nov 4 07:26:23 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 4 Nov 2011 07:26:23 -0700 (PDT) Subject: Improved build system Message-ID: <5d4de232-fa30-4f94-897e-fcd0123f28c0@default> Ok, could you please try just: ./configure and use the default iced-tea? //Fredrik ----- weijun.wang at oracle.com skrev: > On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: > > > > Please send me the build.log file.... > > Attached. > > > > > You can also try: > > > > ./configure --with-boot-jdk=$J6 --disable-javac-multi-core > --disable-javac-deps --disable-javac-server > > This works. > > -Max > > > > > ----- weijun.wang at oracle.com skrev: > > > >> I just tried this on my Ubuntu 11.04 64-bit system: > >> > >> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 > >> 2. get_source.sh > >> 3. Download ccache 3.1.6 source and build it > >> 4. Download the 3 files in common/config and mv one of them > >> 5. ./configure --with-boot-jdk=$J6 > >> 6. make > >> > >> and soon see an error > >> > >> Compiling 10 files in package com/sun/source/util > >> > /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: > >> > >> error: duplicate class: com.sun.mirror.util.TypeVisitor > >> public interface TypeVisitor { > >> ^ > >> > >> -Max From weijun.wang at oracle.com Fri Nov 4 08:03:16 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 4 Nov 2011 23:03:16 +0800 Subject: Improved build system In-Reply-To: <5d4de232-fa30-4f94-897e-fcd0123f28c0@default> References: <5d4de232-fa30-4f94-897e-fcd0123f28c0@default> Message-ID: <61C48A83-B8F2-4EB0-8F70-A19C8CDC6D84@oracle.com> I don't have an IcedTea. Do I need to build one? -Max On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m wrote: > > Ok, could you please try just: > > ./configure > > and use the default iced-tea? > > //Fredrik > > ----- weijun.wang at oracle.com skrev: > >> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>> >>> Please send me the build.log file.... >> >> Attached. >> >>> >>> You can also try: >>> >>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >> --disable-javac-deps --disable-javac-server >> >> This works. >> >> -Max >> >>> >>> ----- weijun.wang at oracle.com skrev: >>> >>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>> >>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>> 2. get_source.sh >>>> 3. Download ccache 3.1.6 source and build it >>>> 4. Download the 3 files in common/config and mv one of them >>>> 5. ./configure --with-boot-jdk=$J6 >>>> 6. make >>>> >>>> and soon see an error >>>> >>>> Compiling 10 files in package com/sun/source/util >>>> >> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>> >>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>> public interface TypeVisitor { >>>> ^ >>>> >>>> -Max From fredrik.ohrstrom at oracle.com Fri Nov 4 08:40:25 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 4 Nov 2011 08:40:25 -0700 (PDT) Subject: Improved build system Message-ID: It is the default Ubuntu Java package. Just install the openjdk package and you will get iced tea. The configure script should remind you what the package name is, if you make sure that you have no java in the path. By the way. You do not have your source and build directory on NFS do you? The javacserver uses file system locking to establish a single server. And locking does not work very well over nfs. (Also building is much slower, if it works.) //Fredrik ----- weijun.wang at oracle.com skrev: > I don't have an IcedTea. Do I need to build one? > > -Max > > > > On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m > wrote: > > > > > Ok, could you please try just: > > > > ./configure > > > > and use the default iced-tea? > > > > //Fredrik > > > > ----- weijun.wang at oracle.com skrev: > > > >> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: > >>> > >>> Please send me the build.log file.... > >> > >> Attached. > >> > >>> > >>> You can also try: > >>> > >>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core > >> --disable-javac-deps --disable-javac-server > >> > >> This works. > >> > >> -Max > >> > >>> > >>> ----- weijun.wang at oracle.com skrev: > >>> > >>>> I just tried this on my Ubuntu 11.04 64-bit system: > >>>> > >>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 > >>>> 2. get_source.sh > >>>> 3. Download ccache 3.1.6 source and build it > >>>> 4. Download the 3 files in common/config and mv one of them > >>>> 5. ./configure --with-boot-jdk=$J6 > >>>> 6. make > >>>> > >>>> and soon see an error > >>>> > >>>> Compiling 10 files in package com/sun/source/util > >>>> > >> > /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: > >>>> > >>>> error: duplicate class: com.sun.mirror.util.TypeVisitor > >>>> public interface TypeVisitor { > >>>> ^ > >>>> > >>>> -Max From jonathan.gibbons at oracle.com Fri Nov 4 08:50:10 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 Nov 2011 08:50:10 -0700 Subject: Improved build system In-Reply-To: References: Message-ID: <4EB409B2.8060005@oracle.com> Does the build, can the build, check for NFS, and report an error? -- Jon On 11/04/2011 08:40 AM, Fredrik ?hrstr?m wrote: > It is the default Ubuntu Java package. > > Just install the openjdk package and you will get iced tea. > The configure script should remind you what the package name is, > if you make sure that you have no java in the path. > > By the way. You do not have your source and build directory > on NFS do you? The javacserver uses file system locking > to establish a single server. And locking does not work > very well over nfs. (Also building is much slower, if it works.) > > //Fredrik > ----- weijun.wang at oracle.com skrev: > >> I don't have an IcedTea. Do I need to build one? >> >> -Max >> >> >> >> On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m >> wrote: >> >>> Ok, could you please try just: >>> >>> ./configure >>> >>> and use the default iced-tea? >>> >>> //Fredrik >>> >>> ----- weijun.wang at oracle.com skrev: >>> >>>> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>>>> Please send me the build.log file.... >>>> Attached. >>>> >>>>> You can also try: >>>>> >>>>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >>>> --disable-javac-deps --disable-javac-server >>>> >>>> This works. >>>> >>>> -Max >>>> >>>>> ----- weijun.wang at oracle.com skrev: >>>>> >>>>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>>>> >>>>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>>>> 2. get_source.sh >>>>>> 3. Download ccache 3.1.6 source and build it >>>>>> 4. Download the 3 files in common/config and mv one of them >>>>>> 5. ./configure --with-boot-jdk=$J6 >>>>>> 6. make >>>>>> >>>>>> and soon see an error >>>>>> >>>>>> Compiling 10 files in package com/sun/source/util >>>>>> >> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>>>> public interface TypeVisitor { >>>>>> ^ >>>>>> >>>>>> -Max From philip.race at oracle.com Fri Nov 4 10:54:25 2011 From: philip.race at oracle.com (Phil Race) Date: Fri, 04 Nov 2011 10:54:25 -0700 Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. In-Reply-To: <973c966f-8550-41fb-ae9d-e32f6627eb92@default> References: <973c966f-8550-41fb-ae9d-e32f6627eb92@default> Message-ID: <4EB426D1.90808@oracle.com> It no workee for me. here's a log of what happens when I run configure from the top-level JDk 7 freshly pulled this morning from http://hg.openjdk.java.net/build-infra/jdk7 sh-4.1$ ./configure checking for gawk... gawk checking for cat... /usr/bin/cat checking for chmod... /usr/bin/chmod checking for cp... /usr/bin/cp checking for cpio... /usr/bin/cpio checking for cut... /usr/bin/cut checking for date... /usr/bin/date checking for df... /usr/bin/df checking for diff... /usr/bin/diff checking for echo... /usr/bin/echo checking for grep that handles long lines and -e... /usr/bin/grep checking for egrep... /usr/bin/grep -E checking for fgrep... /usr/bin/grep -F checking for find... /usr/bin/find checking if find supports -delete... yes checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for head... /usr/bin/head checking for ln... /usr/bin/ln checking for ls... /usr/bin/ls checking for gmake... no checking for make... /usr/bin/make checking for mkdir... /usr/bin/mkdir checking for mv... /usr/bin/mv checking for nawk... no checking for gawk... /usr/bin/gawk checking for printf... /usr/bin/printf checking for pwd... /usr/bin/pwd checking for rm... /usr/bin/rm checking for a sed that does not truncate output... /usr/bin/sed checking for sh... /usr/bin/sh checking for sort... /usr/bin/sort checking for tar... /usr/bin/tar checking for tail... /usr/bin/tail checking for tee... /usr/bin/tee checking for tr... /usr/bin/tr checking for touch... /usr/bin/touch checking for wc... /usr/bin/wc checking for xargs... /usr/bin/xargs checking for zip... /usr/bin/zip checking for unzip... /usr/bin/unzip checking for ldd... /usr/bin/ldd checking for readelf... /usr/bin/readelf configure: error: cannot run /bin/sh common/config/config.sub sh-4.1$ ls common/config/config.sub ls: cannot access common/config/config.sub: No such file or directory -phil. On 10/26/2011 9:28 AM, Fredrik ?hrstr?m wrote: > It builds on WindowsXP, using Visual Studio 2010 Express (free edition). > > 1) Install Visual Studio. > > 2) Install cygwin + devel + zip and any other thing the configure script might complain about.' > > 3) Install freetype from http://gnuwin32.sourceforge.net/packages/freetype.htm and copy libfreetype.dll.a into the more useful name freetype.dll > It usually installs in: /cygdrive/c/Program\ Files/GnuWin32 > > 4) From the cygwin shell > ./configure --with-jvm-variant=server --disable-javac-multi-core --disable-javac-deps --disable-javac-server --with-freetype=/cygdrive/c/Program\ Files/GnuWin32 > > 5) make > > 6) ./build/windows-i586-server-release/jdk/bin/javac Test.java > ./build/windows-i586-server-release/jdk/bin/java Test > Success! > > Anyone cares to test? > > However jconsole does not work. As probably any other graphical program. I know some parts that are still missing. :-) Will fix that. > > If you forget to do the disables above, then the build will be much much slower because of a bug that forces a 2 minute timeout after each repository. To be fixed. > > //Fredrik From fredrik.ohrstrom at oracle.com Fri Nov 4 11:14:12 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 4 Nov 2011 11:14:12 -0700 (PDT) Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. Message-ID: <4b40af6f-7561-4cdc-976e-246e51795965@default> You need to download three files that will soon be added to the repository when the legal paperwork clears. Read here. http://mail.openjdk.java.net/pipermail/build-infra-dev/2011-September/000065.html //Fredrik ----- philip.race at oracle.com skrev: > It no workee for me. > > here's a log of what happens when I run configure > from the top-level JDk 7 freshly pulled this morning from > http://hg.openjdk.java.net/build-infra/jdk7 > > > sh-4.1$ ./configure > checking for gawk... gawk > checking for cat... /usr/bin/cat > checking for chmod... /usr/bin/chmod > checking for cp... /usr/bin/cp > checking for cpio... /usr/bin/cpio > checking for cut... /usr/bin/cut > checking for date... /usr/bin/date > checking for df... /usr/bin/df > checking for diff... /usr/bin/diff > checking for echo... /usr/bin/echo > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for fgrep... /usr/bin/grep -F > checking for find... /usr/bin/find > checking if find supports -delete... yes > checking for grep that handles long lines and -e... (cached) > /usr/bin/grep > checking for head... /usr/bin/head > checking for ln... /usr/bin/ln > checking for ls... /usr/bin/ls > checking for gmake... no > checking for make... /usr/bin/make > checking for mkdir... /usr/bin/mkdir > checking for mv... /usr/bin/mv > checking for nawk... no > checking for gawk... /usr/bin/gawk > checking for printf... /usr/bin/printf > checking for pwd... /usr/bin/pwd > checking for rm... /usr/bin/rm > checking for a sed that does not truncate output... /usr/bin/sed > checking for sh... /usr/bin/sh > checking for sort... /usr/bin/sort > checking for tar... /usr/bin/tar > checking for tail... /usr/bin/tail > checking for tee... /usr/bin/tee > checking for tr... /usr/bin/tr > checking for touch... /usr/bin/touch > checking for wc... /usr/bin/wc > checking for xargs... /usr/bin/xargs > checking for zip... /usr/bin/zip > checking for unzip... /usr/bin/unzip > checking for ldd... /usr/bin/ldd > checking for readelf... /usr/bin/readelf > configure: error: cannot run /bin/sh common/config/config.sub > sh-4.1$ ls common/config/config.sub > ls: cannot access common/config/config.sub: No such file or directory > > -phil. > > On 10/26/2011 9:28 AM, Fredrik ?hrstr?m wrote: > > It builds on WindowsXP, using Visual Studio 2010 Express (free > edition). > > > > 1) Install Visual Studio. > > > > 2) Install cygwin + devel + zip and any other thing the configure > script might complain about.' > > > > 3) Install freetype from > http://gnuwin32.sourceforge.net/packages/freetype.htm and copy > libfreetype.dll.a into the more useful name freetype.dll > > It usually installs in: /cygdrive/c/Program\ Files/GnuWin32 > > > > 4) From the cygwin shell > > ./configure --with-jvm-variant=server --disable-javac-multi-core > --disable-javac-deps --disable-javac-server > --with-freetype=/cygdrive/c/Program\ Files/GnuWin32 > > > > 5) make > > > > 6) ./build/windows-i586-server-release/jdk/bin/javac Test.java > > ./build/windows-i586-server-release/jdk/bin/java Test > > Success! > > > > Anyone cares to test? > > > > However jconsole does not work. As probably any other graphical > program. I know some parts that are still missing. :-) Will fix that. > > > > If you forget to do the disables above, then the build will be much > much slower because of a bug that forces a 2 minute timeout after each > repository. To be fixed. > > > > //Fredrik From fredrik.ohrstrom at oracle.com Fri Nov 4 11:18:58 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 4 Nov 2011 11:18:58 -0700 (PDT) Subject: Improved build system Message-ID: > Does the build, can the build, check for NFS, and report an error? > > Jon You are right, if it is relevant to check for NFS, then it is a test that really should be done in configure. But we have to wait for Weijun's answer to see if nfs is involved or not. //Fredrik ----- fredrik.ohrstrom at oracle.com skrev: > It is the default Ubuntu Java package. > > Just install the openjdk package and you will get iced tea. > The configure script should remind you what the package name is, > if you make sure that you have no java in the path. > > By the way. You do not have your source and build directory > on NFS do you? The javacserver uses file system locking > to establish a single server. And locking does not work > very well over nfs. (Also building is much slower, if it works.) > > //Fredrik > ----- weijun.wang at oracle.com skrev: > > > I don't have an IcedTea. Do I need to build one? > > > > -Max > > > > > > > > On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m > > wrote: > > > > > > > > Ok, could you please try just: > > > > > > ./configure > > > > > > and use the default iced-tea? > > > > > > //Fredrik > > > > > > ----- weijun.wang at oracle.com skrev: > > > > > >> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: > > >>> > > >>> Please send me the build.log file.... > > >> > > >> Attached. > > >> > > >>> > > >>> You can also try: > > >>> > > >>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core > > >> --disable-javac-deps --disable-javac-server > > >> > > >> This works. > > >> > > >> -Max > > >> > > >>> > > >>> ----- weijun.wang at oracle.com skrev: > > >>> > > >>>> I just tried this on my Ubuntu 11.04 64-bit system: > > >>>> > > >>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 > > >>>> 2. get_source.sh > > >>>> 3. Download ccache 3.1.6 source and build it > > >>>> 4. Download the 3 files in common/config and mv one of them > > >>>> 5. ./configure --with-boot-jdk=$J6 > > >>>> 6. make > > >>>> > > >>>> and soon see an error > > >>>> > > >>>> Compiling 10 files in package com/sun/source/util > > >>>> > > >> > > > /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: > > >>>> > > >>>> error: duplicate class: com.sun.mirror.util.TypeVisitor > > >>>> public interface TypeVisitor { > > >>>> ^ > > >>>> > > >>>> -Max From jonathan.gibbons at oracle.com Fri Nov 4 11:43:00 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 Nov 2011 11:43:00 -0700 Subject: Improved build system In-Reply-To: References: Message-ID: <4EB43234.8090400@oracle.com> For Max's issue, I agree. But if NFS is generally discouraged, as you imply, then you should get at least a warning if you try and use it, independent of Max's response. -- Jon On 11/04/2011 11:18 AM, Fredrik ?hrstr?m wrote: >> Does the build, can the build, check for NFS, and report an error? >> >> Jon > > You are right, if it is relevant to check for NFS, then it is a test that really should be done in configure. > > But we have to wait for Weijun's answer to see if nfs is involved or not. > > //Fredrik > > ----- fredrik.ohrstrom at oracle.com skrev: > >> It is the default Ubuntu Java package. >> >> Just install the openjdk package and you will get iced tea. >> The configure script should remind you what the package name is, >> if you make sure that you have no java in the path. >> >> By the way. You do not have your source and build directory >> on NFS do you? The javacserver uses file system locking >> to establish a single server. And locking does not work >> very well over nfs. (Also building is much slower, if it works.) >> >> //Fredrik >> ----- weijun.wang at oracle.com skrev: >> >>> I don't have an IcedTea. Do I need to build one? >>> >>> -Max >>> >>> >>> >>> On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m >>> wrote: >>> >>>> Ok, could you please try just: >>>> >>>> ./configure >>>> >>>> and use the default iced-tea? >>>> >>>> //Fredrik >>>> >>>> ----- weijun.wang at oracle.com skrev: >>>> >>>>> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>>>>> Please send me the build.log file.... >>>>> Attached. >>>>> >>>>>> You can also try: >>>>>> >>>>>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >>>>> --disable-javac-deps --disable-javac-server >>>>> >>>>> This works. >>>>> >>>>> -Max >>>>> >>>>>> ----- weijun.wang at oracle.com skrev: >>>>>> >>>>>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>>>>> >>>>>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>>>>> 2. get_source.sh >>>>>>> 3. Download ccache 3.1.6 source and build it >>>>>>> 4. Download the 3 files in common/config and mv one of them >>>>>>> 5. ./configure --with-boot-jdk=$J6 >>>>>>> 6. make >>>>>>> >>>>>>> and soon see an error >>>>>>> >>>>>>> Compiling 10 files in package com/sun/source/util >>>>>>> >> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>>>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>>>>> public interface TypeVisitor { >>>>>>> ^ >>>>>>> >>>>>>> -Max From kelly.ohair at oracle.com Fri Nov 4 12:08:43 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Fri, 4 Nov 2011 12:08:43 -0700 Subject: Improved build system In-Reply-To: <4EB43234.8090400@oracle.com> References: <4EB43234.8090400@oracle.com> Message-ID: <26962FEA-7639-433B-9BBC-B7E7D018AA2A@oracle.com> You would be amazed at how many people still use NFS partitions to build in. :^( -kto On Nov 4, 2011, at 11:43 AM, Jonathan Gibbons wrote: > For Max's issue, I agree. But if NFS is generally discouraged, as you imply, then you should get at least a warning if you try and use it, independent of Max's response. > > -- Jon > > > > On 11/04/2011 11:18 AM, Fredrik ?hrstr?m wrote: >>> Does the build, can the build, check for NFS, and report an error? >>> >>> Jon >> >> You are right, if it is relevant to check for NFS, then it is a test that really should be done in configure. >> >> But we have to wait for Weijun's answer to see if nfs is involved or not. >> >> //Fredrik >> >> ----- fredrik.ohrstrom at oracle.com skrev: >> >>> It is the default Ubuntu Java package. >>> >>> Just install the openjdk package and you will get iced tea. >>> The configure script should remind you what the package name is, >>> if you make sure that you have no java in the path. >>> >>> By the way. You do not have your source and build directory >>> on NFS do you? The javacserver uses file system locking >>> to establish a single server. And locking does not work >>> very well over nfs. (Also building is much slower, if it works.) >>> >>> //Fredrik >>> ----- weijun.wang at oracle.com skrev: >>> >>>> I don't have an IcedTea. Do I need to build one? >>>> >>>> -Max >>>> >>>> >>>> >>>> On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m >>>> wrote: >>>> >>>>> Ok, could you please try just: >>>>> >>>>> ./configure >>>>> >>>>> and use the default iced-tea? >>>>> >>>>> //Fredrik >>>>> >>>>> ----- weijun.wang at oracle.com skrev: >>>>> >>>>>> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>>>>>> Please send me the build.log file.... >>>>>> Attached. >>>>>> >>>>>>> You can also try: >>>>>>> >>>>>>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >>>>>> --disable-javac-deps --disable-javac-server >>>>>> >>>>>> This works. >>>>>> >>>>>> -Max >>>>>> >>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>> >>>>>>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>>>>>> >>>>>>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>>>>>> 2. get_source.sh >>>>>>>> 3. Download ccache 3.1.6 source and build it >>>>>>>> 4. Download the 3 files in common/config and mv one of them >>>>>>>> 5. ./configure --with-boot-jdk=$J6 >>>>>>>> 6. make >>>>>>>> >>>>>>>> and soon see an error >>>>>>>> >>>>>>>> Compiling 10 files in package com/sun/source/util >>>>>>>> >>> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>>>>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>>>>>> public interface TypeVisitor { >>>>>>>> ^ >>>>>>>> >>>>>>>> -Max > From jonathan.gibbons at oracle.com Fri Nov 4 12:14:17 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 04 Nov 2011 12:14:17 -0700 Subject: Improved build system In-Reply-To: <26962FEA-7639-433B-9BBC-B7E7D018AA2A@oracle.com> References: <4EB43234.8090400@oracle.com> <26962FEA-7639-433B-9BBC-B7E7D018AA2A@oracle.com> Message-ID: <4EB43989.3030502@oracle.com> Perhaps that's because they don't get a nice friendly warning advising them to do otherwise. If nothing else, they should build locally and then rsync the results to the remote location. -- Jon On 11/04/2011 12:08 PM, Kelly O'Hair wrote: > You would be amazed at how many people still use NFS partitions to build in. :^( > > -kto > > On Nov 4, 2011, at 11:43 AM, Jonathan Gibbons wrote: > >> For Max's issue, I agree. But if NFS is generally discouraged, as you imply, then you should get at least a warning if you try and use it, independent of Max's response. >> >> -- Jon >> >> >> >> On 11/04/2011 11:18 AM, Fredrik ?hrstr?m wrote: >>>> Does the build, can the build, check for NFS, and report an error? >>>> >>>> Jon >>> You are right, if it is relevant to check for NFS, then it is a test that really should be done in configure. >>> >>> But we have to wait for Weijun's answer to see if nfs is involved or not. >>> >>> //Fredrik >>> >>> ----- fredrik.ohrstrom at oracle.com skrev: >>> >>>> It is the default Ubuntu Java package. >>>> >>>> Just install the openjdk package and you will get iced tea. >>>> The configure script should remind you what the package name is, >>>> if you make sure that you have no java in the path. >>>> >>>> By the way. You do not have your source and build directory >>>> on NFS do you? The javacserver uses file system locking >>>> to establish a single server. And locking does not work >>>> very well over nfs. (Also building is much slower, if it works.) >>>> >>>> //Fredrik >>>> ----- weijun.wang at oracle.com skrev: >>>> >>>>> I don't have an IcedTea. Do I need to build one? >>>>> >>>>> -Max >>>>> >>>>> >>>>> >>>>> On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m >>>>> wrote: >>>>> >>>>>> Ok, could you please try just: >>>>>> >>>>>> ./configure >>>>>> >>>>>> and use the default iced-tea? >>>>>> >>>>>> //Fredrik >>>>>> >>>>>> ----- weijun.wang at oracle.com skrev: >>>>>> >>>>>>> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>>>>>>> Please send me the build.log file.... >>>>>>> Attached. >>>>>>> >>>>>>>> You can also try: >>>>>>>> >>>>>>>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >>>>>>> --disable-javac-deps --disable-javac-server >>>>>>> >>>>>>> This works. >>>>>>> >>>>>>> -Max >>>>>>> >>>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>>> >>>>>>>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>>>>>>> >>>>>>>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>>>>>>> 2. get_source.sh >>>>>>>>> 3. Download ccache 3.1.6 source and build it >>>>>>>>> 4. Download the 3 files in common/config and mv one of them >>>>>>>>> 5. ./configure --with-boot-jdk=$J6 >>>>>>>>> 6. make >>>>>>>>> >>>>>>>>> and soon see an error >>>>>>>>> >>>>>>>>> Compiling 10 files in package com/sun/source/util >>>>>>>>> >>>> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>>>>>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>>>>>>> public interface TypeVisitor { >>>>>>>>> ^ >>>>>>>>> >>>>>>>>> -Max From philip.race at oracle.com Fri Nov 4 12:25:50 2011 From: philip.race at oracle.com (Phil Race) Date: Fri, 04 Nov 2011 12:25:50 -0700 Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. In-Reply-To: <4b40af6f-7561-4cdc-976e-246e51795965@default> References: <4b40af6f-7561-4cdc-976e-246e51795965@default> Message-ID: <4EB43C3E.70705@oracle.com> So a little further now. >configure: error: Tried to find a VS installation under "C:\Program Files (x86)" > but failed. Please run "c:\cygwin\bin\bash.exe -l" from a VS command prompt and > then run configure/make from there. Apparently because my VS2010 is not in the standard place I was required to go run c:\vs2010\VC\bin\vcvars32.bat, then start my shell OK .. but VS sets the variable VS100COMNTOOLS so all you had to do was look for this variable VS100COMNTOOLS=c:\vs2010\Common7\Tools\ This would be a regression from the current build system which checks for this variable. Anyway I got past that too, however I am stuck again :- ---- checking for host address size... 32 bits checking whether byte ordering is bigendian... yes configure: WARNING: The tested endian in the host (big) differs from the endian expected to be found in the host (little) checking for javac... no checking for java... /cygdrive/c/Windows/system32/java checking for java... (cached) /cygdrive/c/Windows/system32/java checking for cygpath... (cached) /usr/bin/cygpath configure: error: Cannot find the rt.jar or its equivalent! ---- I don't know how disconcerted to be by the warning but how do I fix the issue with rt.jar ? How does it look for rt.jar ? Actually why does it need rt.jar ? -phil. On 11/4/2011 11:14 AM, Fredrik ?hrstr?m wrote: > You need to download three files that will soon be added to the repository > when the legal paperwork clears. > > Read here. > > http://mail.openjdk.java.net/pipermail/build-infra-dev/2011-September/000065.html > > //Fredrik > > ----- philip.race at oracle.com skrev: From fredrik.ohrstrom at oracle.com Fri Nov 4 13:52:04 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 4 Nov 2011 13:52:04 -0700 (PDT) Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. Message-ID: <98d4f272-deb7-4194-a9bc-d6aa91ef9768@default> ----- philip.race at oracle.com skrev: > OK .. but VS sets the variable VS100COMNTOOLS so all you had to do > was look for this variable > VS100COMNTOOLS=c:\vs2010\Common7\Tools\ Excellent! I will improve the configure script to look for this! It currently only searches for vcvarsall.bat under "Program Files" > checking for java... /cygdrive/c/Windows/system32/java > checking for java... (cached) /cygdrive/c/Windows/system32/java > checking for cygpath... (cached) /usr/bin/cygpath > configure: error: Cannot find the rt.jar or its equivalent! So it seems like it can't find the jdk where the rt.jar is stored. Have you done a default install using the Oracle Java Installer? The Windows/system32/java installation is new to me. Where is the actual jdk stored? > How does it look for rt.jar ? Actually why does it need rt.jar ? When it thinks it has found the jdk it will look for rt.jar or classes.jar (macosx) in the directories below. The explicit path to rt.jar is necessary when compiling with -source 6 -target 6, which is done when building the build tools, that have to be run by the boot jdk. //Fredrik From stuart.marks at oracle.com Fri Nov 4 13:57:43 2011 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 04 Nov 2011 13:57:43 -0700 Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. In-Reply-To: <98d4f272-deb7-4194-a9bc-d6aa91ef9768@default> References: <98d4f272-deb7-4194-a9bc-d6aa91ef9768@default> Message-ID: <4EB451C7.7090904@oracle.com> Phil's build output had something else significant that seemed very strange to me: > checking for host address size... 32 bits > checking whether byte ordering is bigendian... yes > configure: WARNING: The tested endian in the host (big) differs from the endian > expected to be found in the host (little) Given that Phil is apparently building on a Win32 system on x86, how could something have determined that his system is big-endian? I just wanted to point this out. This might indicate that something else has gone wrong earlier in the configure process. s'marks On 11/4/11 1:52 PM, Fredrik ?hrstr?m wrote: > > ----- philip.race at oracle.com skrev: >> OK .. but VS sets the variable VS100COMNTOOLS so all you had to do >> was look for this variable >> VS100COMNTOOLS=c:\vs2010\Common7\Tools\ > > Excellent! I will improve the configure script to look for this! > It currently only searches for vcvarsall.bat under "Program Files" > >> checking for java... /cygdrive/c/Windows/system32/java >> checking for java... (cached) /cygdrive/c/Windows/system32/java >> checking for cygpath... (cached) /usr/bin/cygpath >> configure: error: Cannot find the rt.jar or its equivalent! > > So it seems like it can't find the jdk where the rt.jar is stored. > Have you done a default install using the Oracle Java Installer? The Windows/system32/java installation is new to me. Where is the actual jdk stored? > >> How does it look for rt.jar ? Actually why does it need rt.jar ? > > When it thinks it has found the jdk it will look for rt.jar or classes.jar (macosx) in the directories below. > > The explicit path to rt.jar is necessary when compiling with -source 6 -target 6, which is done when building the build tools, that have to be run by the boot jdk. > > //Fredrik From fredrik.ohrstrom at oracle.com Fri Nov 4 14:13:44 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 4 Nov 2011 14:13:44 -0700 (PDT) Subject: Sv: Re: As you might have seen in the last changset, build-infra now builds on 32bit windows. Message-ID: <952d8dce-6e2b-45e3-bb6d-08689762cdda@default> ----- stuart.marks at oracle.com skrev: > Phil's build output had something else significant that seemed very > strange to me: > > > checking for host address size... 32 bits > > checking whether byte ordering is bigendian... yes > > configure: WARNING: The tested endian in the host (big) differs from > the endian > > expected to be found in the host (little) > > Given that Phil is apparently building on a Win32 system on x86, how > could > something have determined that his system is big-endian? > > I just wanted to point this out. This might indicate that something > else has > gone wrong earlier in the configure process. Thank you for the keen observation! But I think it is a bug in the configure script, that I have seen, but yet had time to fix. //Fredrik From philip.race at oracle.com Fri Nov 4 14:26:10 2011 From: philip.race at oracle.com (Phil Race) Date: Fri, 04 Nov 2011 14:26:10 -0700 Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. In-Reply-To: <98d4f272-deb7-4194-a9bc-d6aa91ef9768@default> References: <98d4f272-deb7-4194-a9bc-d6aa91ef9768@default> Message-ID: <4EB45872.2080608@oracle.com> Is it looking for a JDk or a JRE ? What's in \windows\system32\java will I believe always map to a public JRE install, not a JDK. This is a 64 bit Windows 7 system - I think > 50% of windows 7 installs are 64 bit. I have *several* JRE's and JDK's installed. The JRE's are in the default locations, the JDKs are installed into \jdk1.6 and \jdk1.7. But all were installed by the standard Oracle installer. Also 1.7 is my default JRE , [how] could that be the problem ? sh-4.1$ which java /cygdrive/c/Windows/system32/java sh-4.1$ java -version java version "1.7.0_01" Java(TM) SE Runtime Environment (build 1.7.0_01-b08) Java HotSpot(TM) Client VM (build 21.1-b02, mixed mode, sharing) -phil. On 11/4/2011 1:52 PM, Fredrik ?hrstr?m wrote: > clicking for java... /cygdrive/c/Windows/system32/java >> checking for java... (cached) /cygdrive/c/Windows/system32/java >> checking for cygpath... (cached) /usr/bin/cygpath >> configure: error: Cannot find the rt.jar or its equivalent! > So it seems like it can't find the jdk where the rt.jar is stored. > Have you done a default install using the Oracle Java Installer? The Windows/system32/java installation is new to me. Where is the actual jdk stored? > >> How does it look for rt.jar ? Actually why does it need rt.jar ? > When it thinks it has found the jdk it will look for rt.jar or classes.jar (macosx) in the directories below. > > The explicit path to rt.jar is necessary when compiling with -source 6 -target 6, which is done when building the build tools, that have to be run by the boot jdk. > > //Fredrik From philip.race at oracle.com Fri Nov 4 14:27:05 2011 From: philip.race at oracle.com (Phil Race) Date: Fri, 04 Nov 2011 14:27:05 -0700 Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. In-Reply-To: <4EB451C7.7090904@oracle.com> References: <98d4f272-deb7-4194-a9bc-d6aa91ef9768@default> <4EB451C7.7090904@oracle.com> Message-ID: <4EB458A9.3010904@oracle.com> On 11/4/2011 1:57 PM, Stuart Marks wrote: > Phil's build output had something else significant that seemed very > strange to me: > >> checking for host address size... 32 bits >> checking whether byte ordering is bigendian... yes >> configure: WARNING: The tested endian in the host (big) differs from >> the endian >> expected to be found in the host (little) > > Given that Phil is apparently building on a Win32 system on x86, how > could something have determined that his system is big-endian? > > I just wanted to point this out. This might indicate that something > else has gone wrong earlier in the configure process. Indeed, that's what I meant by "I don't know how disconcerted to be by the warning". -phil. > > s'marks From robert.ottenhag at oracle.com Fri Nov 4 14:30:47 2011 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Fri, 04 Nov 2011 22:30:47 +0100 Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. In-Reply-To: <98d4f272-deb7-4194-a9bc-d6aa91ef9768@default> References: <98d4f272-deb7-4194-a9bc-d6aa91ef9768@default> Message-ID: <4EB45987.600@oracle.com> On 11/04/2011 09:52 PM, Fredrik ?hrstr?m wrote: > ----- philip.race at oracle.com skrev: >> OK .. but VS sets the variable VS100COMNTOOLS so all you had to do >> was look for this variable >> VS100COMNTOOLS=c:\vs2010\Common7\Tools\ > Excellent! I will improve the configure script to look for this! > It currently only searches for vcvarsall.bat under "Program Files" Ok. > >> checking for java... /cygdrive/c/Windows/system32/java >> checking for java... (cached) /cygdrive/c/Windows/system32/java >> checking for cygpath... (cached) /usr/bin/cygpath >> configure: error: Cannot find the rt.jar or its equivalent! > So it seems like it can't find the jdk where the rt.jar is stored. > Have you done a default install using the Oracle Java Installer? The Windows/system32/java installation is new to me. Where is the actual jdk stored? The java.exe launcher in c:\windows\system32 belongs to the public JRE (JRockit or Sun JREs). The launcher use the Windows registry to find the location of the public JRE installation directory. In fact, you may use the Windows registry to locate any JDK or public JRE that is installed by the JRockit or Sun installers, at keys HKLM\Software\{JavaSoft,JRockit}. There is a system tool called reg.exe to read the registry from the command line. /Robert > >> How does it look for rt.jar ? Actually why does it need rt.jar ? > When it thinks it has found the jdk it will look for rt.jar or classes.jar (macosx) in the directories below. > > The explicit path to rt.jar is necessary when compiling with -source 6 -target 6, which is done when building the build tools, that have to be run by the boot jdk. > > //Fredrik From fredrik.ohrstrom at oracle.com Fri Nov 4 14:46:25 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 04 Nov 2011 21:46:25 +0000 Subject: hg: build-infra/jdk7: Now uses the env variable %VS100COMNTOOLS% to find the Message-ID: <20111104214626.01B6E47244@hg.openjdk.java.net> Changeset: 7240b1c11ea5 Author: ohrstrom Date: 2011-11-04 22:44 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/7240b1c11ea5 Now uses the env variable %VS100COMNTOOLS% to find the Visual Studio installationin addition to searching in %PROGRAMFILES%. ! configure ! configure.ac From fredrik.ohrstrom at oracle.com Fri Nov 4 14:49:14 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 4 Nov 2011 14:49:14 -0700 (PDT) Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. Message-ID: <720325df-fee3-40f1-a232-a717542fb9c0@default> ----- philip.race at oracle.com skrev: > Is it looking for a JDk or a JRE ? What's in \windows\system32\java > will I believe always map to a public JRE install, not a JDK. It needs a jdk. (Since it needs a javac.) > I have *several* JRE's and JDK's installed. The JRE's are in the If you have several JRES/JDKS installed, you will probably have to set JAVA_HOME or use --with-boot-jdk= to specify exactly which JDK you want to build with. The intent is that a default install of a Java JDK in the default directory, should be found by configure. If you got anything else, you need to specify it manually. //Fredrik From fredrik.ohrstrom at oracle.com Fri Nov 4 14:52:16 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 4 Nov 2011 14:52:16 -0700 (PDT) Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. Message-ID: <092fb4c2-ab1e-4c4e-acb7-c7d962acd2d8@default> ----- stuart.marks at oracle.com skrev: > something have determined that his system is big-endian? > I just wanted to point this out. This might indicate that something > else has gone wrong earlier in the configure process. I now know what the problem is, the configure script, adds LDFLAGS to cl.exe when building an executable for testing bigendian. But the LDFLAGS are only valid for linking using link.exe, thus it fails. I will have to think through this a bit to come up with a cleaner solution. It probably involves not setting LDFLAGS, but instead LDFLAGS_LIB and using that to setup LDFLAGS_JDKLIB later on. //Fredrik From fredrik.ohrstrom at oracle.com Fri Nov 4 14:53:12 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Fri, 4 Nov 2011 14:53:12 -0700 (PDT) Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. Message-ID: <01b25e31-3d01-41de-8461-8a8b568b1a05@default> ----- philip.race at oracle.com skrev: > OK .. but VS sets the variable VS100COMNTOOLS so all you had to do > was look for this variable > VS100COMNTOOLS=c:\vs2010\Common7\Tools\ Please test again! I have pushed a fix. //Fredrik From philip.race at oracle.com Fri Nov 4 15:06:28 2011 From: philip.race at oracle.com (Phil Race) Date: Fri, 04 Nov 2011 15:06:28 -0700 Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. In-Reply-To: <01b25e31-3d01-41de-8461-8a8b568b1a05@default> References: <01b25e31-3d01-41de-8461-8a8b568b1a05@default> Message-ID: <4EB461E4.1030108@oracle.com> Yep that worked. I see you ran vsvarsall.bat I've always run vc\bin\vcvars32.bat I only need to set up the compiler envt. not the whole Visual Studio envt and my experience is that sometimes the latter inserts things that cause problems. -phil. On 11/4/2011 2:53 PM, Fredrik ?hrstr?m wrote: > ----- philip.race at oracle.com skrev: > >> OK .. but VS sets the variable VS100COMNTOOLS so all you had to do >> was look for this variable >> VS100COMNTOOLS=c:\vs2010\Common7\Tools\ > Please test again! I have pushed a fix. > > //Fredrik From philip.race at oracle.com Fri Nov 4 15:16:49 2011 From: philip.race at oracle.com (Phil Race) Date: Fri, 04 Nov 2011 15:16:49 -0700 Subject: As you might have seen in the last changset, build-infra now builds on 32bit windows. In-Reply-To: <720325df-fee3-40f1-a232-a717542fb9c0@default> References: <720325df-fee3-40f1-a232-a717542fb9c0@default> Message-ID: <4EB46451.9020909@oracle.com> setting JAVA_HOME=c:\jdk1.6 worked. Maybe that wouldn't have been necessary if I'd installed in the default location. -phil. On 11/4/2011 2:49 PM, Fredrik ?hrstr?m wrote: > ----- philip.race at oracle.com skrev: > >> Is it looking for a JDk or a JRE ? What's in \windows\system32\java >> will I believe always map to a public JRE install, not a JDK. > It needs a jdk. (Since it needs a javac.) > >> I have *several* JRE's and JDK's installed. The JRE's are in the > If you have several JRES/JDKS installed, you will probably > have to set JAVA_HOME or use --with-boot-jdk= > to specify exactly which JDK you want to build with. > > The intent is that a default install of a Java JDK in the default > directory, should be found by configure. If you got anything else, > you need to specify it manually. > > //Fredrik From weijun.wang at oracle.com Fri Nov 4 19:04:00 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Sat, 5 Nov 2011 10:04:00 +0800 Subject: Improved build system In-Reply-To: References: Message-ID: <1FD6CAB4-E27B-4488-A666-E577C27152FD@oracle.com> On Nov 4, 2011, at 11:40 PM, Fredrik ?hrstr?m wrote: > It is the default Ubuntu Java package. > > Just install the openjdk package and you will get iced tea. > The configure script should remind you what the package name is, > if you make sure that you have no java in the path. I'll try it on a separate machine. > > By the way. You do not have your source and build directory > on NFS do you? The javacserver uses file system locking > to establish a single server. And locking does not work > very well over nfs. (Also building is much slower, if it works.) No. Everything is on my own disk. -Max > > //Fredrik > ----- weijun.wang at oracle.com skrev: > >> I don't have an IcedTea. Do I need to build one? >> >> -Max >> >> >> >> On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m >> wrote: >> >>> >>> Ok, could you please try just: >>> >>> ./configure >>> >>> and use the default iced-tea? >>> >>> //Fredrik >>> >>> ----- weijun.wang at oracle.com skrev: >>> >>>> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>>>> >>>>> Please send me the build.log file.... >>>> >>>> Attached. >>>> >>>>> >>>>> You can also try: >>>>> >>>>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >>>> --disable-javac-deps --disable-javac-server >>>> >>>> This works. >>>> >>>> -Max >>>> >>>>> >>>>> ----- weijun.wang at oracle.com skrev: >>>>> >>>>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>>>> >>>>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>>>> 2. get_source.sh >>>>>> 3. Download ccache 3.1.6 source and build it >>>>>> 4. Download the 3 files in common/config and mv one of them >>>>>> 5. ./configure --with-boot-jdk=$J6 >>>>>> 6. make >>>>>> >>>>>> and soon see an error >>>>>> >>>>>> Compiling 10 files in package com/sun/source/util >>>>>> >>>> >> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>>>> >>>>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>>>> public interface TypeVisitor { >>>>>> ^ >>>>>> >>>>>> -Max From david.holmes at oracle.com Sun Nov 6 17:12:12 2011 From: david.holmes at oracle.com (David Holmes) Date: Mon, 07 Nov 2011 11:12:12 +1000 Subject: Improved build system In-Reply-To: <26962FEA-7639-433B-9BBC-B7E7D018AA2A@oracle.com> References: <4EB43234.8090400@oracle.com> <26962FEA-7639-433B-9BBC-B7E7D018AA2A@oracle.com> Message-ID: <4EB7306C.7060109@oracle.com> On 5/11/2011 5:08 AM, Kelly O'Hair wrote: > > You would be amazed at how many people still use NFS partitions to build in. :^( Yes, but even if we build locally we _do_ still use NFS for the source tree and that is not something I expect to change. My "workstation" is a Solaris box, my build machine is whatever I'm targeting and I do not expect to have to transfer edits between my workstation and build machine (I've worked that way in the past when my workstation and build machine were on different continents, and I don't expect to have to do it when they are next to each other!) David > -kto > > On Nov 4, 2011, at 11:43 AM, Jonathan Gibbons wrote: > >> For Max's issue, I agree. But if NFS is generally discouraged, as you imply, then you should get at least a warning if you try and use it, independent of Max's response. >> >> -- Jon >> >> >> >> On 11/04/2011 11:18 AM, Fredrik ?hrstr?m wrote: >>>> Does the build, can the build, check for NFS, and report an error? >>>> >>>> Jon >>> >>> You are right, if it is relevant to check for NFS, then it is a test that really should be done in configure. >>> >>> But we have to wait for Weijun's answer to see if nfs is involved or not. >>> >>> //Fredrik >>> >>> ----- fredrik.ohrstrom at oracle.com skrev: >>> >>>> It is the default Ubuntu Java package. >>>> >>>> Just install the openjdk package and you will get iced tea. >>>> The configure script should remind you what the package name is, >>>> if you make sure that you have no java in the path. >>>> >>>> By the way. You do not have your source and build directory >>>> on NFS do you? The javacserver uses file system locking >>>> to establish a single server. And locking does not work >>>> very well over nfs. (Also building is much slower, if it works.) >>>> >>>> //Fredrik >>>> ----- weijun.wang at oracle.com skrev: >>>> >>>>> I don't have an IcedTea. Do I need to build one? >>>>> >>>>> -Max >>>>> >>>>> >>>>> >>>>> On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m >>>>> wrote: >>>>> >>>>>> Ok, could you please try just: >>>>>> >>>>>> ./configure >>>>>> >>>>>> and use the default iced-tea? >>>>>> >>>>>> //Fredrik >>>>>> >>>>>> ----- weijun.wang at oracle.com skrev: >>>>>> >>>>>>> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>>>>>>> Please send me the build.log file.... >>>>>>> Attached. >>>>>>> >>>>>>>> You can also try: >>>>>>>> >>>>>>>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >>>>>>> --disable-javac-deps --disable-javac-server >>>>>>> >>>>>>> This works. >>>>>>> >>>>>>> -Max >>>>>>> >>>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>>> >>>>>>>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>>>>>>> >>>>>>>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>>>>>>> 2. get_source.sh >>>>>>>>> 3. Download ccache 3.1.6 source and build it >>>>>>>>> 4. Download the 3 files in common/config and mv one of them >>>>>>>>> 5. ./configure --with-boot-jdk=$J6 >>>>>>>>> 6. make >>>>>>>>> >>>>>>>>> and soon see an error >>>>>>>>> >>>>>>>>> Compiling 10 files in package com/sun/source/util >>>>>>>>> >>>> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>>>>>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>>>>>>> public interface TypeVisitor { >>>>>>>>> ^ >>>>>>>>> >>>>>>>>> -Max >> > From erik.joelsson at oracle.com Mon Nov 7 05:05:33 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 07 Nov 2011 13:05:33 +0000 Subject: hg: build-infra/jdk7: Added support for skipping auto-adding of META-INF to jars. Message-ID: <20111107130533.BD0DF47264@hg.openjdk.java.net> Changeset: 66d4a4880a73 Author: erikj Date: 2011-11-07 14:03 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/66d4a4880a73 Added support for skipping auto-adding of META-INF to jars. ! common/make/JavaCompilation.gmk From erik.joelsson at oracle.com Mon Nov 7 05:06:23 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 07 Nov 2011 13:06:23 +0000 Subject: hg: build-infra/jdk7/jdk: Converted jconsole. Message-ID: <20111107130633.5040E47265@hg.openjdk.java.net> Changeset: c6871f76a9b9 Author: erikj Date: 2011-11-07 14:04 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/c6871f76a9b9 Converted jconsole. ! make/CopyIntoClasses.gmk ! make/GensrcMisc.gmk ! make/Images.gmk ! make/sun/Makefile - make/sun/jconsole/FILES.gmk - make/sun/jconsole/Makefile From erik.joelsson at oracle.com Mon Nov 7 06:16:45 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 07 Nov 2011 14:16:45 +0000 Subject: hg: build-infra/jdk7/jdk: Converted native2ascii and dtrace. Message-ID: <20111107141705.BA4E847266@hg.openjdk.java.net> Changeset: 0dbbb555f360 Author: erikj Date: 2011-11-07 15:16 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/0dbbb555f360 Converted native2ascii and dtrace. ! make/CompileNativeLibraries.gmk ! make/sun/Makefile - make/sun/native2ascii/Makefile - make/sun/tracing/Makefile - make/sun/tracing/dtrace/Makefile From jonathan.gibbons at oracle.com Mon Nov 7 10:50:49 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 07 Nov 2011 10:50:49 -0800 Subject: 2nd and 3rd tier targets Message-ID: <4EB82889.8000205@oracle.com> New-build team, Right now, I imagine you're all busy on what I could describe as the "1st tier" targets in the Makefiles -- simply being able to build JDK as needed on all platforms. I wonder if you've given thought to supporting and/or providing additional interesting targets. For example, I could imagine providing "2nd tier" targets which are of interest to all, but which are not required as part of building JDK. Running FindBugs or CheckStyle might come into this category. Then there are targets specific to a component, which I call "3rd tier" targets. For example, langtools/make/build.xml has a target to run a utility to generate an HTML file containing examples of as many as possible of the diagnostics that can be run by javac. -- Jon From oehrstroem at gmail.com Mon Nov 7 12:19:00 2011 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 7 Nov 2011 21:19:00 +0100 Subject: Fwd: 2nd and 3rd tier targets In-Reply-To: References: <4EB82889.8000205@oracle.com> Message-ID: 2011/11/7 Jonathan Gibbons : > Right now, I imagine you're all busy on what I could describe as the "1st > tier" targets in the Makefiles -- simply being able to build JDK as needed > on all platforms. Indeed! :-) > I wonder if you've given thought to supporting and/or providing additional > interesting targets. > > For example, I could imagine providing "2nd tier" targets which are of > interest to all, but which are not required as part of building JDK. > Running FindBugs or CheckStyle might come into this category. Absolutely. But I would favor creating shellscripts instead and reserve make file targets for build artifacts. We could for example add: common/bin/findbugs.sh common/bin/checkstyle.sh we are already adding common/bin/compareimages.sh These shell scripts could be pure shell script, or run a jar file, and if the jar file does not exist, invoke make to create it. > Then there are > targets specific to a component, which I call "3rd tier" targets. For > example, langtools/make/build.xml has a target to run a utility to generate > an HTML file containing examples of as many as possible of the diagnostics > that can be run by javac. Also a shell script, perhaps in langtools/bin? //Fredrik From philip.race at oracle.com Mon Nov 7 12:41:08 2011 From: philip.race at oracle.com (Phil Race) Date: Mon, 07 Nov 2011 12:41:08 -0800 Subject: Sv: OOME in javac when building on Windows 7 In-Reply-To: References: Message-ID: <4EB84264.3040203@oracle.com> Fredrik, ['ccing the list] On 11/5/2011 2:14 AM, Fredrik ?hrstr?m wrote: > I think you have set an explicit --with-server-java=".." > where you have not added enough heap. > > If you just run ./configure, then it should set the > heap size properly. > > Try that. > > //Fredrik > > ----- philip.race at oracle.com skrev: > >> configure is happy now but the build fails with OOM .. large >> attachment >> so sending to you directly. >> >> -phil. I never used that option. I was just using ./configure. That in fact said it would build both so I removed the server dir : rm -rf windows-i586-clientANDserver-release and tried again with : ./configure --with-jvm-variant=client --with-freetype=/cygdrive/c/build-infra/freetype I still get the OOME The system is out of resources. Consult the following stack trace for details. java.lang.OutOfMemoryError: GC overhead limit exceeded at com.sun.tools.javac.parser.JavacParser.blockStatements(JavacParser.ja va:1551) at com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:1523) at com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:1537) at com.sun.tools.javac.parser.JavacParser.methodDeclaratorRest(JavacPars er.java:2654) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaratio n(JavacParser.java:2603) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacPars er.java:2531) at com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.j ava:2379) at com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclarat ion(JavacParser.java:2320) at com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.ja va:2309) at com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacPars er.java:2247) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:630) at com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667) at com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:96 4) at com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:855) at com.sun.tools.javac.main.Main.compile(Main.java:546) at com.sun.tools.javac.main.JavacServer$Handler.run(JavacServer.java:660 ) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor .java:603) at java.lang.Thread.run(Thread.java:722) Javac command line that failed: -XDserver:portfile=c:/build-infra/jdk7/build/win dows-i586-client-release/javacservers/GENERATE_NEWBYTECODE.port,poolsize=6,javac =C:/build-infra/jdk7/build/windows-i586-client-release/uncygdrive.exe%20C:/jdk1. 7/bin/java%20-XX:+UseParallelOldGC%20-verbosegc%20-Xbootclasspath/p:c:/build-inf ra/jdk7/build/windows-i586-client-release/langtools/dist/bootstrap/lib/javac.jar %20-jar%20c:/build-infra/jdk7/build/windows-i586-client-release/langtools/dist/b ootstrap/lib/javac.jar -XDdeps=file=c:/build-infra/jdk7/build/windows-i586-clien t-release/corba/classes/com/sun/corba/se/impl/logging/_the.package.deps,groupon= package -XDpubapi=file=c:/build-infra/jdk7/build/windows-i586-client-release/cor ba/classes/com/sun/corba/se/impl/logging/_the.package.api,notify,package=com.sun .corba.se.impl.logging -XDnativeapi=file=c:/build-infra/jdk7/build/windows-i586- client-release/corba/classes/com/sun/corba/se/impl/logging/_the.package.native,n otify,package=com.sun.corba.se.impl.logging -Xprefer:source -XDignore.symbol.fil e=true -cp C:/jdk1.7/lib/tools.jar -Xlint:all,-deprecation,-unchecked,-serial,-f allthrough,-cast,-rawtypes,-static,-dep-ann -implicit:none -sourcepath c:/build- infra/jdk7/corba/src/share/classes;c:/build-infra/jdk7/build/windows-i586-client -release/corba/gensrc;c:/build-infra/jdk7/build/windows-i586-client-release/corb a/logwrappers -d c:/build-infra/jdk7/build/windows-i586-client-release/corba/cla sses @C:\Users\prr\AppData\Local\Temp\atfile_a08860 My machine is an 8-core Xeon with 6GB RAM .. running 64 bit Windows 7. I am using 32 bit JDK 1.7.0_01 as the bootstrap JDK, set via "JAVA_HOME". I see that the build set "UseParallelOldGC". Why ? I don't see any heap options although that may imply some but I am not sure how well it works for the client VM .. on the other hand it apparently worked for you. I didn't use any of the options you had in your email from a week or so ago "--disable-javac-multi-core --disable-javac-deps --disable-javac-server" but your email said those were just to prevent a 2 minute timeout. ==== And one other thing: about a minute into the build a windows command tool GUI pops up, but there's no shell in the window - its empty. Its appears something in the build inadvertently creates this GUI to run some command. I didn't notice when it went away, but it was gone by the time the build failed. -phil. From fredrik.ohrstrom at oracle.com Mon Nov 7 13:19:48 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Mon, 7 Nov 2011 13:19:48 -0800 (PST) Subject: Sv: OOME in javac when building on Windows 7 Message-ID: <9b54e0e5-15a2-4261-8d9e-6b2e152ed22c@default> Please try with a 64 bit jvm. The configure script needs to be updated to detect when you run with a 32 bit jvm to accomodate for the smaller available heap size. The configure script calculates the needed amount of heap memory for the javac server. It needs a LOT of memory for the time being since each core gets its own JavaCompiler, and each JavaCompiler ends up with 30% (wild guesstime) of all classes in the JDK. The reason is of course that the JavaCompilers do not share any state. In the future we will have them share state so that the memory usage shrinks. (Look in configure.ac for "We try to limit the heap size" and you will find the rudimentary calculations.) Now, the configure script, should stop and complain when it calculated a heap size, which does not work. Instead the ac macro ADD_JVM_ARG_IF_OK simply does not add the heap size, which is why the javac server line: javac=C:/build-infra/jdk7/build/windows-i586-client-release/uncygdrive.exe%20C:/jdk1.7/bin/java%20-XX:+UseParallelOldGC%20-verbosegc%20 does not have any -Xmx. I will fix that. Also, the configure script defaults to 4 cores on windows, will fix that too. As for the GUI popup. On Windows, it is impossible to run a background command without a window, unless it is a service. Thus the window is the javac server. I can make a copy of the javac server log scroll by in that window, if you like, now it is stored in build/windows..../javacserver/*.stdouterr To get rid of the annoying pause after building a repository: Remove the line BUILD_LOG_WRAPPER:=.... in your spec.gmk //Fredrik ----- philip.race at oracle.com skrev: > Fredrik, > > ['ccing the list] > > > On 11/5/2011 2:14 AM, Fredrik ?hrstr?m wrote: > > I think you have set an explicit --with-server-java=".." > > where you have not added enough heap. > > > > If you just run ./configure, then it should set the > > heap size properly. > > > > Try that. > > > > //Fredrik > > > > ----- philip.race at oracle.com skrev: > > > >> configure is happy now but the build fails with OOM .. large > >> attachment > >> so sending to you directly. > >> > >> -phil. > > > I never used that option. I was just using ./configure. > That in fact said it would build both so I removed the server dir : > rm -rf windows-i586-clientANDserver-release > > and tried again with : > ./configure --with-jvm-variant=client > --with-freetype=/cygdrive/c/build-infra/freetype > > I still get the OOME > The system is out of resources. > Consult the following stack trace for details. > java.lang.OutOfMemoryError: GC overhead limit exceeded > at > com.sun.tools.javac.parser.JavacParser.blockStatements(JavacParser.ja > va:1551) > at > com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:1523) > at > com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:1537) > at > com.sun.tools.javac.parser.JavacParser.methodDeclaratorRest(JavacPars > er.java:2654) > at > com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaratio > n(JavacParser.java:2603) > at > com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacPars > er.java:2531) > at > com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.j > ava:2379) > at > com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclarat > ion(JavacParser.java:2320) > at > com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.ja > va:2309) > at > com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacPars > er.java:2247) > at > com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:630) > at > com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667) > at > com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:96 > 4) > at > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:855) > at com.sun.tools.javac.main.Main.compile(Main.java:546) > at > com.sun.tools.javac.main.JavacServer$Handler.run(JavacServer.java:660 > ) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. > java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor > .java:603) > at java.lang.Thread.run(Thread.java:722) > > > Javac command line that failed: > -XDserver:portfile=c:/build-infra/jdk7/build/win > dows-i586-client-release/javacservers/GENERATE_NEWBYTECODE.port,poolsize=6,javac > =C:/build-infra/jdk7/build/windows-i586-client-release/uncygdrive.exe%20C:/jdk1. > 7/bin/java%20-XX:+UseParallelOldGC%20-verbosegc%20-Xbootclasspath/p:c:/build-inf > ra/jdk7/build/windows-i586-client-release/langtools/dist/bootstrap/lib/javac.jar > %20-jar%20c:/build-infra/jdk7/build/windows-i586-client-release/langtools/dist/b > ootstrap/lib/javac.jar > -XDdeps=file=c:/build-infra/jdk7/build/windows-i586-clien > t-release/corba/classes/com/sun/corba/se/impl/logging/_the.package.deps,groupon= > package > -XDpubapi=file=c:/build-infra/jdk7/build/windows-i586-client-release/cor > ba/classes/com/sun/corba/se/impl/logging/_the.package.api,notify,package=com.sun > .corba.se.impl.logging > -XDnativeapi=file=c:/build-infra/jdk7/build/windows-i586- > client-release/corba/classes/com/sun/corba/se/impl/logging/_the.package.native,n > otify,package=com.sun.corba.se.impl.logging -Xprefer:source > -XDignore.symbol.fil > e=true -cp C:/jdk1.7/lib/tools.jar > -Xlint:all,-deprecation,-unchecked,-serial,-f > allthrough,-cast,-rawtypes,-static,-dep-ann -implicit:none -sourcepath > > c:/build- > infra/jdk7/corba/src/share/classes;c:/build-infra/jdk7/build/windows-i586-client > -release/corba/gensrc;c:/build-infra/jdk7/build/windows-i586-client-release/corb > a/logwrappers -d > c:/build-infra/jdk7/build/windows-i586-client-release/corba/cla > sses @C:\Users\prr\AppData\Local\Temp\atfile_a08860 > > > My machine is an 8-core Xeon with 6GB RAM .. running 64 bit Windows > 7. > I am using 32 bit JDK 1.7.0_01 as the bootstrap JDK, set via > "JAVA_HOME". > > I see that the build set "UseParallelOldGC". Why ? I don't see any > heap > options although > that may imply some but I am not sure how well it works for the client > > VM .. on > the other hand it apparently worked for you. > I didn't use any of the options you had in your email from a week or > so ago > "--disable-javac-multi-core --disable-javac-deps > --disable-javac-server" > but your email said those were just to prevent a 2 minute timeout. > > ==== > > And one other thing: about a minute into the build a windows command > tool GUI > pops up, but there's no shell in the window - its empty. Its appears > something in the > build inadvertently creates this GUI to run some command. > I didn't notice when it went away, but it was gone by the time the > build > failed. > > -phil. From philip.race at oracle.com Mon Nov 7 13:39:59 2011 From: philip.race at oracle.com (Phil Race) Date: Mon, 07 Nov 2011 13:39:59 -0800 Subject: Sv: OOME in javac when building on Windows 7 In-Reply-To: <9b54e0e5-15a2-4261-8d9e-6b2e152ed22c@default> References: <9b54e0e5-15a2-4261-8d9e-6b2e152ed22c@default> Message-ID: <4EB8502F.2090305@oracle.com> Hi, I can definitely switch it to 64 bit JRE. I didn't do that because your original email subject was "build-infra now builds on 32bit windows." So I tried to avoid 64 bit thinking that was what wouldn't work. Should I now infer that the configure script would have been ok with the client VM on 32 bit windows because it would have set up all options for client ? But it sounds like this would lose some of the build time benefits unless you can have a 64 bit JDK. Couldn't you instead just pass "-server" to the 32 bit JDK? The 32 bit JDK for windows has a server VM too. For the GUI pop-up, our build systems in labs have historically been a bit more of a pain to configure when they needed access to the console. Kelly knows the details better than I do. Maybe you could try "javaw.exe" to run that server ? It shouldn't need a console. "-Djava.awt.headless=true" is worth a try but I suspect won't prevent the console. -phil. On 11/7/2011 1:19 PM, Fredrik ?hrstr?m wrote: > Please try with a 64 bit jvm. The configure script needs to be > updated to detect when you run with a 32 bit jvm to accomodate > for the smaller available heap size. > > The configure script calculates the needed amount of heap memory > for the javac server. It needs a LOT of memory for the time being > since each core gets its own JavaCompiler, and each JavaCompiler > ends up with 30% (wild guesstime) of all classes in the JDK. > The reason is of course that the JavaCompilers do not share any state. > In the future we will have them share state so that the memory usage > shrinks. (Look in configure.ac for "We try to limit the heap size" > and you will find the rudimentary calculations.) > > Now, the configure script, should stop and complain when it calculated > a heap size, which does not work. Instead the ac macro ADD_JVM_ARG_IF_OK > simply does not add the heap size, which is why the javac server line: > javac=C:/build-infra/jdk7/build/windows-i586-client-release/uncygdrive.exe%20C:/jdk1.7/bin/java%20-XX:+UseParallelOldGC%20-verbosegc%20 > does not have any -Xmx. I will fix that. > > Also, the configure script defaults to 4 cores on windows, will fix that too. > > As for the GUI popup. On Windows, it is impossible to run a background command > without a window, unless it is a service. Thus the window is the javac server. > I can make a copy of the javac server log scroll by in that window, if you like, > now it is stored in build/windows..../javacserver/*.stdouterr > > To get rid of the annoying pause after building a repository: > Remove the line BUILD_LOG_WRAPPER:=.... in your spec.gmk > > //Fredrik > > ----- philip.race at oracle.com skrev: > >> Fredrik, >> >> ['ccing the list] >> >> >> On 11/5/2011 2:14 AM, Fredrik ?hrstr?m wrote: >>> I think you have set an explicit --with-server-java=".." >>> where you have not added enough heap. >>> >>> If you just run ./configure, then it should set the >>> heap size properly. >>> >>> Try that. >>> >>> //Fredrik >>> >>> ----- philip.race at oracle.com skrev: >>> >>>> configure is happy now but the build fails with OOM .. large >>>> attachment >>>> so sending to you directly. >>>> >>>> -phil. >> >> I never used that option. I was just using ./configure. >> That in fact said it would build both so I removed the server dir : >> rm -rf windows-i586-clientANDserver-release >> >> and tried again with : >> ./configure --with-jvm-variant=client >> --with-freetype=/cygdrive/c/build-infra/freetype >> >> I still get the OOME >> The system is out of resources. >> Consult the following stack trace for details. >> java.lang.OutOfMemoryError: GC overhead limit exceeded >> at >> com.sun.tools.javac.parser.JavacParser.blockStatements(JavacParser.ja >> va:1551) >> at >> com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:1523) >> at >> com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:1537) >> at >> com.sun.tools.javac.parser.JavacParser.methodDeclaratorRest(JavacPars >> er.java:2654) >> at >> com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaratio >> n(JavacParser.java:2603) >> at >> com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacPars >> er.java:2531) >> at >> com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.j >> ava:2379) >> at >> com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclarat >> ion(JavacParser.java:2320) >> at >> com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.ja >> va:2309) >> at >> com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacPars >> er.java:2247) >> at >> com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:630) >> at >> com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667) >> at >> com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:96 >> 4) >> at >> com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:855) >> at com.sun.tools.javac.main.Main.compile(Main.java:546) >> at >> com.sun.tools.javac.main.JavacServer$Handler.run(JavacServer.java:660 >> ) >> at >> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. >> java:1110) >> at >> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor >> .java:603) >> at java.lang.Thread.run(Thread.java:722) >> >> >> Javac command line that failed: >> -XDserver:portfile=c:/build-infra/jdk7/build/win >> dows-i586-client-release/javacservers/GENERATE_NEWBYTECODE.port,poolsize=6,javac >> =C:/build-infra/jdk7/build/windows-i586-client-release/uncygdrive.exe%20C:/jdk1. >> 7/bin/java%20-XX:+UseParallelOldGC%20-verbosegc%20-Xbootclasspath/p:c:/build-inf >> ra/jdk7/build/windows-i586-client-release/langtools/dist/bootstrap/lib/javac.jar >> %20-jar%20c:/build-infra/jdk7/build/windows-i586-client-release/langtools/dist/b >> ootstrap/lib/javac.jar >> -XDdeps=file=c:/build-infra/jdk7/build/windows-i586-clien >> t-release/corba/classes/com/sun/corba/se/impl/logging/_the.package.deps,groupon= >> package >> -XDpubapi=file=c:/build-infra/jdk7/build/windows-i586-client-release/cor >> ba/classes/com/sun/corba/se/impl/logging/_the.package.api,notify,package=com.sun >> .corba.se.impl.logging >> -XDnativeapi=file=c:/build-infra/jdk7/build/windows-i586- >> client-release/corba/classes/com/sun/corba/se/impl/logging/_the.package.native,n >> otify,package=com.sun.corba.se.impl.logging -Xprefer:source >> -XDignore.symbol.fil >> e=true -cp C:/jdk1.7/lib/tools.jar >> -Xlint:all,-deprecation,-unchecked,-serial,-f >> allthrough,-cast,-rawtypes,-static,-dep-ann -implicit:none -sourcepath >> >> c:/build- >> infra/jdk7/corba/src/share/classes;c:/build-infra/jdk7/build/windows-i586-client >> -release/corba/gensrc;c:/build-infra/jdk7/build/windows-i586-client-release/corb >> a/logwrappers -d >> c:/build-infra/jdk7/build/windows-i586-client-release/corba/cla >> sses @C:\Users\prr\AppData\Local\Temp\atfile_a08860 >> >> >> My machine is an 8-core Xeon with 6GB RAM .. running 64 bit Windows >> 7. >> I am using 32 bit JDK 1.7.0_01 as the bootstrap JDK, set via >> "JAVA_HOME". >> >> I see that the build set "UseParallelOldGC". Why ? I don't see any >> heap >> options although >> that may imply some but I am not sure how well it works for the client >> >> VM .. on >> the other hand it apparently worked for you. >> I didn't use any of the options you had in your email from a week or >> so ago >> "--disable-javac-multi-core --disable-javac-deps >> --disable-javac-server" >> but your email said those were just to prevent a 2 minute timeout. >> >> ==== >> >> And one other thing: about a minute into the build a windows command >> tool GUI >> pops up, but there's no shell in the window - its empty. Its appears >> something in the >> build inadvertently creates this GUI to run some command. >> I didn't notice when it went away, but it was gone by the time the >> build >> failed. >> >> -phil. From jonathan.gibbons at oracle.com Mon Nov 7 13:43:13 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 07 Nov 2011 13:43:13 -0800 Subject: Fwd: 2nd and 3rd tier targets In-Reply-To: References: <4EB82889.8000205@oracle.com> Message-ID: <4EB850F1.9090101@oracle.com> Having shell scripts makes things convenient for developers on local machines, but might make things less convenient when submitting jobs to make-oriented build farms. It would also be nice if the necessary tools were made available in the same way that you talk about compilers and other stuff being made available. -- Jon On 11/07/2011 12:19 PM, Fredrik ?hrstr?m wrote: > 2011/11/7 Jonathan Gibbons: >> Right now, I imagine you're all busy on what I could describe as the "1st >> tier" targets in the Makefiles -- simply being able to build JDK as needed >> on all platforms. > Indeed! :-) > >> I wonder if you've given thought to supporting and/or providing additional >> interesting targets. >> >> For example, I could imagine providing "2nd tier" targets which are of >> interest to all, but which are not required as part of building JDK. >> Running FindBugs or CheckStyle might come into this category. > Absolutely. But I would favor creating shellscripts instead and reserve > make file targets for build artifacts. We could for example add: > > common/bin/findbugs.sh > common/bin/checkstyle.sh > > we are already adding > common/bin/compareimages.sh > > These shell scripts could be pure shell script, or run a jar file, and if the > jar file does not exist, invoke make to create it. > >> Then there are >> targets specific to a component, which I call "3rd tier" targets. For >> example, langtools/make/build.xml has a target to run a utility to generate >> an HTML file containing examples of as many as possible of the diagnostics >> that can be run by javac. > Also a shell script, perhaps in langtools/bin? > > //Fredrik From fredrik.ohrstrom at oracle.com Mon Nov 7 13:54:39 2011 From: fredrik.ohrstrom at oracle.com (=?UTF-8?B?RnJlZHJpayDDlmhyc3Ryw7Zt?=) Date: Mon, 7 Nov 2011 13:54:39 -0800 (PST) Subject: Sv: Re: Sv: OOME in javac when building on Windows 7 Message-ID: ----- philip.race at oracle.com skrev: > I can definitely switch it to 64 bit JRE. I didn't do that because > your original email > subject was "build-infra now builds on 32bit windows." So I tried to > avoid 64 bit thinking that was what wouldn't work. That was a reasonable assumption. :-) But the real reason it only builds a 32 bit jvm, is because config.guess returns i686-pc-cygwin instead of x86_64-pc-cygwin. I do not know why. Perhaps it is a bug in config.guess, perhaps it is a side effect of cygwin being 32 bit? Anyone out there who knows? > Should I now infer that the configure script would have been ok with > the client VM > on 32 bit windows because it would have set up all options for client > ? The settings -client -server does not affect the possible size of the heap. On a 32 bit machine, the available virtual memory is 2G on Windows, or 3G since the java launcher and jvm.dll are compiled with LARGEADDRESSAWARE. (I think they are?) Unfortunately, that memory is severly fragmented on Windows (dll:s are sprinkled around as salt and pepper), and Hotspot/OpenJDK cannot deal with split heaps (JRockit can). So the largest contiguous memory chunk that is possible to find on Windows 32 bit, is usually around 1.8G. Which is the maximum heap size. > But it sounds like this would lose some of the build time benefits > unless you can have a 64 bit JDK. In a way, yes. Since the javacserver is a memory hog scaling in size with the number of cores. Yes, to get full speed on all cores, you need a 64 bit machine. When we improve javac, and move some shellscript code into a smarter javac, then this will not be a problem. For build systems with fewer cores (1) or very little memory. You can use --disable-javac-multi-core --disable-javac-deps --disable-javac-server and the memory usage will be smaller. I have successfully built the openjdk build-infra forest on my asus 901 netbook with 1G of RAM using that config. Took a while though, but most of that time was spent on C++. > Maybe you could try "javaw.exe" to run that server ? It shouldn't need > a console. > "-Djava.awt.headless=true" is worth a try but I suspect won't prevent > the console. Ah, of course. Thanks for the tip! I'll try that. You can try too. Simply change in the spec.gmk file where it says SERVER_JAVA:=.... to use javaw instead of java. //Fredrik > -phil. > > On 11/7/2011 1:19 PM, Fredrik ?hrstr?m wrote: > > Please try with a 64 bit jvm. The configure script needs to be > > updated to detect when you run with a 32 bit jvm to accomodate > > for the smaller available heap size. > > > > The configure script calculates the needed amount of heap memory > > for the javac server. It needs a LOT of memory for the time being > > since each core gets its own JavaCompiler, and each JavaCompiler > > ends up with 30% (wild guesstime) of all classes in the JDK. > > The reason is of course that the JavaCompilers do not share any > state. > > In the future we will have them share state so that the memory > usage > > shrinks. (Look in configure.ac for "We try to limit the heap size" > > and you will find the rudimentary calculations.) > > > > Now, the configure script, should stop and complain when it > calculated > > a heap size, which does not work. Instead the ac macro > ADD_JVM_ARG_IF_OK > > simply does not add the heap size, which is why the javac server > line: > > > javac=C:/build-infra/jdk7/build/windows-i586-client-release/uncygdrive.exe%20C:/jdk1.7/bin/java%20-XX:+UseParallelOldGC%20-verbosegc%20 > > does not have any -Xmx. I will fix that. > > > > Also, the configure script defaults to 4 cores on windows, will fix > that too. > > > > As for the GUI popup. On Windows, it is impossible to run a > background command > > without a window, unless it is a service. Thus the window is the > javac server. > > I can make a copy of the javac server log scroll by in that window, > if you like, > > now it is stored in build/windows..../javacserver/*.stdouterr > > > > To get rid of the annoying pause after building a repository: > > Remove the line BUILD_LOG_WRAPPER:=.... in your spec.gmk > > > > //Fredrik > > > > ----- philip.race at oracle.com skrev: > > > >> Fredrik, > >> > >> ['ccing the list] > >> > >> > >> On 11/5/2011 2:14 AM, Fredrik ?hrstr?m wrote: > >>> I think you have set an explicit --with-server-java=".." > >>> where you have not added enough heap. > >>> > >>> If you just run ./configure, then it should set the > >>> heap size properly. > >>> > >>> Try that. > >>> > >>> //Fredrik > >>> > >>> ----- philip.race at oracle.com skrev: > >>> > >>>> configure is happy now but the build fails with OOM .. large > >>>> attachment > >>>> so sending to you directly. > >>>> > >>>> -phil. > >> > >> I never used that option. I was just using ./configure. > >> That in fact said it would build both so I removed the server dir > : > >> rm -rf windows-i586-clientANDserver-release > >> > >> and tried again with : > >> ./configure --with-jvm-variant=client > >> --with-freetype=/cygdrive/c/build-infra/freetype > >> > >> I still get the OOME > >> The system is out of resources. > >> Consult the following stack trace for details. > >> java.lang.OutOfMemoryError: GC overhead limit exceeded > >> at > >> > com.sun.tools.javac.parser.JavacParser.blockStatements(JavacParser.ja > >> va:1551) > >> at > >> > com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:1523) > >> at > >> > com.sun.tools.javac.parser.JavacParser.block(JavacParser.java:1537) > >> at > >> > com.sun.tools.javac.parser.JavacParser.methodDeclaratorRest(JavacPars > >> er.java:2654) > >> at > >> > com.sun.tools.javac.parser.JavacParser.classOrInterfaceBodyDeclaratio > >> n(JavacParser.java:2603) > >> at > >> > com.sun.tools.javac.parser.JavacParser.classOrInterfaceBody(JavacPars > >> er.java:2531) > >> at > >> > com.sun.tools.javac.parser.JavacParser.classDeclaration(JavacParser.j > >> ava:2379) > >> at > >> > com.sun.tools.javac.parser.JavacParser.classOrInterfaceOrEnumDeclarat > >> ion(JavacParser.java:2320) > >> at > >> > com.sun.tools.javac.parser.JavacParser.typeDeclaration(JavacParser.ja > >> va:2309) > >> at > >> > com.sun.tools.javac.parser.JavacParser.parseCompilationUnit(JavacPars > >> er.java:2247) > >> at > >> com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:630) > >> at > >> com.sun.tools.javac.main.JavaCompiler.parse(JavaCompiler.java:667) > >> at > >> > com.sun.tools.javac.main.JavaCompiler.parseFiles(JavaCompiler.java:96 > >> 4) > >> at > >> > com.sun.tools.javac.main.JavaCompiler.compile(JavaCompiler.java:855) > >> at com.sun.tools.javac.main.Main.compile(Main.java:546) > >> at > >> > com.sun.tools.javac.main.JavacServer$Handler.run(JavacServer.java:660 > >> ) > >> at > >> > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor. > >> java:1110) > >> at > >> > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor > >> .java:603) > >> at java.lang.Thread.run(Thread.java:722) > >> > >> > >> Javac command line that failed: > >> -XDserver:portfile=c:/build-infra/jdk7/build/win > >> > dows-i586-client-release/javacservers/GENERATE_NEWBYTECODE.port,poolsize=6,javac > >> > =C:/build-infra/jdk7/build/windows-i586-client-release/uncygdrive.exe%20C:/jdk1. > >> > 7/bin/java%20-XX:+UseParallelOldGC%20-verbosegc%20-Xbootclasspath/p:c:/build-inf > >> > ra/jdk7/build/windows-i586-client-release/langtools/dist/bootstrap/lib/javac.jar > >> > %20-jar%20c:/build-infra/jdk7/build/windows-i586-client-release/langtools/dist/b > >> ootstrap/lib/javac.jar > >> -XDdeps=file=c:/build-infra/jdk7/build/windows-i586-clien > >> > t-release/corba/classes/com/sun/corba/se/impl/logging/_the.package.deps,groupon= > >> package > >> > -XDpubapi=file=c:/build-infra/jdk7/build/windows-i586-client-release/cor > >> > ba/classes/com/sun/corba/se/impl/logging/_the.package.api,notify,package=com.sun > >> .corba.se.impl.logging > >> -XDnativeapi=file=c:/build-infra/jdk7/build/windows-i586- > >> > client-release/corba/classes/com/sun/corba/se/impl/logging/_the.package.native,n > >> otify,package=com.sun.corba.se.impl.logging -Xprefer:source > >> -XDignore.symbol.fil > >> e=true -cp C:/jdk1.7/lib/tools.jar > >> -Xlint:all,-deprecation,-unchecked,-serial,-f > >> allthrough,-cast,-rawtypes,-static,-dep-ann -implicit:none > -sourcepath > >> > >> c:/build- > >> > infra/jdk7/corba/src/share/classes;c:/build-infra/jdk7/build/windows-i586-client > >> > -release/corba/gensrc;c:/build-infra/jdk7/build/windows-i586-client-release/corb > >> a/logwrappers -d > >> c:/build-infra/jdk7/build/windows-i586-client-release/corba/cla > >> sses @C:\Users\prr\AppData\Local\Temp\atfile_a08860 > >> > >> > >> My machine is an 8-core Xeon with 6GB RAM .. running 64 bit > Windows > >> 7. > >> I am using 32 bit JDK 1.7.0_01 as the bootstrap JDK, set via > >> "JAVA_HOME". > >> > >> I see that the build set "UseParallelOldGC". Why ? I don't see any > >> heap > >> options although > >> that may imply some but I am not sure how well it works for the > client > >> > >> VM .. on > >> the other hand it apparently worked for you. > >> I didn't use any of the options you had in your email from a week > or > >> so ago > >> "--disable-javac-multi-core --disable-javac-deps > >> --disable-javac-server" > >> but your email said those were just to prevent a 2 minute timeout. > >> > >> ==== > >> > >> And one other thing: about a minute into the build a windows > command > >> tool GUI > >> pops up, but there's no shell in the window - its empty. Its > appears > >> something in the > >> build inadvertently creates this GUI to run some command. > >> I didn't notice when it went away, but it was gone by the time the > >> build > >> failed. > >> > >> -phil. From oehrstroem at gmail.com Mon Nov 7 14:27:08 2011 From: oehrstroem at gmail.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Mon, 7 Nov 2011 23:27:08 +0100 Subject: Fwd: 2nd and 3rd tier targets In-Reply-To: <4EB850F1.9090101@oracle.com> References: <4EB82889.8000205@oracle.com> <4EB850F1.9090101@oracle.com> Message-ID: 2011/11/7 Jonathan Gibbons : > Having shell scripts makes things convenient for developers on local > machines, but might make things less convenient when submitting jobs to > make-oriented build farms. Yes, we have to take that into account. Perhaps a single target run: make run TOOL=checkstyle.sh that redirects to the shell script, would solve the problem. > It would also be nice if the necessary tools were made available in the same > way that you talk about compilers and other stuff being made available. If the tools are big, then yes, they can be part of build-deps. But the tools mentioned so far, seems to be rather small. //Fredrik 2011/11/7 Jonathan Gibbons : > Having shell scripts makes things convenient for developers on local > machines, but might make things less convenient when submitting jobs to > make-oriented build farms. > > It would also be nice if the necessary tools were made available in the same > way that you talk about compilers and other stuff being made available. > > -- Jon > > > On 11/07/2011 12:19 PM, Fredrik ?hrstr?m wrote: >> >> 2011/11/7 Jonathan Gibbons: >>> >>> Right now, I imagine you're all busy on what I could describe as the "1st >>> tier" targets in the Makefiles -- simply being able to build JDK as >>> needed >>> on all platforms. >> >> Indeed! :-) >> >>> I wonder if you've given thought to supporting and/or providing >>> additional >>> interesting targets. >>> >>> For example, I could imagine providing "2nd tier" targets which are of >>> interest to all, but which are not required as part of building JDK. >>> Running FindBugs or CheckStyle might come into this category. >> >> Absolutely. But I would favor creating shellscripts instead and reserve >> make file targets for build artifacts. We could for example add: >> >> common/bin/findbugs.sh >> common/bin/checkstyle.sh >> >> we are already adding >> common/bin/compareimages.sh >> >> These shell scripts could be pure shell script, or run a jar file, and if >> the >> jar file does not exist, invoke make to create it. >> >>> Then there are >>> targets specific to a component, which I call "3rd tier" targets. For >>> example, langtools/make/build.xml has a target to run a utility to >>> generate >>> an HTML file containing examples of as many as possible of the >>> diagnostics >>> that can be run by javac. >> >> Also a shell script, perhaps in langtools/bin? >> >> //Fredrik > > From jonathan.gibbons at oracle.com Mon Nov 7 14:36:33 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 07 Nov 2011 14:36:33 -0800 Subject: Fwd: 2nd and 3rd tier targets In-Reply-To: References: <4EB82889.8000205@oracle.com> <4EB850F1.9090101@oracle.com> Message-ID: <4EB85D71.3010405@oracle.com> On 11/07/2011 02:27 PM, Fredrik ?hrstr?m wrote: > If the tools are big, then yes, they can be part of build-deps. But the > tools mentioned so far, seems to be rather small. > It's not the size that matters as much as making it easy to developers to get the tools, without resorting to a miscellany of internal Oracle file servers. -- Jon From philip.race at oracle.com Mon Nov 7 16:07:51 2011 From: philip.race at oracle.com (Phil Race) Date: Mon, 07 Nov 2011 16:07:51 -0800 Subject: Sv: Re: Sv: OOME in javac when building on Windows 7 In-Reply-To: References: Message-ID: <4EB872D7.2020307@oracle.com> On 11/7/2011 1:54 PM, Fredrik ?hrstr?m wrote: > ----- philip.race at oracle.com skrev: >> I can definitely switch it to 64 bit JRE. I didn't do that because >> your original email >> subject was "build-infra now builds on 32bit windows." So I tried to >> avoid 64 bit thinking that was what wouldn't work. > That was a reasonable assumption. :-) But the real reason it only > builds a 32 bit jvm, is because config.guess returns i686-pc-cygwin > instead of x86_64-pc-cygwin. I do not know why. Perhaps it is a > bug in config.guess, perhaps it is a side effect of cygwin being 32 bit? > Anyone out there who knows? > 64 bit gets me past that problem. I've now got a new completely unrelated problem in building hotspot running the linker Compiling... c1_ValueType.cpp Generating Code... sh C:\build-infra\jdk7\hotspot/make/windows/build_vm_def.sh C:\BUILD-~1\jdk7\build\WINDOW~1\UNCYGD~1.EXE C:\vs2010\VC\BIN\link.exe @ C:\Users\prr\AppData\Local\Temp\nmC8DB.tmp LINK : fatal error LNK1181: cannot open input file 'kernel32.lib' NMAKE : fatal error U1077: 'C:\BUILD-~1\jdk7\build\WINDOW~1\UNCYGD~1.EXE' : return code '0x49d' Stop. NMAKE : fatal error U1077: 'cd' : return code '0x2' Stop. NMAKE : fatal error U1077: 'C:\vs2010\VC\BIN\nmake.EXE' : return code '0x2' Stop. make[2]: *** [generic_build1] Error 2 make[1]: *** [product1] Error 2 make: *** [hotspot] Error 2 Another path problem I suppose which is strange as the SDK and so kernel32.lib is in the standard location: sh-4.1$ pwd /cygdrive/c/Program Files (x86)/Microsoft SDKs/Windows/v7.0A/lib sh-4.1$ ls Kernel32.lib Kernel32.lib >> Should I now infer that the configure script would have been ok with >> the client VM >> on 32 bit windows because it would have set up all options for client >> ? > The settings -client -server does not affect the possible size of the heap. > On a 32 bit machine, the available virtual memory is 2G on Windows, or 3G > since the java launcher and jvm.dll are compiled with LARGEADDRESSAWARE. > (I think they are?) > > Unfortunately, that memory is severly fragmented on Windows (dll:s are > sprinkled around as salt and pepper), and Hotspot/OpenJDK > cannot deal with split heaps (JRockit can). So the largest contiguous memory > chunk that is possible to find on Windows 32 bit, is usually around 1.8G. > Which is the maximum heap size. Server can't affect the *possible* heap, but it does affect the default heap settings. But it sounds like you are saying that this javac server requires so much heap, that it will likely hit the fragmentation problem, if not the overall heap limit. In the 32 bit JRE, graphics drivers, notably D3D drivers, are a notable cause of that. I suspect that the D3D preload code for startup performance can hit you there. But it may be worth experimenting with -Dsun.java2d.d3d=false, and -Djava.awt.headless=true to minimise the likelihood of this and see what a 32 bit server JVM can handle. > >> Maybe you could try "javaw.exe" to run that server ? It shouldn't need >> a console. >> "-Djava.awt.headless=true" is worth a try but I suspect won't prevent >> the console. > Ah, of course. Thanks for the tip! I'll try that. > > You can try too. Simply change in the spec.gmk file where it says > SERVER_JAVA:=.... to use javaw instead of java. > Unfortunately it didn't help. Maybe the way its being launched is part of the problem. ie if its launched indirectly via something which causes the cmd.exe to be created already. I haven't yet found where the command is launched. -phil. > //Fredrik > From georges.saab at oracle.com Tue Nov 8 08:12:45 2011 From: georges.saab at oracle.com (Georges Saab) Date: Tue, 8 Nov 2011 08:12:45 -0800 Subject: Improved build system In-Reply-To: <4EB7306C.7060109@oracle.com> References: <4EB43234.8090400@oracle.com> <26962FEA-7639-433B-9BBC-B7E7D018AA2A@oracle.com> <4EB7306C.7060109@oracle.com> Message-ID: IMO we should not assume that build machines can NFS mount source directories from dev workstations. This is not the same thing as saying it should not be possible to take advantage of it where it is the case. /GES On 6 nov 2011, at 17:12, David Holmes wrote: > On 5/11/2011 5:08 AM, Kelly O'Hair wrote: >> >> You would be amazed at how many people still use NFS partitions to build in. :^( > > Yes, but even if we build locally we _do_ still use NFS for the source tree and that is not something I expect to change. My "workstation" is a Solaris box, my build machine is whatever I'm targeting and I do not expect to have to transfer edits between my workstation and build machine (I've worked that way in the past when my workstation and build machine were on different continents, and I don't expect to have to do it when they are next to each other!) > > David > >> -kto >> >> On Nov 4, 2011, at 11:43 AM, Jonathan Gibbons wrote: >> >>> For Max's issue, I agree. But if NFS is generally discouraged, as you imply, then you should get at least a warning if you try and use it, independent of Max's response. >>> >>> -- Jon >>> >>> >>> >>> On 11/04/2011 11:18 AM, Fredrik ?hrstr?m wrote: >>>>> Does the build, can the build, check for NFS, and report an error? >>>>> >>>>> Jon >>>> >>>> You are right, if it is relevant to check for NFS, then it is a test that really should be done in configure. >>>> >>>> But we have to wait for Weijun's answer to see if nfs is involved or not. >>>> >>>> //Fredrik >>>> >>>> ----- fredrik.ohrstrom at oracle.com skrev: >>>> >>>>> It is the default Ubuntu Java package. >>>>> >>>>> Just install the openjdk package and you will get iced tea. >>>>> The configure script should remind you what the package name is, >>>>> if you make sure that you have no java in the path. >>>>> >>>>> By the way. You do not have your source and build directory >>>>> on NFS do you? The javacserver uses file system locking >>>>> to establish a single server. And locking does not work >>>>> very well over nfs. (Also building is much slower, if it works.) >>>>> >>>>> //Fredrik >>>>> ----- weijun.wang at oracle.com skrev: >>>>> >>>>>> I don't have an IcedTea. Do I need to build one? >>>>>> >>>>>> -Max >>>>>> >>>>>> >>>>>> >>>>>> On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m >>>>>> wrote: >>>>>> >>>>>>> Ok, could you please try just: >>>>>>> >>>>>>> ./configure >>>>>>> >>>>>>> and use the default iced-tea? >>>>>>> >>>>>>> //Fredrik >>>>>>> >>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>> >>>>>>>> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>>>>>>>> Please send me the build.log file.... >>>>>>>> Attached. >>>>>>>> >>>>>>>>> You can also try: >>>>>>>>> >>>>>>>>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >>>>>>>> --disable-javac-deps --disable-javac-server >>>>>>>> >>>>>>>> This works. >>>>>>>> >>>>>>>> -Max >>>>>>>> >>>>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>>>> >>>>>>>>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>>>>>>>> >>>>>>>>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>>>>>>>> 2. get_source.sh >>>>>>>>>> 3. Download ccache 3.1.6 source and build it >>>>>>>>>> 4. Download the 3 files in common/config and mv one of them >>>>>>>>>> 5. ./configure --with-boot-jdk=$J6 >>>>>>>>>> 6. make >>>>>>>>>> >>>>>>>>>> and soon see an error >>>>>>>>>> >>>>>>>>>> Compiling 10 files in package com/sun/source/util >>>>>>>>>> >>>>> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>>>>>>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>>>>>>>> public interface TypeVisitor { >>>>>>>>>> ^ >>>>>>>>>> >>>>>>>>>> -Max >>> >> From jonathan.gibbons at oracle.com Tue Nov 8 08:48:19 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 08 Nov 2011 08:48:19 -0800 Subject: hg: build-infra/jdk7/langtools: Added more info to pub api and native api files. Modifiers to methods, In-Reply-To: <20111103165916.971744721F@hg.openjdk.java.net> References: <20111103165916.971744721F@hg.openjdk.java.net> Message-ID: <4EB95D53.4040309@oracle.com> On 11/03/2011 09:59 AM, erik.joelsson at oracle.com wrote: > Changeset: e1493aa6e122 > Author: erikj > Date: 2011-11-03 17:50 +0100 > URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/e1493aa6e122 > > Added more info to pub api and native api files. Modifiers to methods, > perhaps all are not needed, but several are. Added static final fields > to native api as these are included in header files. We will need to > find a way to filter this in make later. > > ! src/share/classes/com/sun/tools/javac/processing/ApiVisitor.java > ! src/share/classes/com/sun/tools/javac/processing/NativeapiVisitor.java > ! src/share/classes/com/sun/tools/javac/processing/PubapiVisitor.java > Erik, I don't think these belong here (eventually). javac.processing is for the implementation support for annotation processing; I don't think it should be used for client code like this. -- Jon From fredrik.ohrstrom at oracle.com Tue Nov 8 13:42:05 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 08 Nov 2011 21:42:05 +0000 Subject: hg: build-infra/jdk7: Added annotation ForceNativeHeader to trigger javah on a class. Message-ID: <20111108214205.4E17E4729B@hg.openjdk.java.net> Changeset: 7cfc8f162d58 Author: ohrstrom Date: 2011-11-08 22:49 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/7cfc8f162d58 Added annotation ForceNativeHeader to trigger javah on a class. Also fixed dependency tracking problems for native header generation. ! common/make/JavaCompilation.gmk From fredrik.ohrstrom at oracle.com Tue Nov 8 13:42:48 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 08 Nov 2011 21:42:48 +0000 Subject: hg: build-infra/jdk7/langtools: Added annotation ForceNativeHeader to trigger javah on a class. Message-ID: <20111108214254.09F494729C@hg.openjdk.java.net> Changeset: 5d684df20334 Author: ohrstrom Date: 2011-11-08 22:49 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/5d684df20334 Added annotation ForceNativeHeader to trigger javah on a class. Also fixed dependency tracking problems for native header generation. ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/processing/NativeapiVisitor.java + src/share/classes/javax/tools/ForceNativeHeader.java From fredrik.ohrstrom at oracle.com Tue Nov 8 13:43:08 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 08 Nov 2011 21:43:08 +0000 Subject: hg: build-infra/jdk7/jdk: Added annotation ForceNativeHeader to trigger javah on a class. Message-ID: <20111108214335.2C1074729D@hg.openjdk.java.net> Changeset: d3f616af43d8 Author: ohrstrom Date: 2011-11-08 22:50 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/d3f616af43d8 Added annotation ForceNativeHeader to trigger javah on a class. Also fixed dependency tracking problems for native header generation. ! src/share/classes/sun/nio/ch/IOStatus.java ! src/share/classes/sun/nio/ch/SctpStdSocketOption.java ! src/solaris/classes/sun/nio/ch/SctpAssocChange.java ! src/solaris/classes/sun/nio/ch/SctpPeerAddrChange.java ! src/solaris/classes/sun/nio/ch/SctpResultContainer.java From david.holmes at oracle.com Tue Nov 8 19:36:37 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 09 Nov 2011 13:36:37 +1000 Subject: Improved build system In-Reply-To: References: <4EB43234.8090400@oracle.com> <26962FEA-7639-433B-9BBC-B7E7D018AA2A@oracle.com> <4EB7306C.7060109@oracle.com> Message-ID: <4EB9F545.7020203@oracle.com> On 9/11/2011 2:12 AM, Georges Saab wrote: > IMO we should not assume that build machines can NFS mount source directories from dev workstations. Not that I was implying that, but to clarify the NFS mounts in question are not on the workstation but on the file servers - accessed by both the workstation and the build machine via NFS. > This is not the same thing as saying it should not be possible to take advantage of it where it is the case. And hopefully to also gain the benefits even when on NFS. David ----- > > /GES > > > On 6 nov 2011, at 17:12, David Holmes wrote: > >> On 5/11/2011 5:08 AM, Kelly O'Hair wrote: >>> >>> You would be amazed at how many people still use NFS partitions to build in. :^( >> >> Yes, but even if we build locally we _do_ still use NFS for the source tree and that is not something I expect to change. My "workstation" is a Solaris box, my build machine is whatever I'm targeting and I do not expect to have to transfer edits between my workstation and build machine (I've worked that way in the past when my workstation and build machine were on different continents, and I don't expect to have to do it when they are next to each other!) >> >> David >> >>> -kto >>> >>> On Nov 4, 2011, at 11:43 AM, Jonathan Gibbons wrote: >>> >>>> For Max's issue, I agree. But if NFS is generally discouraged, as you imply, then you should get at least a warning if you try and use it, independent of Max's response. >>>> >>>> -- Jon >>>> >>>> >>>> >>>> On 11/04/2011 11:18 AM, Fredrik ?hrstr?m wrote: >>>>>> Does the build, can the build, check for NFS, and report an error? >>>>>> >>>>>> Jon >>>>> >>>>> You are right, if it is relevant to check for NFS, then it is a test that really should be done in configure. >>>>> >>>>> But we have to wait for Weijun's answer to see if nfs is involved or not. >>>>> >>>>> //Fredrik >>>>> >>>>> ----- fredrik.ohrstrom at oracle.com skrev: >>>>> >>>>>> It is the default Ubuntu Java package. >>>>>> >>>>>> Just install the openjdk package and you will get iced tea. >>>>>> The configure script should remind you what the package name is, >>>>>> if you make sure that you have no java in the path. >>>>>> >>>>>> By the way. You do not have your source and build directory >>>>>> on NFS do you? The javacserver uses file system locking >>>>>> to establish a single server. And locking does not work >>>>>> very well over nfs. (Also building is much slower, if it works.) >>>>>> >>>>>> //Fredrik >>>>>> ----- weijun.wang at oracle.com skrev: >>>>>> >>>>>>> I don't have an IcedTea. Do I need to build one? >>>>>>> >>>>>>> -Max >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m >>>>>>> wrote: >>>>>>> >>>>>>>> Ok, could you please try just: >>>>>>>> >>>>>>>> ./configure >>>>>>>> >>>>>>>> and use the default iced-tea? >>>>>>>> >>>>>>>> //Fredrik >>>>>>>> >>>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>>> >>>>>>>>> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>>>>>>>>> Please send me the build.log file.... >>>>>>>>> Attached. >>>>>>>>> >>>>>>>>>> You can also try: >>>>>>>>>> >>>>>>>>>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >>>>>>>>> --disable-javac-deps --disable-javac-server >>>>>>>>> >>>>>>>>> This works. >>>>>>>>> >>>>>>>>> -Max >>>>>>>>> >>>>>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>>>>> >>>>>>>>>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>>>>>>>>> >>>>>>>>>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>>>>>>>>> 2. get_source.sh >>>>>>>>>>> 3. Download ccache 3.1.6 source and build it >>>>>>>>>>> 4. Download the 3 files in common/config and mv one of them >>>>>>>>>>> 5. ./configure --with-boot-jdk=$J6 >>>>>>>>>>> 6. make >>>>>>>>>>> >>>>>>>>>>> and soon see an error >>>>>>>>>>> >>>>>>>>>>> Compiling 10 files in package com/sun/source/util >>>>>>>>>>> >>>>>> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>>>>>>>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>>>>>>>>> public interface TypeVisitor { >>>>>>>>>>> ^ >>>>>>>>>>> >>>>>>>>>>> -Max >>>> >>> > From jonathan.gibbons at oracle.com Tue Nov 8 18:49:12 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 08 Nov 2011 18:49:12 -0800 Subject: Improved build system In-Reply-To: <13e0743d-b7d4-4998-9ec7-bb3edcc57561@default> References: <13e0743d-b7d4-4998-9ec7-bb3edcc57561@default> Message-ID: <4EB9EA28.7010608@oracle.com> On 09/29/2011 05:33 PM, Fredrik ?hrstr?m wrote: > The first thing you should do after you fetched the update. > > cd common/config > wgethttp://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.guess > wgethttp://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.sub > wgethttp://www.opensource.apple.com/source/libdispatch/libdispatch-187.5/m4/pkg.m4?txt > mv pkg.m4?txt pkg.m4 > > The paperwork has not yet cleared on these files, but as soon as it does, I will > commit them to the repository. > > Now run: > ./configure You need to cd ../../ before running ./configure -- Jon From jonathan.gibbons at oracle.com Tue Nov 8 19:14:01 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 08 Nov 2011 19:14:01 -0800 Subject: Improved build system In-Reply-To: <13e0743d-b7d4-4998-9ec7-bb3edcc57561@default> References: <13e0743d-b7d4-4998-9ec7-bb3edcc57561@default> Message-ID: <4EB9EFF9.7070905@oracle.com> On 09/29/2011 05:33 PM, Fredrik ?hrstr?m wrote: > It currently only builds successfully on 64bit GNU/Linux. OK, maybe you knew this, but on a 32 bit Ubuntu, the build gets most of the way through, but hangs here: > Copying wsimport > Copying orbd > Copying servertool > Copying tnameserv > Copying pack200 > Linking executable unpack200 > /w/jjg/work/build-infra-dev/jdk7/build/linux-i586-clientANDserver-release/jdk/newobjs/unpackexe/unpack.o: > In function `unpacker::redirect_stdio()': > Copying unpack200 > Compiling 1 files in package > /w/jjg/work/build-infra-dev/jdk7/build/linux-i586-clientANDserver-release/jdk/newdemo/applets/ArcTest/ > Compiling 1 files in package > /w/jjg/work/build-infra-dev/jdk7/build/linux-i586-clientANDserver-release/jdk/newdemo/applets/BarChart/ -- Jon From jonathan.gibbons at oracle.com Tue Nov 8 19:15:38 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 08 Nov 2011 19:15:38 -0800 Subject: Improved build system In-Reply-To: <4EB9EFF9.7070905@oracle.com> References: <13e0743d-b7d4-4998-9ec7-bb3edcc57561@default> <4EB9EFF9.7070905@oracle.com> Message-ID: <4EB9F05A.70104@oracle.com> On 11/08/2011 07:14 PM, Jonathan Gibbons wrote: > On 09/29/2011 05:33 PM, Fredrik ?hrstr?m wrote: >> It currently only builds successfully on 64bit GNU/Linux. > > OK, maybe you knew this, but on a 32 bit Ubuntu, the build gets most > of the way through, but hangs here: > >> Copying wsimport >> Copying orbd >> Copying servertool >> Copying tnameserv >> Copying pack200 >> Linking executable unpack200 >> /w/jjg/work/build-infra-dev/jdk7/build/linux-i586-clientANDserver-release/jdk/newobjs/unpackexe/unpack.o: >> In function `unpacker::redirect_stdio()': >> Copying unpack200 >> Compiling 1 files in package >> /w/jjg/work/build-infra-dev/jdk7/build/linux-i586-clientANDserver-release/jdk/newdemo/applets/ArcTest/ >> Compiling 1 files in package >> /w/jjg/work/build-infra-dev/jdk7/build/linux-i586-clientANDserver-release/jdk/newdemo/applets/BarChart/ > > -- Jon > After killing it and starting over, it completed the build in an additional 27 seconds. -- Jon From jonathan.gibbons at oracle.com Tue Nov 8 19:25:18 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 08 Nov 2011 19:25:18 -0800 Subject: big missing dependency Message-ID: <4EB9F29E.5050006@oracle.com> I edited javac in a way that would change the bytecodes, and reran the build. No JDK source files got recompiled, as they should have been. -- Jon From georges.saab at oracle.com Tue Nov 8 21:59:37 2011 From: georges.saab at oracle.com (Georges Saab) Date: Tue, 8 Nov 2011 21:59:37 -0800 Subject: Improved build system In-Reply-To: <4EB9F545.7020203@oracle.com> References: <4EB43234.8090400@oracle.com> <26962FEA-7639-433B-9BBC-B7E7D018AA2A@oracle.com> <4EB7306C.7060109@oracle.com> <4EB9F545.7020203@oracle.com> Message-ID: <9BF600EA-A539-4DCD-9BF4-72700F744977@oracle.com> On 8 nov 2011, at 19:36, David Holmes wrote: > On 9/11/2011 2:12 AM, Georges Saab wrote: >> IMO we should not assume that build machines can NFS mount source directories from dev workstations. > > Not that I was implying that, but to clarify the NFS mounts in question are not on the workstation but on the file servers - accessed by both the workstation and the build machine via NFS. Thanks for clarifying. In that case, let me also clarify: I don't think we should assume that the workstation and the build machine can mount directories from the same NFS servers. :) > >> This is not the same thing as saying it should not be possible to take advantage of it where it is the case. > > And hopefully to also gain the benefits even when on NFS. > > David > ----- > >> >> /GES >> >> >> On 6 nov 2011, at 17:12, David Holmes wrote: >> >>> On 5/11/2011 5:08 AM, Kelly O'Hair wrote: >>>> >>>> You would be amazed at how many people still use NFS partitions to build in. :^( >>> >>> Yes, but even if we build locally we _do_ still use NFS for the source tree and that is not something I expect to change. My "workstation" is a Solaris box, my build machine is whatever I'm targeting and I do not expect to have to transfer edits between my workstation and build machine (I've worked that way in the past when my workstation and build machine were on different continents, and I don't expect to have to do it when they are next to each other!) >>> >>> David >>> >>>> -kto >>>> >>>> On Nov 4, 2011, at 11:43 AM, Jonathan Gibbons wrote: >>>> >>>>> For Max's issue, I agree. But if NFS is generally discouraged, as you imply, then you should get at least a warning if you try and use it, independent of Max's response. >>>>> >>>>> -- Jon >>>>> >>>>> >>>>> >>>>> On 11/04/2011 11:18 AM, Fredrik ?hrstr?m wrote: >>>>>>> Does the build, can the build, check for NFS, and report an error? >>>>>>> >>>>>>> Jon >>>>>> >>>>>> You are right, if it is relevant to check for NFS, then it is a test that really should be done in configure. >>>>>> >>>>>> But we have to wait for Weijun's answer to see if nfs is involved or not. >>>>>> >>>>>> //Fredrik >>>>>> >>>>>> ----- fredrik.ohrstrom at oracle.com skrev: >>>>>> >>>>>>> It is the default Ubuntu Java package. >>>>>>> >>>>>>> Just install the openjdk package and you will get iced tea. >>>>>>> The configure script should remind you what the package name is, >>>>>>> if you make sure that you have no java in the path. >>>>>>> >>>>>>> By the way. You do not have your source and build directory >>>>>>> on NFS do you? The javacserver uses file system locking >>>>>>> to establish a single server. And locking does not work >>>>>>> very well over nfs. (Also building is much slower, if it works.) >>>>>>> >>>>>>> //Fredrik >>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>> >>>>>>>> I don't have an IcedTea. Do I need to build one? >>>>>>>> >>>>>>>> -Max >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Nov 4, 2011, at 10:26 PM, Fredrik ?hrstr?m >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Ok, could you please try just: >>>>>>>>> >>>>>>>>> ./configure >>>>>>>>> >>>>>>>>> and use the default iced-tea? >>>>>>>>> >>>>>>>>> //Fredrik >>>>>>>>> >>>>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>>>> >>>>>>>>>> On 11/04/2011 08:19 PM, Fredrik ?hrstr?m wrote: >>>>>>>>>>> Please send me the build.log file.... >>>>>>>>>> Attached. >>>>>>>>>> >>>>>>>>>>> You can also try: >>>>>>>>>>> >>>>>>>>>>> ./configure --with-boot-jdk=$J6 --disable-javac-multi-core >>>>>>>>>> --disable-javac-deps --disable-javac-server >>>>>>>>>> >>>>>>>>>> This works. >>>>>>>>>> >>>>>>>>>> -Max >>>>>>>>>> >>>>>>>>>>> ----- weijun.wang at oracle.com skrev: >>>>>>>>>>> >>>>>>>>>>>> I just tried this on my Ubuntu 11.04 64-bit system: >>>>>>>>>>>> >>>>>>>>>>>> 1. Clone http://hg.openjdk.java.net/build-infra/jdk7 >>>>>>>>>>>> 2. get_source.sh >>>>>>>>>>>> 3. Download ccache 3.1.6 source and build it >>>>>>>>>>>> 4. Download the 3 files in common/config and mv one of them >>>>>>>>>>>> 5. ./configure --with-boot-jdk=$J6 >>>>>>>>>>>> 6. make >>>>>>>>>>>> >>>>>>>>>>>> and soon see an error >>>>>>>>>>>> >>>>>>>>>>>> Compiling 10 files in package com/sun/source/util >>>>>>>>>>>> >>>>>>> /space/repos/build-infra/jdk7/langtools/src/share/classes/com/sun/mirror/util/TypeVisitor.java:52: >>>>>>>>>>>> error: duplicate class: com.sun.mirror.util.TypeVisitor >>>>>>>>>>>> public interface TypeVisitor { >>>>>>>>>>>> ^ >>>>>>>>>>>> >>>>>>>>>>>> -Max >>>>> >>>> >> From erik.joelsson at oracle.com Wed Nov 9 00:56:17 2011 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 09 Nov 2011 09:56:17 +0100 Subject: hg: build-infra/jdk7/langtools: Added more info to pub api and native api files. Modifiers to methods, In-Reply-To: <4EB95D53.4040309@oracle.com> References: <20111103165916.971744721F@hg.openjdk.java.net> <4EB95D53.4040309@oracle.com> Message-ID: <4EBA4031.2070009@oracle.com> (remember I'm Erik and not Joel now! ;) I agree with you, but for now I just followed what Fredrik already put there. In my view, this is still just prototyping, it might not work at all or it might work out great, most probably we will change it around a lot before we are satisfied. I sure expect a lot of cleanup before it's production ready anyhow. Where would you think it should reside? /Erik On 2011-11-08 17:48, Jonathan Gibbons wrote: > On 11/03/2011 09:59 AM, erik.joelsson at oracle.com wrote: >> Changeset: e1493aa6e122 >> Author: erikj >> Date: 2011-11-03 17:50 +0100 >> URL: >> http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/e1493aa6e122 >> >> Added more info to pub api and native api files. Modifiers to methods, >> perhaps all are not needed, but several are. Added static final fields >> to native api as these are included in header files. We will need to >> find a way to filter this in make later. >> >> ! src/share/classes/com/sun/tools/javac/processing/ApiVisitor.java >> ! src/share/classes/com/sun/tools/javac/processing/NativeapiVisitor.java >> ! src/share/classes/com/sun/tools/javac/processing/PubapiVisitor.java >> > > Erik, > > I don't think these belong here (eventually). javac.processing is > for the implementation support for annotation processing; I don't > think it should be used for client code like this. > > -- Jon From fredrik.ohrstrom at oracle.com Wed Nov 9 01:20:28 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 09 Nov 2011 10:20:28 +0100 Subject: Improved build system In-Reply-To: <20111109022009.GG25917@rivendell.middle-earth.co.uk> References: <20111109022009.GG25917@rivendell.middle-earth.co.uk> Message-ID: <4EBA45DC.7020608@oracle.com> 2011-11-09 03:20, Dr Andrew John Hughes skrev: > That sounds like a regression to me. Is there a plan to fix this? > All my source trees are on NFS and I have no plans to move them. NFS is not involved in Max build problem it could be that it just works on NFS. Since NFS is important to you, perhaps you could give it a try and test the build? source = local disk build artifacts = local disk source = nfs build artifacts = local disk source = nfs build artifacts = nfs If NFS is a problem, then I will simply move the locking file to /tmp. Trivial. //Fredrik From fredrik.ohrstrom at oracle.com Wed Nov 9 02:22:28 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Wed, 09 Nov 2011 10:22:28 +0000 Subject: hg: build-infra/jdk7: Made sure a single threaded batch compile also find files with the ForceNativeHeader annotation. Message-ID: <20111109102228.5E5E1472A7@hg.openjdk.java.net> Changeset: fd522294cfd7 Author: ohrstrom Date: 2011-11-09 11:22 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/fd522294cfd7 Made sure a single threaded batch compile also find files with the ForceNativeHeader annotation. ! common/make/JavaCompilation.gmk From fredrik.ohrstrom at oracle.com Wed Nov 9 03:48:32 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 09 Nov 2011 12:48:32 +0100 Subject: big missing dependency Message-ID: <4EBA6890.3050007@oracle.com> 2011/11/9 Jonathan Gibbons : > I edited javac in a way that would change the bytecodes, and reran the > build. No JDK source files got recompiled, as they should have been. It would be a truly awesome build system that could deduce that, your newly compiled javac creates bytecodes that differ from the old ones, and only then trigger a recompile of corba/jaxp/jaxws/hotspot/jdk. (I heard that GNU make 4.2, will have an AI, so we just need to wait.) In the meantime, we could always trigger a rebuild of all the other repoes, if the langtools repo is changed, even a tiny bit. This would make us err on the safe side. But it would be inconvenient. I think, we have to rely on ourselves (when we are developing javac) to realize that, it is time to do "make clean && make" But there are three more big dependencies missing, that are possible to deal with. If you add a public method to java.lang.Object, then none of corba/jaxp/jaxws are recompiled, and they should be. Partially this is a result of the current repository structure. With Jigsaw, it will all be solved, right? //Fredrik From jonathan.gibbons at oracle.com Wed Nov 9 07:10:14 2011 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 09 Nov 2011 07:10:14 -0800 Subject: big missing dependency In-Reply-To: <4EBA6890.3050007@oracle.com> References: <4EBA6890.3050007@oracle.com> Message-ID: <4EBA97D6.7070804@oracle.com> On 11/09/2011 03:48 AM, Fredrik ?hrstr?m wrote: > It would be a truly awesome build system that could deduce that, > your newly compiled javac creates bytecodes that differ from the old ones, I thought you were shooting for "truly awesome" :-) You're already at "awesome". I would assume that if any javac classes have changed, then all downstream compilations need to be redone. Conceptually, that means that all downstream compilations should depend on something like build/bootstrap/lib/javac.jar. -- Jon From erik.joelsson at oracle.com Wed Nov 9 08:46:49 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 09 Nov 2011 16:46:49 +0000 Subject: hg: build-infra/jdk7: 3 new changesets Message-ID: <20111109164649.CD351472AC@hg.openjdk.java.net> Changeset: c46b4f913631 Author: erikj Date: 2011-11-09 14:38 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/c46b4f913631 Adding RMICompilation.gmk to handle rmic with as good dependency checking as possible. + common/make/RMICompile.gmk Changeset: a3b791409b75 Author: erikj Date: 2011-11-09 14:42 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/a3b791409b75 merge Changeset: 6ef532a95bb7 Author: erikj Date: 2011-11-09 16:49 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/6ef532a95bb7 Fixes in RMICompile. ! common/make/RMICompile.gmk From erik.joelsson at oracle.com Wed Nov 9 08:47:39 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 09 Nov 2011 16:47:39 +0000 Subject: hg: build-infra/jdk7/jdk: 3 new changesets Message-ID: <20111109164818.793AE472AD@hg.openjdk.java.net> Changeset: 394d016602c5 Author: erikj Date: 2011-11-09 14:39 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/394d016602c5 Converted sun/rmi/registry, rmi and rmid. Redid GenerateClasses to use new rmic macro from common. ! make/CompileLaunchers.gmk ! make/CompileNativeLibraries.gmk ! make/GenerateClasses.gmk ! make/GensrcProperties.gmk ! make/sun/rmi/Makefile - make/sun/rmi/registry/Makefile - make/sun/rmi/rmi/Makefile - make/sun/rmi/rmid/Makefile Changeset: b38392d10fa3 Author: erikj Date: 2011-11-09 14:42 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/b38392d10fa3 merge Changeset: 2f706d236bef Author: erikj Date: 2011-11-09 16:49 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/2f706d236bef Fixed generation of source files for certain stub classes to have proper dependencies. ! make/GenerateClasses.gmk From erik.joelsson at oracle.com Wed Nov 9 09:58:24 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 09 Nov 2011 17:58:24 +0000 Subject: hg: build-infra/jdk7/jdk: Converted oldtools. Message-ID: <20111109175857.1D7B7472AE@hg.openjdk.java.net> Changeset: f9bbbf64e0b0 Author: erikj Date: 2011-11-09 18:57 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/f9bbbf64e0b0 Converted oldtools. ! make/GensrcProperties.gmk ! make/sun/rmi/Makefile - make/sun/rmi/oldtools/FILES_java.gmk - make/sun/rmi/oldtools/Makefile From robert.ottenhag at oracle.com Thu Nov 10 03:27:40 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:27:40 +0000 Subject: hg: build-infra/jdk7: Disable jcheck Message-ID: <20111110112740.F11B6472C6@hg.openjdk.java.net> Changeset: f0fb16984aeb Author: rottenha Date: 2011-11-10 12:19 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/f0fb16984aeb Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:27:51 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:27:51 +0000 Subject: hg: build-infra/jdk7/corba: Disable jcheck Message-ID: <20111110112752.97C4A472C7@hg.openjdk.java.net> Changeset: 91ccaa55fb78 Author: rottenha Date: 2011-11-10 12:19 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/corba/rev/91ccaa55fb78 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:28:03 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:28:03 +0000 Subject: hg: build-infra/jdk7/hotspot: Disable jcheck Message-ID: <20111110112807.B0BBF472C8@hg.openjdk.java.net> Changeset: 52c4a1ae6adc Author: rottenha Date: 2011-11-10 12:19 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/hotspot/rev/52c4a1ae6adc Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:28:18 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:28:18 +0000 Subject: hg: build-infra/jdk7/jaxp: Disable jcheck Message-ID: <20111110112821.AA480472C9@hg.openjdk.java.net> Changeset: 8ba16f929245 Author: rottenha Date: 2011-11-10 12:19 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jaxp/rev/8ba16f929245 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:28:32 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:28:32 +0000 Subject: hg: build-infra/jdk7/jaxws: Disable jcheck Message-ID: <20111110112835.E9DC8472CA@hg.openjdk.java.net> Changeset: c55e074767c0 Author: rottenha Date: 2011-11-10 12:19 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jaxws/rev/c55e074767c0 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:28:47 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:28:47 +0000 Subject: hg: build-infra/jdk7/jdk: Disable jcheck Message-ID: <20111110112908.3F7AD472CB@hg.openjdk.java.net> Changeset: f0a89847a5b6 Author: rottenha Date: 2011-11-10 12:19 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/f0a89847a5b6 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:29:19 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:29:19 +0000 Subject: hg: build-infra/jdk7/langtools: Disable jcheck Message-ID: <20111110112923.06491472CC@hg.openjdk.java.net> Changeset: 0d93f5a799c5 Author: rottenha Date: 2011-11-10 12:19 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/0d93f5a799c5 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:52:16 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:52:16 +0000 Subject: hg: build-infra/jdk7-extra: Disable jcheck Message-ID: <20111110115217.0024D472CD@hg.openjdk.java.net> Changeset: 129d8885524e Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-extra/rev/129d8885524e Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:52:23 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:52:23 +0000 Subject: hg: build-infra/jdk7-modules: Disable jcheck Message-ID: <20111110115223.2D46C472CE@hg.openjdk.java.net> Changeset: 1a9f4de58c14 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-modules/rev/1a9f4de58c14 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:52:27 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:52:27 +0000 Subject: hg: build-infra/jdk7-extra/corba: Disable jcheck Message-ID: <20111110115230.0FC02472CF@hg.openjdk.java.net> Changeset: ae9a7d18af4f Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-extra/corba/rev/ae9a7d18af4f Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:52:33 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:52:33 +0000 Subject: hg: build-infra/jdk8: Disable jcheck Message-ID: <20111110115233.25FD7472D0@hg.openjdk.java.net> Changeset: de4d2da7625c Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/rev/de4d2da7625c Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:52:39 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:52:39 +0000 Subject: hg: build-infra/jdk7-modules/corba: Disable jcheck Message-ID: <20111110115240.B9A24472D1@hg.openjdk.java.net> Changeset: 7a6377741a63 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-modules/corba/rev/7a6377741a63 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:52:43 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:52:43 +0000 Subject: hg: build-infra/jdk7-extra/hotspot: Disable jcheck Message-ID: <20111110115249.14859472D2@hg.openjdk.java.net> Changeset: 86926ee9317c Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-extra/hotspot/rev/86926ee9317c Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:52:49 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:52:49 +0000 Subject: hg: build-infra/jdk8/corba: Disable jcheck Message-ID: <20111110115250.9DB59472D3@hg.openjdk.java.net> Changeset: 908aa7895887 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/corba/rev/908aa7895887 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:52:52 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:52:52 +0000 Subject: hg: build-infra/jdk7-modules/hotspot: Disable jcheck Message-ID: <20111110115257.E8085472D4@hg.openjdk.java.net> Changeset: 77c0f609f1bc Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-modules/hotspot/rev/77c0f609f1bc Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:00 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:00 +0000 Subject: hg: build-infra/jdk7-extra/jaxp: Disable jcheck Message-ID: <20111110115300.6753C472D5@hg.openjdk.java.net> Changeset: 7abafbfe69b3 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-extra/jaxp/rev/7abafbfe69b3 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:10 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:10 +0000 Subject: hg: build-infra/jdk7-modules/jaxp: Disable jcheck Message-ID: <20111110115310.A6E49472D6@hg.openjdk.java.net> Changeset: 14d9d7b7f1d8 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-modules/jaxp/rev/14d9d7b7f1d8 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:06 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:06 +0000 Subject: hg: build-infra/jdk8/hotspot: Disable jcheck Message-ID: <20111110115311.A7733472D7@hg.openjdk.java.net> Changeset: b1b05e1e0140 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/hotspot/rev/b1b05e1e0140 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:17 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:17 +0000 Subject: hg: build-infra/jdk7-extra/jaxws: Disable jcheck Message-ID: <20111110115317.A2CD1472D8@hg.openjdk.java.net> Changeset: 7e002cac4952 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-extra/jaxws/rev/7e002cac4952 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:22 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:22 +0000 Subject: hg: build-infra/jdk7-modules/jaxws: Disable jcheck Message-ID: <20111110115322.64642472D9@hg.openjdk.java.net> Changeset: 0637d95d4e09 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-modules/jaxws/rev/0637d95d4e09 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:26 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:26 +0000 Subject: hg: build-infra/jdk8/jaxp: Disable jcheck Message-ID: <20111110115326.B3895472DA@hg.openjdk.java.net> Changeset: ad9fe1502624 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jaxp/rev/ad9fe1502624 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:42 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:42 +0000 Subject: hg: build-infra/jdk8/jaxws: Disable jcheck Message-ID: <20111110115342.291FB472DB@hg.openjdk.java.net> Changeset: 1ae105404eaa Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jaxws/rev/1ae105404eaa Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:32 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:32 +0000 Subject: hg: build-infra/jdk7-extra/jdk: Disable jcheck Message-ID: <20111110115350.1C094472DC@hg.openjdk.java.net> Changeset: f509d8db3484 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-extra/jdk/rev/f509d8db3484 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:38 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:38 +0000 Subject: hg: build-infra/jdk7-modules/jdk: Disable jcheck Message-ID: <20111110115352.B5DF5472DD@hg.openjdk.java.net> Changeset: ea2549112801 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-modules/jdk/rev/ea2549112801 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:54:02 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:54:02 +0000 Subject: hg: build-infra/jdk7-extra/langtools: Disable jcheck Message-ID: <20111110115405.44E85472DE@hg.openjdk.java.net> Changeset: 8f019c41dad6 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-extra/langtools/rev/8f019c41dad6 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:54:07 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:54:07 +0000 Subject: hg: build-infra/jdk7-modules/langtools: Disable jcheck Message-ID: <20111110115410.14F3E472DF@hg.openjdk.java.net> Changeset: 0542f2135ee3 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7-modules/langtools/rev/0542f2135ee3 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:53:54 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:53:54 +0000 Subject: hg: build-infra/jdk8/jdk: Disable jcheck Message-ID: <20111110115411.78031472E0@hg.openjdk.java.net> Changeset: 315d73190f18 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/jdk/rev/315d73190f18 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 03:54:22 2011 From: robert.ottenhag at oracle.com (robert.ottenhag at oracle.com) Date: Thu, 10 Nov 2011 11:54:22 +0000 Subject: hg: build-infra/jdk8/langtools: Disable jcheck Message-ID: <20111110115424.E5A41472E1@hg.openjdk.java.net> Changeset: e7f9fd853b53 Author: rottenha Date: 2011-11-10 12:51 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk8/langtools/rev/e7f9fd853b53 Disable jcheck - .jcheck/conf From robert.ottenhag at oracle.com Thu Nov 10 04:31:52 2011 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Thu, 10 Nov 2011 13:31:52 +0100 Subject: Disabled jcheck in all build-infra repos Message-ID: <4EBBC438.1030308@oracle.com> Hi, I have now explicitly disabled jcheck for all build-infra repos since some of the recent changes in build-infra/jdk7 made jcheck fail when trying to pull and update. The disabling was done on the server by removing the directory ".jcheck" in the root of each repository, as specified in the jcheck.py header documentation. Alternative solutions such as disabling it locally in each $repo/.hg/hgrc file (overriding jcheck=...) or the global ~/.hgrc file where considered but rejected. The former needs to applied for each cloned build-infra repo, and the latter will also disable jcheck for any other standard Open or Closed JDK repo that actually requires it. Also note that jcheck was never intended to be run on the build-infra repos in the first place, allowing free form commits and rapid development without bug IDs, as the changes are never intended to be directly committed upstream, but selectively ported. The fix was separately reapplied to all build-infra repos (no, it was not merged...), including build-infra/{jdk7, jdk7-extra, jdk7-modules, jdk8}. Thanks /Robert -- Oracle Robert Ottenhag | Senior Member of Technical Staff Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 Oracle Java HotSpot Virtual Machine ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- From fredrik.ohrstrom at oracle.com Thu Nov 10 06:02:39 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 10 Nov 2011 14:02:39 +0000 Subject: hg: build-infra/jdk7/langtools: 3 new changesets Message-ID: <20111110140247.9571B472E9@hg.openjdk.java.net> Changeset: b6364306a813 Author: ohrstrom Date: 2011-11-10 14:38 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/b6364306a813 Cleanup whitespace in langtools. ! src/share/classes/com/sun/tools/javac/Main.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/file/JavacFileManager.java ! src/share/classes/com/sun/tools/javac/jvm/ClassReader.java ! src/share/classes/com/sun/tools/javac/jvm/ClassWriter.java ! src/share/classes/com/sun/tools/javac/main/Main.java ! src/share/classes/com/sun/tools/javac/util/Log.java Changeset: a73ade325b2b Author: ohrstrom Date: 2011-11-10 14:46 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/a73ade325b2b Restore getInfo to info. ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javac/comp/Env.java Changeset: b052d8d110e8 Author: ohrstrom Date: 2011-11-10 15:02 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/b052d8d110e8 Cleanup more whitespace differences. Restore protected status on some variables. ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java From kelly.ohair at oracle.com Thu Nov 10 06:07:15 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 10 Nov 2011 09:07:15 -0500 Subject: Disabled jcheck in all build-infra repos In-Reply-To: <4EBBC438.1030308@oracle.com> References: <4EBBC438.1030308@oracle.com> Message-ID: Thanks for doing this. The server side was supposed to disable jcheck for these repos. Did you check with John Coomes? Or have you been given a set of golden keys to the Mercurial server area? ;^) -kto On Nov 10, 2011, at 7:31 AM, Robert Ottenhag wrote: > Hi, > > I have now explicitly disabled jcheck for all build-infra repos since some of the recent changes in build-infra/jdk7 made jcheck fail when trying to pull and update. The disabling was done on the server by removing the directory ".jcheck" in the root of each repository, as specified in the jcheck.py header documentation. > > Alternative solutions such as disabling it locally in each $repo/.hg/hgrc file (overriding jcheck=...) or the global ~/.hgrc file where considered but rejected. The former needs to applied for each cloned build-infra repo, and the latter will also disable jcheck for any other standard Open or Closed JDK repo that actually requires it. > > Also note that jcheck was never intended to be run on the build-infra repos in the first place, allowing free form commits and rapid development without bug IDs, as the changes are never intended to be directly committed upstream, but selectively ported. > > The fix was separately reapplied to all build-infra repos (no, it was not merged...), including build-infra/{jdk7, jdk7-extra, jdk7-modules, jdk8}. > > Thanks > > /Robert > > -- > Oracle > Robert Ottenhag | Senior Member of Technical Staff > Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 > Oracle Java HotSpot Virtual Machine > ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm > > Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 > > Green Oracle > > Oracle is committed to developing practices and products that help protect the environment > -- > > From fredrik.ohrstrom at oracle.com Thu Nov 10 06:10:44 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 10 Nov 2011 14:10:44 +0000 Subject: hg: build-infra/jdk7/langtools: Removed unnecessary option declarations. Message-ID: <20111110141046.1A3CD472EA@hg.openjdk.java.net> Changeset: 9aa80132c5cd Author: ohrstrom Date: 2011-11-10 15:10 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/9aa80132c5cd Removed unnecessary option declarations. ! src/share/classes/com/sun/tools/javac/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java From erik.joelsson at oracle.com Thu Nov 10 07:14:58 2011 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Nov 2011 16:14:58 +0100 Subject: java-rmi.exe/cgi Message-ID: <4EBBEA72.602@oracle.com> Sometimes when converting makefiles in the jdk repo, I stumble over things that don't look right. The code seem to suggest one intention, but careful inspection reveals a different behavior. Normally I try to copy the actual behavior and put a note in the new make file about it. Now I discovered something that's just too weird: In "jdk/make/sun/rmi/cgi/Makefile" the program "java-rmi.exe" is built. This looks like it's intended to be a windows native version of the "java-rmi.cgi" script that is available on linux and solaris. The makefile even copies java-rmi.exe to java-rmi.cgi. When creating the j2sdk/jre images, however, only the exe version is included. I verified this in the promoted builds of jdk 7 (b148 and a few others). The makefile also tries to declare that the program be compiled from "jdk/src/windows/bin/java-rmi.c" (by declaring FILES_c variable) but Program.gmk ignores this and just builds main.c (the standard java launcher) instead. So the "java-rmi.exe" in a windows distribution is just java.exe with a weird name. What is this script/program used for, is it used at all, and how should I convert the building of it? I have tried compiling java-rmi.c and it seems to be working at least. (Gives same default output as the script on linux) /Erik From kelly.ohair at oracle.com Thu Nov 10 07:21:14 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 10 Nov 2011 10:21:14 -0500 Subject: java-rmi.exe/cgi In-Reply-To: <4EBBEA72.602@oracle.com> References: <4EBBEA72.602@oracle.com> Message-ID: <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 My gut feeling is that we fix it, and then add this file to an exclusion list when we get to the point of comparing built jdk images. But I'm willing to accept other suggestions. -kto On Nov 10, 2011, at 10:14 AM, Erik Joelsson wrote: > Sometimes when converting makefiles in the jdk repo, I stumble over things that don't look right. The code seem to suggest one intention, but careful inspection reveals a different behavior. Normally I try to copy the actual behavior and put a note in the new make file about it. Now I discovered something that's just too weird: > > In "jdk/make/sun/rmi/cgi/Makefile" the program "java-rmi.exe" is built. This looks like it's intended to be a windows native version of the "java-rmi.cgi" script that is available on linux and solaris. The makefile even copies java-rmi.exe to java-rmi.cgi. When creating the j2sdk/jre images, however, only the exe version is included. I verified this in the promoted builds of jdk 7 (b148 and a few others). The makefile also tries to declare that the program be compiled from "jdk/src/windows/bin/java-rmi.c" (by declaring FILES_c variable) but Program.gmk ignores this and just builds main.c (the standard java launcher) instead. So the "java-rmi.exe" in a windows distribution is just java.exe with a weird name. > > What is this script/program used for, is it used at all, and how should I convert the building of it? I have tried compiling java-rmi.c and it seems to be working at least. (Gives same default output as the script on linux) > > /Erik From erik.joelsson at oracle.com Thu Nov 10 07:27:10 2011 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Nov 2011 16:27:10 +0100 Subject: java-rmi.exe/cgi In-Reply-To: <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> References: <4EBBEA72.602@oracle.com> <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> Message-ID: <4EBBED4E.6030009@oracle.com> Ah, thanks! The bug evaluation says that this shouldn't be built at all. For the sake of faster builds, not building unnecessary stuff is the best way of improving speed. I vote for delete. /Erik On 2011-11-10 16:21, Kelly O'Hair wrote: > See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 > > My gut feeling is that we fix it, and then add this file to an exclusion list when we get to the point of > comparing built jdk images. > But I'm willing to accept other suggestions. > > -kto > > On Nov 10, 2011, at 10:14 AM, Erik Joelsson wrote: > >> Sometimes when converting makefiles in the jdk repo, I stumble over things that don't look right. The code seem to suggest one intention, but careful inspection reveals a different behavior. Normally I try to copy the actual behavior and put a note in the new make file about it. Now I discovered something that's just too weird: >> >> In "jdk/make/sun/rmi/cgi/Makefile" the program "java-rmi.exe" is built. This looks like it's intended to be a windows native version of the "java-rmi.cgi" script that is available on linux and solaris. The makefile even copies java-rmi.exe to java-rmi.cgi. When creating the j2sdk/jre images, however, only the exe version is included. I verified this in the promoted builds of jdk 7 (b148 and a few others). The makefile also tries to declare that the program be compiled from "jdk/src/windows/bin/java-rmi.c" (by declaring FILES_c variable) but Program.gmk ignores this and just builds main.c (the standard java launcher) instead. So the "java-rmi.exe" in a windows distribution is just java.exe with a weird name. >> >> What is this script/program used for, is it used at all, and how should I convert the building of it? I have tried compiling java-rmi.c and it seems to be working at least. (Gives same default output as the script on linux) >> >> /Erik From kelly.ohair at oracle.com Thu Nov 10 07:40:17 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 10 Nov 2011 10:40:17 -0500 Subject: java-rmi.exe/cgi In-Reply-To: <4EBBED4E.6030009@oracle.com> References: <4EBBEA72.602@oracle.com> <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> <4EBBED4E.6030009@oracle.com> Message-ID: <3B052BEB-3C1F-4B97-B32E-632881EC58E1@oracle.com> You have my vote too. However, if we are removing something, we will eventually need a bug report and file a CCC for it (http://ccc.us.oracle.com) CCC is used whenever we do anything to the product that a customer might be surprised by, like deleting files or removing apis etc. Of course CCC might go away when the Sun LDAP goes away, not sure... We could wait to see what happens to CCC. ;^) -kto On Nov 10, 2011, at 10:27 AM, Erik Joelsson wrote: > Ah, thanks! The bug evaluation says that this shouldn't be built at all. For the sake of faster builds, not building unnecessary stuff is the best way of improving speed. I vote for delete. > > /Erik > > On 2011-11-10 16:21, Kelly O'Hair wrote: >> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 >> >> My gut feeling is that we fix it, and then add this file to an exclusion list when we get to the point of >> comparing built jdk images. >> But I'm willing to accept other suggestions. >> >> -kto >> >> On Nov 10, 2011, at 10:14 AM, Erik Joelsson wrote: >> >>> Sometimes when converting makefiles in the jdk repo, I stumble over things that don't look right. The code seem to suggest one intention, but careful inspection reveals a different behavior. Normally I try to copy the actual behavior and put a note in the new make file about it. Now I discovered something that's just too weird: >>> >>> In "jdk/make/sun/rmi/cgi/Makefile" the program "java-rmi.exe" is built. This looks like it's intended to be a windows native version of the "java-rmi.cgi" script that is available on linux and solaris. The makefile even copies java-rmi.exe to java-rmi.cgi. When creating the j2sdk/jre images, however, only the exe version is included. I verified this in the promoted builds of jdk 7 (b148 and a few others). The makefile also tries to declare that the program be compiled from "jdk/src/windows/bin/java-rmi.c" (by declaring FILES_c variable) but Program.gmk ignores this and just builds main.c (the standard java launcher) instead. So the "java-rmi.exe" in a windows distribution is just java.exe with a weird name. >>> >>> What is this script/program used for, is it used at all, and how should I convert the building of it? I have tried compiling java-rmi.c and it seems to be working at least. (Gives same default output as the script on linux) >>> >>> /Erik From kelly.ohair at oracle.com Thu Nov 10 07:46:37 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 10 Nov 2011 10:46:37 -0500 Subject: java-rmi.exe/cgi In-Reply-To: <3B052BEB-3C1F-4B97-B32E-632881EC58E1@oracle.com> References: <4EBBEA72.602@oracle.com> <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> <4EBBED4E.6030009@oracle.com> <3B052BEB-3C1F-4B97-B32E-632881EC58E1@oracle.com> Message-ID: <04FAEAF9-3BF0-4082-B7C2-E473ED53F215@oracle.com> Actually,, I suspect we may have many of these CCC type issues, we could just gather them up and do one CCC, when we get closer to integrating the changes. So I still vote for delete, but we need to track these things. -kto On Nov 10, 2011, at 10:40 AM, Kelly O'Hair wrote: > You have my vote too. > > However, if we are removing something, we will eventually need a bug report and file a CCC for it (http://ccc.us.oracle.com) > CCC is used whenever we do anything to the product that a customer might be surprised by, like deleting files or > removing apis etc. > > Of course CCC might go away when the Sun LDAP goes away, not sure... We could wait to see what happens to CCC. ;^) > > -kto > > On Nov 10, 2011, at 10:27 AM, Erik Joelsson wrote: > >> Ah, thanks! The bug evaluation says that this shouldn't be built at all. For the sake of faster builds, not building unnecessary stuff is the best way of improving speed. I vote for delete. >> >> /Erik >> >> On 2011-11-10 16:21, Kelly O'Hair wrote: >>> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 >>> >>> My gut feeling is that we fix it, and then add this file to an exclusion list when we get to the point of >>> comparing built jdk images. >>> But I'm willing to accept other suggestions. >>> >>> -kto >>> >>> On Nov 10, 2011, at 10:14 AM, Erik Joelsson wrote: >>> >>>> Sometimes when converting makefiles in the jdk repo, I stumble over things that don't look right. The code seem to suggest one intention, but careful inspection reveals a different behavior. Normally I try to copy the actual behavior and put a note in the new make file about it. Now I discovered something that's just too weird: >>>> >>>> In "jdk/make/sun/rmi/cgi/Makefile" the program "java-rmi.exe" is built. This looks like it's intended to be a windows native version of the "java-rmi.cgi" script that is available on linux and solaris. The makefile even copies java-rmi.exe to java-rmi.cgi. When creating the j2sdk/jre images, however, only the exe version is included. I verified this in the promoted builds of jdk 7 (b148 and a few others). The makefile also tries to declare that the program be compiled from "jdk/src/windows/bin/java-rmi.c" (by declaring FILES_c variable) but Program.gmk ignores this and just builds main.c (the standard java launcher) instead. So the "java-rmi.exe" in a windows distribution is just java.exe with a weird name. >>>> >>>> What is this script/program used for, is it used at all, and how should I convert the building of it? I have tried compiling java-rmi.c and it seems to be working at least. (Gives same default output as the script on linux) >>>> >>>> /Erik > From erik.joelsson at oracle.com Thu Nov 10 08:09:22 2011 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Nov 2011 17:09:22 +0100 Subject: java-rmi.exe/cgi In-Reply-To: <04FAEAF9-3BF0-4082-B7C2-E473ED53F215@oracle.com> References: <4EBBEA72.602@oracle.com> <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> <4EBBED4E.6030009@oracle.com> <3B052BEB-3C1F-4B97-B32E-632881EC58E1@oracle.com> <04FAEAF9-3BF0-4082-B7C2-E473ED53F215@oracle.com> Message-ID: <4EBBF732.3010606@oracle.com> What I don't understand is, when java-rmi.cgi was removed java 1.2, why leave the source and build file for it? They just stopped bundling it in the images? /Erik On 2011-11-10 16:46, Kelly O'Hair wrote: > Actually,, I suspect we may have many of these CCC type issues, we could just gather them up and > do one CCC, when we get closer to integrating the changes. > So I still vote for delete, but we need to track these things. > > -kto > > On Nov 10, 2011, at 10:40 AM, Kelly O'Hair wrote: > >> You have my vote too. >> >> However, if we are removing something, we will eventually need a bug report and file a CCC for it (http://ccc.us.oracle.com) >> CCC is used whenever we do anything to the product that a customer might be surprised by, like deleting files or >> removing apis etc. >> >> Of course CCC might go away when the Sun LDAP goes away, not sure... We could wait to see what happens to CCC. ;^) >> >> -kto >> >> On Nov 10, 2011, at 10:27 AM, Erik Joelsson wrote: >> >>> Ah, thanks! The bug evaluation says that this shouldn't be built at all. For the sake of faster builds, not building unnecessary stuff is the best way of improving speed. I vote for delete. >>> >>> /Erik >>> >>> On 2011-11-10 16:21, Kelly O'Hair wrote: >>>> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 >>>> >>>> My gut feeling is that we fix it, and then add this file to an exclusion list when we get to the point of >>>> comparing built jdk images. >>>> But I'm willing to accept other suggestions. >>>> >>>> -kto >>>> >>>> On Nov 10, 2011, at 10:14 AM, Erik Joelsson wrote: >>>> >>>>> Sometimes when converting makefiles in the jdk repo, I stumble over things that don't look right. The code seem to suggest one intention, but careful inspection reveals a different behavior. Normally I try to copy the actual behavior and put a note in the new make file about it. Now I discovered something that's just too weird: >>>>> >>>>> In "jdk/make/sun/rmi/cgi/Makefile" the program "java-rmi.exe" is built. This looks like it's intended to be a windows native version of the "java-rmi.cgi" script that is available on linux and solaris. The makefile even copies java-rmi.exe to java-rmi.cgi. When creating the j2sdk/jre images, however, only the exe version is included. I verified this in the promoted builds of jdk 7 (b148 and a few others). The makefile also tries to declare that the program be compiled from "jdk/src/windows/bin/java-rmi.c" (by declaring FILES_c variable) but Program.gmk ignores this and just builds main.c (the standard java launcher) instead. So the "java-rmi.exe" in a windows distribution is just java.exe with a weird name. >>>>> >>>>> What is this script/program used for, is it used at all, and how should I convert the building of it? I have tried compiling java-rmi.c and it seems to be working at least. (Gives same default output as the script on linux) >>>>> >>>>> /Erik From robert.ottenhag at oracle.com Thu Nov 10 08:15:15 2011 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Thu, 10 Nov 2011 17:15:15 +0100 Subject: Disabled jcheck in all build-infra repos In-Reply-To: References: <4EBBC438.1030308@oracle.com> Message-ID: <4EBBF893.6040408@oracle.com> Kelly, My vocabulary is somewhat misleading regarding "server side" here. I meant that I committed the change to the repositories locally on my machine as usual and then pushed it to the openjdk server using fpush, e.g. http://hg.openjdk.java.net/build-infra/jdk7/rev/f0fb16984aeb. I do not have any direct access to the openjdk server whatsoever ;-) Whatever the server side does with jcheck on commits is surely handled by John C. only. /Robert On 11/10/2011 03:07 PM, Kelly O'Hair wrote: > Thanks for doing this. The server side was supposed to disable jcheck for these repos. > > Did you check with John Coomes? Or have you been given a set of golden keys to the Mercurial server area? ;^) > > -kto > > On Nov 10, 2011, at 7:31 AM, Robert Ottenhag wrote: > >> Hi, >> >> I have now explicitly disabled jcheck for all build-infra repos since some of the recent changes in build-infra/jdk7 made jcheck fail when trying to pull and update. The disabling was done on the server by removing the directory ".jcheck" in the root of each repository, as specified in the jcheck.py header documentation. >> >> Alternative solutions such as disabling it locally in each $repo/.hg/hgrc file (overriding jcheck=...) or the global ~/.hgrc file where considered but rejected. The former needs to applied for each cloned build-infra repo, and the latter will also disable jcheck for any other standard Open or Closed JDK repo that actually requires it. >> >> Also note that jcheck was never intended to be run on the build-infra repos in the first place, allowing free form commits and rapid development without bug IDs, as the changes are never intended to be directly committed upstream, but selectively ported. >> >> The fix was separately reapplied to all build-infra repos (no, it was not merged...), including build-infra/{jdk7, jdk7-extra, jdk7-modules, jdk8}. >> >> Thanks >> >> /Robert >> >> -- >> Oracle >> Robert Ottenhag | Senior Member of Technical Staff >> Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 >> Oracle Java HotSpot Virtual Machine >> ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm >> >> Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 >> >> Green Oracle >> >> Oracle is committed to developing practices and products that help protect the environment >> -- >> >> -- Oracle Robert Ottenhag | Senior Member of Technical Staff Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 Oracle Java HotSpot Virtual Machine ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- From robert.ottenhag at oracle.com Thu Nov 10 08:21:06 2011 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Thu, 10 Nov 2011 17:21:06 +0100 Subject: java-rmi.exe/cgi In-Reply-To: <4EBBF732.3010606@oracle.com> References: <4EBBEA72.602@oracle.com> <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> <4EBBED4E.6030009@oracle.com> <3B052BEB-3C1F-4B97-B32E-632881EC58E1@oracle.com> <04FAEAF9-3BF0-4082-B7C2-E473ED53F215@oracle.com> <4EBBF732.3010606@oracle.com> Message-ID: <4EBBF9F2.9020403@oracle.com> This bug is mine actually. I submitted it to Sun back when analyzing the JDK 6 build system for the JRockit JDK 6 port. My personal recommendation is that the removal should be done in Open JDK 8 (and 7uX), and that the build-infra project should not remove it on it's own, especially since the build-infra project does not do bug tracking. I will take ownership of that bug and get it fixed. /Robert On 11/10/2011 05:09 PM, Erik Joelsson wrote: > What I don't understand is, when java-rmi.cgi was removed java 1.2, > why leave the source and build file for it? They just stopped bundling > it in the images? > > /Erik > > On 2011-11-10 16:46, Kelly O'Hair wrote: >> Actually,, I suspect we may have many of these CCC type issues, we >> could just gather them up and >> do one CCC, when we get closer to integrating the changes. >> So I still vote for delete, but we need to track these things. >> >> -kto >> >> On Nov 10, 2011, at 10:40 AM, Kelly O'Hair wrote: >> >>> You have my vote too. >>> >>> However, if we are removing something, we will eventually need a bug >>> report and file a CCC for it (http://ccc.us.oracle.com) >>> CCC is used whenever we do anything to the product that a customer >>> might be surprised by, like deleting files or >>> removing apis etc. >>> >>> Of course CCC might go away when the Sun LDAP goes away, not >>> sure... We could wait to see what happens to CCC. ;^) >>> >>> -kto >>> >>> On Nov 10, 2011, at 10:27 AM, Erik Joelsson wrote: >>> >>>> Ah, thanks! The bug evaluation says that this shouldn't be built at >>>> all. For the sake of faster builds, not building unnecessary stuff >>>> is the best way of improving speed. I vote for delete. >>>> >>>> /Erik >>>> >>>> On 2011-11-10 16:21, Kelly O'Hair wrote: >>>>> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 >>>>> >>>>> My gut feeling is that we fix it, and then add this file to an >>>>> exclusion list when we get to the point of >>>>> comparing built jdk images. >>>>> But I'm willing to accept other suggestions. >>>>> >>>>> -kto >>>>> >>>>> On Nov 10, 2011, at 10:14 AM, Erik Joelsson wrote: >>>>> >>>>>> Sometimes when converting makefiles in the jdk repo, I stumble >>>>>> over things that don't look right. The code seem to suggest one >>>>>> intention, but careful inspection reveals a different behavior. >>>>>> Normally I try to copy the actual behavior and put a note in the >>>>>> new make file about it. Now I discovered something that's just >>>>>> too weird: >>>>>> >>>>>> In "jdk/make/sun/rmi/cgi/Makefile" the program "java-rmi.exe" is >>>>>> built. This looks like it's intended to be a windows native >>>>>> version of the "java-rmi.cgi" script that is available on linux >>>>>> and solaris. The makefile even copies java-rmi.exe to >>>>>> java-rmi.cgi. When creating the j2sdk/jre images, however, only >>>>>> the exe version is included. I verified this in the promoted >>>>>> builds of jdk 7 (b148 and a few others). The makefile also tries >>>>>> to declare that the program be compiled from >>>>>> "jdk/src/windows/bin/java-rmi.c" (by declaring FILES_c variable) >>>>>> but Program.gmk ignores this and just builds main.c (the standard >>>>>> java launcher) instead. So the "java-rmi.exe" in a windows >>>>>> distribution is just java.exe with a weird name. >>>>>> >>>>>> What is this script/program used for, is it used at all, and how >>>>>> should I convert the building of it? I have tried compiling >>>>>> java-rmi.c and it seems to be working at least. (Gives same >>>>>> default output as the script on linux) >>>>>> >>>>>> /Erik -- Oracle Robert Ottenhag | Senior Member of Technical Staff Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 Oracle Java HotSpot Virtual Machine ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 Green Oracle Oracle is committed to developing practices and products that help protect the environment -- From erik.joelsson at oracle.com Thu Nov 10 08:23:45 2011 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 10 Nov 2011 17:23:45 +0100 Subject: java-rmi.exe/cgi In-Reply-To: <4EBBF9F2.9020403@oracle.com> References: <4EBBEA72.602@oracle.com> <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> <4EBBED4E.6030009@oracle.com> <3B052BEB-3C1F-4B97-B32E-632881EC58E1@oracle.com> <04FAEAF9-3BF0-4082-B7C2-E473ED53F215@oracle.com> <4EBBF732.3010606@oracle.com> <4EBBF9F2.9020403@oracle.com> Message-ID: <4EBBFA91.4090707@oracle.com> You have a good point there, Robert. Since I already did the conversion, I'm now just tweaking it so that the converted makefile does the same weird thing as the original. /Erik On 2011-11-10 17:21, Robert Ottenhag wrote: > This bug is mine actually. I submitted it to Sun back when analyzing > the JDK 6 build system for the JRockit JDK 6 port. > > My personal recommendation is that the removal should be done in Open > JDK 8 (and 7uX), and that the build-infra project should not remove it > on it's own, especially since the build-infra project does not do bug > tracking. > > I will take ownership of that bug and get it fixed. > > /Robert > > > On 11/10/2011 05:09 PM, Erik Joelsson wrote: >> What I don't understand is, when java-rmi.cgi was removed java 1.2, >> why leave the source and build file for it? They just stopped >> bundling it in the images? >> >> /Erik >> >> On 2011-11-10 16:46, Kelly O'Hair wrote: >>> Actually,, I suspect we may have many of these CCC type issues, we >>> could just gather them up and >>> do one CCC, when we get closer to integrating the changes. >>> So I still vote for delete, but we need to track these things. >>> >>> -kto >>> >>> On Nov 10, 2011, at 10:40 AM, Kelly O'Hair wrote: >>> >>>> You have my vote too. >>>> >>>> However, if we are removing something, we will eventually need a >>>> bug report and file a CCC for it (http://ccc.us.oracle.com) >>>> CCC is used whenever we do anything to the product that a customer >>>> might be surprised by, like deleting files or >>>> removing apis etc. >>>> >>>> Of course CCC might go away when the Sun LDAP goes away, not >>>> sure... We could wait to see what happens to CCC. ;^) >>>> >>>> -kto >>>> >>>> On Nov 10, 2011, at 10:27 AM, Erik Joelsson wrote: >>>> >>>>> Ah, thanks! The bug evaluation says that this shouldn't be built >>>>> at all. For the sake of faster builds, not building unnecessary >>>>> stuff is the best way of improving speed. I vote for delete. >>>>> >>>>> /Erik >>>>> >>>>> On 2011-11-10 16:21, Kelly O'Hair wrote: >>>>>> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 >>>>>> >>>>>> My gut feeling is that we fix it, and then add this file to an >>>>>> exclusion list when we get to the point of >>>>>> comparing built jdk images. >>>>>> But I'm willing to accept other suggestions. >>>>>> >>>>>> -kto >>>>>> >>>>>> On Nov 10, 2011, at 10:14 AM, Erik Joelsson wrote: >>>>>> >>>>>>> Sometimes when converting makefiles in the jdk repo, I stumble >>>>>>> over things that don't look right. The code seem to suggest one >>>>>>> intention, but careful inspection reveals a different behavior. >>>>>>> Normally I try to copy the actual behavior and put a note in the >>>>>>> new make file about it. Now I discovered something that's just >>>>>>> too weird: >>>>>>> >>>>>>> In "jdk/make/sun/rmi/cgi/Makefile" the program "java-rmi.exe" is >>>>>>> built. This looks like it's intended to be a windows native >>>>>>> version of the "java-rmi.cgi" script that is available on linux >>>>>>> and solaris. The makefile even copies java-rmi.exe to >>>>>>> java-rmi.cgi. When creating the j2sdk/jre images, however, only >>>>>>> the exe version is included. I verified this in the promoted >>>>>>> builds of jdk 7 (b148 and a few others). The makefile also tries >>>>>>> to declare that the program be compiled from >>>>>>> "jdk/src/windows/bin/java-rmi.c" (by declaring FILES_c variable) >>>>>>> but Program.gmk ignores this and just builds main.c (the >>>>>>> standard java launcher) instead. So the "java-rmi.exe" in a >>>>>>> windows distribution is just java.exe with a weird name. >>>>>>> >>>>>>> What is this script/program used for, is it used at all, and how >>>>>>> should I convert the building of it? I have tried compiling >>>>>>> java-rmi.c and it seems to be working at least. (Gives same >>>>>>> default output as the script on linux) >>>>>>> >>>>>>> /Erik > > From mark.reinhold at oracle.com Thu Nov 10 08:25:22 2011 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 10 Nov 2011 08:25:22 -0800 Subject: Disabled jcheck in all build-infra repos In-Reply-To: robert.ottenhag@oracle.com; Thu, 10 Nov 2011 17:15:15 +0100; <4EBBF893.6040408@oracle.com> Message-ID: <20111110162522.E34622DE4@eggemoggin.niobe.net> 2011/11/10 8:15 -0800, robert.ottenhag at oracle.com: > My vocabulary is somewhat misleading regarding "server side" here. I meant that > I committed the change to the repositories locally on my machine as usual and > then pushed it to the openjdk server using fpush, > e.g. http://hg.openjdk.java.net/build-infra/jdk7/rev/f0fb16984aeb. I do not > have any direct access to the openjdk server whatsoever ;-) Whatever the server > side does with jcheck on commits is surely handled by John C. only. For one of our Mercurial servers to run jcheck during a push requires not only a .jcheck/conf file in the target repo but also a setting in a separate configuration file stored elsewhere on the server itself. The build-infra repos on hg.openjdk.java.net have never been configured to run jcheck. Your changeset disables jcheck for local commits, which is no doubt useful but will not change any behavior on the server. - Mark From robert.ottenhag at oracle.com Thu Nov 10 08:34:32 2011 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Thu, 10 Nov 2011 08:34:32 -0800 (PST) Subject: java-rmi.exe/cgi In-Reply-To: <4EBBFA91.4090707@oracle.com> References: <4EBBEA72.602@oracle.com> <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> <4EBBED4E.6030009@oracle.com> <3B052BEB-3C1F-4B97-B32E-632881EC58E1@oracle.com> <04FAEAF9-3BF0-4082-B7C2-E473ED53F215@oracle.com> <4EBBF732.3010606@oracle.com> <4EBBF9F2.9020403@oracle.com 4EBBFA91.4090707@oracle.com> Message-ID: <2d43dbac-8a3c-4d3d-b826-a29b37ad6b99@default> Erik, Ok, I'm good with that. /R > -----Original Message----- > From: Erik Joelsson > Sent: Thursday, November 10, 2011 5:24 PM > To: Robert Ottenhag > Cc: Kelly O'Hair; build-infra-dev at openjdk.java.net > Subject: Re: java-rmi.exe/cgi > > You have a good point there, Robert. Since I already did the > conversion, > I'm now just tweaking it so that the converted makefile does the same > weird thing as the original. > > /Erik > > On 2011-11-10 17:21, Robert Ottenhag wrote: > > This bug is mine actually. I submitted it to Sun back when > analyzing > > the JDK 6 build system for the JRockit JDK 6 port. > > > > My personal recommendation is that the removal should be > done in Open > > JDK 8 (and 7uX), and that the build-infra project should > not remove it > > on it's own, especially since the build-infra project does > not do bug > > tracking. > > > > I will take ownership of that bug and get it fixed. > > > > /Robert > > > > > > On 11/10/2011 05:09 PM, Erik Joelsson wrote: > >> What I don't understand is, when java-rmi.cgi was removed > java 1.2, > >> why leave the source and build file for it? They just stopped > >> bundling it in the images? > >> > >> /Erik > >> > >> On 2011-11-10 16:46, Kelly O'Hair wrote: > >>> Actually,, I suspect we may have many of these CCC type > issues, we > >>> could just gather them up and > >>> do one CCC, when we get closer to integrating the changes. > >>> So I still vote for delete, but we need to track these things. > >>> > >>> -kto > >>> > >>> On Nov 10, 2011, at 10:40 AM, Kelly O'Hair wrote: > >>> > >>>> You have my vote too. > >>>> > >>>> However, if we are removing something, we will eventually need a > >>>> bug report and file a CCC for it (http://ccc.us.oracle.com) > >>>> CCC is used whenever we do anything to the product that > a customer > >>>> might be surprised by, like deleting files or > >>>> removing apis etc. > >>>> > >>>> Of course CCC might go away when the Sun LDAP goes away, not > >>>> sure... We could wait to see what happens to CCC. ;^) > >>>> > >>>> -kto > >>>> > >>>> On Nov 10, 2011, at 10:27 AM, Erik Joelsson wrote: > >>>> > >>>>> Ah, thanks! The bug evaluation says that this shouldn't > be built > >>>>> at all. For the sake of faster builds, not building unnecessary > >>>>> stuff is the best way of improving speed. I vote for delete. > >>>>> > >>>>> /Erik > >>>>> > >>>>> On 2011-11-10 16:21, Kelly O'Hair wrote: > >>>>>> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 > >>>>>> > >>>>>> My gut feeling is that we fix it, and then add this file to an > >>>>>> exclusion list when we get to the point of > >>>>>> comparing built jdk images. > >>>>>> But I'm willing to accept other suggestions. > >>>>>> > >>>>>> -kto > >>>>>> > >>>>>> On Nov 10, 2011, at 10:14 AM, Erik Joelsson wrote: > >>>>>> > >>>>>>> Sometimes when converting makefiles in the jdk repo, > I stumble > >>>>>>> over things that don't look right. The code seem to > suggest one > >>>>>>> intention, but careful inspection reveals a different > behavior. > >>>>>>> Normally I try to copy the actual behavior and put a > note in the > >>>>>>> new make file about it. Now I discovered something > that's just > >>>>>>> too weird: > >>>>>>> > >>>>>>> In "jdk/make/sun/rmi/cgi/Makefile" the program > "java-rmi.exe" is > >>>>>>> built. This looks like it's intended to be a windows native > >>>>>>> version of the "java-rmi.cgi" script that is > available on linux > >>>>>>> and solaris. The makefile even copies java-rmi.exe to > >>>>>>> java-rmi.cgi. When creating the j2sdk/jre images, > however, only > >>>>>>> the exe version is included. I verified this in the promoted > >>>>>>> builds of jdk 7 (b148 and a few others). The makefile > also tries > >>>>>>> to declare that the program be compiled from > >>>>>>> "jdk/src/windows/bin/java-rmi.c" (by declaring > FILES_c variable) > >>>>>>> but Program.gmk ignores this and just builds main.c (the > >>>>>>> standard java launcher) instead. So the "java-rmi.exe" in a > >>>>>>> windows distribution is just java.exe with a weird name. > >>>>>>> > >>>>>>> What is this script/program used for, is it used at > all, and how > >>>>>>> should I convert the building of it? I have tried compiling > >>>>>>> java-rmi.c and it seems to be working at least. (Gives same > >>>>>>> default output as the script on linux) > >>>>>>> > >>>>>>> /Erik > > > > > > From robert.ottenhag at oracle.com Thu Nov 10 08:37:14 2011 From: robert.ottenhag at oracle.com (Robert Ottenhag) Date: Thu, 10 Nov 2011 08:37:14 -0800 (PST) Subject: Disabled jcheck in all build-infra repos In-Reply-To: <20111110162522.E34622DE4@eggemoggin.niobe.net> References: <10> <2011> <17:15:15> <+0100> <4EBBF893.6040408@oracle.com 20111110162522.E34622DE4@eggemoggin.niobe.net> Message-ID: <5297f845-291c-435f-8f0a-fe123d636dc8@default> Mark, Thanks for clarifying these dependencies. It will be good to know if we do any new off-the-record project in the future. /Robert > -----Original Message----- > From: Mark Reinhold > Sent: Thursday, November 10, 2011 5:25 PM > To: Robert Ottenhag > Cc: build-infra-dev at openjdk.java.net > Subject: Re: Disabled jcheck in all build-infra repos > > 2011/11/10 8:15 -0800, robert.ottenhag at oracle.com: > > My vocabulary is somewhat misleading regarding "server > side" here. I meant that > > I committed the change to the repositories locally on my > machine as usual and > > then pushed it to the openjdk server using fpush, > > e.g. > http://hg.openjdk.java.net/build-infra/jdk7/rev/f0fb16984aeb. I do not > > have any direct access to the openjdk server whatsoever ;-) > Whatever the server > > side does with jcheck on commits is surely handled by John C. only. > > For one of our Mercurial servers to run jcheck during a push requires > not only a .jcheck/conf file in the target repo but also a setting in > a separate configuration file stored elsewhere on the server itself. > > The build-infra repos on hg.openjdk.java.net have never been > configured > to run jcheck. Your changeset disables jcheck for local > commits, which > is no doubt useful but will not change any behavior on the server. > > - Mark > > From kelly.ohair at oracle.com Thu Nov 10 08:44:51 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 10 Nov 2011 11:44:51 -0500 Subject: java-rmi.exe/cgi In-Reply-To: <4EBBF9F2.9020403@oracle.com> References: <4EBBEA72.602@oracle.com> <86407114-9D01-4740-B411-0C14DDD41AE9@oracle.com> <4EBBED4E.6030009@oracle.com> <3B052BEB-3C1F-4B97-B32E-632881EC58E1@oracle.com> <04FAEAF9-3BF0-4082-B7C2-E473ED53F215@oracle.com> <4EBBF732.3010606@oracle.com> <4EBBF9F2.9020403@oracle.com> Message-ID: <3FE9BE18-FBEE-4BDB-8969-2BCC58CF943A@oracle.com> On Nov 10, 2011, at 11:21 AM, Robert Ottenhag wrote: > This bug is mine actually. I submitted it to Sun back when analyzing the JDK 6 build system for the JRockit JDK 6 port. > > My personal recommendation is that the removal should be done in Open JDK 8 (and 7uX), and that the build-infra project should not remove it on it's own, especially since the build-infra project does not do bug tracking. > > I will take ownership of that bug and get it fixed. Thank you. -kto > > /Robert > > > On 11/10/2011 05:09 PM, Erik Joelsson wrote: >> What I don't understand is, when java-rmi.cgi was removed java 1.2, why leave the source and build file for it? They just stopped bundling it in the images? >> >> /Erik >> >> On 2011-11-10 16:46, Kelly O'Hair wrote: >>> Actually,, I suspect we may have many of these CCC type issues, we could just gather them up and >>> do one CCC, when we get closer to integrating the changes. >>> So I still vote for delete, but we need to track these things. >>> >>> -kto >>> >>> On Nov 10, 2011, at 10:40 AM, Kelly O'Hair wrote: >>> >>>> You have my vote too. >>>> >>>> However, if we are removing something, we will eventually need a bug report and file a CCC for it (http://ccc.us.oracle.com) >>>> CCC is used whenever we do anything to the product that a customer might be surprised by, like deleting files or >>>> removing apis etc. >>>> >>>> Of course CCC might go away when the Sun LDAP goes away, not sure... We could wait to see what happens to CCC. ;^) >>>> >>>> -kto >>>> >>>> On Nov 10, 2011, at 10:27 AM, Erik Joelsson wrote: >>>> >>>>> Ah, thanks! The bug evaluation says that this shouldn't be built at all. For the sake of faster builds, not building unnecessary stuff is the best way of improving speed. I vote for delete. >>>>> >>>>> /Erik >>>>> >>>>> On 2011-11-10 16:21, Kelly O'Hair wrote: >>>>>> See http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6512052 >>>>>> >>>>>> My gut feeling is that we fix it, and then add this file to an exclusion list when we get to the point of >>>>>> comparing built jdk images. >>>>>> But I'm willing to accept other suggestions. >>>>>> >>>>>> -kto >>>>>> >>>>>> On Nov 10, 2011, at 10:14 AM, Erik Joelsson wrote: >>>>>> >>>>>>> Sometimes when converting makefiles in the jdk repo, I stumble over things that don't look right. The code seem to suggest one intention, but careful inspection reveals a different behavior. Normally I try to copy the actual behavior and put a note in the new make file about it. Now I discovered something that's just too weird: >>>>>>> >>>>>>> In "jdk/make/sun/rmi/cgi/Makefile" the program "java-rmi.exe" is built. This looks like it's intended to be a windows native version of the "java-rmi.cgi" script that is available on linux and solaris. The makefile even copies java-rmi.exe to java-rmi.cgi. When creating the j2sdk/jre images, however, only the exe version is included. I verified this in the promoted builds of jdk 7 (b148 and a few others). The makefile also tries to declare that the program be compiled from "jdk/src/windows/bin/java-rmi.c" (by declaring FILES_c variable) but Program.gmk ignores this and just builds main.c (the standard java launcher) instead. So the "java-rmi.exe" in a windows distribution is just java.exe with a weird name. >>>>>>> >>>>>>> What is this script/program used for, is it used at all, and how should I convert the building of it? I have tried compiling java-rmi.c and it seems to be working at least. (Gives same default output as the script on linux) >>>>>>> >>>>>>> /Erik > > > -- > Oracle > Robert Ottenhag | Senior Member of Technical Staff > Phone: +46850630961 | Fax: +46850630911 | Mobile: +46707106161 > Oracle Java HotSpot Virtual Machine > ORACLE Sweden | Folkungagatan 122 | SE-116 30 Stockholm > > Oracle Svenska AB, Kronborgsgr?nd 17, S-164 28 KISTA, reg.no. 556254-6746 > > Green Oracle > > Oracle is committed to developing practices and products that help protect the environment > -- > From kelly.ohair at oracle.com Thu Nov 10 08:47:09 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Thu, 10 Nov 2011 11:47:09 -0500 Subject: Disabled jcheck in all build-infra repos In-Reply-To: <5297f845-291c-435f-8f0a-fe123d636dc8@default> References: <10> <2011> <17:15:15> <+0100> <4EBBF893.6040408@oracle.com 20111110162522.E34622DE4@eggemoggin.niobe.net> <5297f845-291c-435f-8f0a-fe123d636dc8@default> Message-ID: <367850A1-EE5E-4BC8-8345-86F768A4D583@oracle.com> Ah it all makes sense now. Thanks Mark, for checking. So when we do our integration, we will need to make sure these .jcheck/conf changes are not included. -kto On Nov 10, 2011, at 11:37 AM, Robert Ottenhag wrote: > Mark, > > Thanks for clarifying these dependencies. It will be good to know if we do any new off-the-record project in the future. > > /Robert > >> -----Original Message----- >> From: Mark Reinhold >> Sent: Thursday, November 10, 2011 5:25 PM >> To: Robert Ottenhag >> Cc: build-infra-dev at openjdk.java.net >> Subject: Re: Disabled jcheck in all build-infra repos >> >> 2011/11/10 8:15 -0800, robert.ottenhag at oracle.com: >>> My vocabulary is somewhat misleading regarding "server >> side" here. I meant that >>> I committed the change to the repositories locally on my >> machine as usual and >>> then pushed it to the openjdk server using fpush, >>> e.g. >> http://hg.openjdk.java.net/build-infra/jdk7/rev/f0fb16984aeb. I do not >>> have any direct access to the openjdk server whatsoever ;-) >> Whatever the server >>> side does with jcheck on commits is surely handled by John C. only. >> >> For one of our Mercurial servers to run jcheck during a push requires >> not only a .jcheck/conf file in the target repo but also a setting in >> a separate configuration file stored elsewhere on the server itself. >> >> The build-infra repos on hg.openjdk.java.net have never been >> configured >> to run jcheck. Your changeset disables jcheck for local >> commits, which >> is no doubt useful but will not change any behavior on the server. >> >> - Mark >> >> From fredrik.ohrstrom at oracle.com Thu Nov 10 08:51:10 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 10 Nov 2011 16:51:10 +0000 Subject: hg: build-infra/jdk7/langtools: Moved dependency tracking code into com.sun.tools.javac.comp.Dependencies. Message-ID: <20111110165114.38655472F0@hg.openjdk.java.net> Changeset: e3a7d4ff462b Author: ohrstrom Date: 2011-11-10 17:50 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/e3a7d4ff462b Moved dependency tracking code into com.sun.tools.javac.comp.Dependencies. Moved the server into com.sun.tools.javacserver.JavacServer ! src/share/classes/com/sun/tools/javac/Main.java + src/share/classes/com/sun/tools/javac/comp/ApiVisitor.java + src/share/classes/com/sun/tools/javac/comp/Dependencies.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java + src/share/classes/com/sun/tools/javac/comp/NativeapiVisitor.java + src/share/classes/com/sun/tools/javac/comp/PubapiVisitor.java ! src/share/classes/com/sun/tools/javac/comp/Resolve.java ! src/share/classes/com/sun/tools/javac/main/JavaCompiler.java - src/share/classes/com/sun/tools/javac/main/JavacServer.java ! src/share/classes/com/sun/tools/javac/main/Main.java - src/share/classes/com/sun/tools/javac/processing/ApiVisitor.java - src/share/classes/com/sun/tools/javac/processing/NativeapiVisitor.java - src/share/classes/com/sun/tools/javac/processing/PubapiVisitor.java + src/share/classes/com/sun/tools/javac/util/OptionParser.java + src/share/classes/com/sun/tools/javacserver/JavacServer.java From erik.joelsson at oracle.com Thu Nov 10 09:25:06 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Thu, 10 Nov 2011 17:25:06 +0000 Subject: hg: build-infra/jdk7/jdk: Converted rmi/cgi. Message-ID: <20111110172526.BFFCD472F2@hg.openjdk.java.net> Changeset: e96a60ae6252 Author: erikj Date: 2011-11-10 18:24 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/e96a60ae6252 Converted rmi/cgi. ! make/CompileLaunchers.gmk ! make/sun/Makefile - make/sun/rmi/Makefile - make/sun/rmi/cgi/Makefile From erik.joelsson at oracle.com Fri Nov 11 05:20:32 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 11 Nov 2011 13:20:32 +0000 Subject: hg: build-infra/jdk7/jdk: Converted sun/management Message-ID: <20111111132051.2FB6A47317@hg.openjdk.java.net> Changeset: e1678395abb2 Author: erikj Date: 2011-11-11 14:20 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/e1678395abb2 Converted sun/management ! make/CompileJavaClasses.gmk ! make/CopyFiles.gmk ! make/sun/Makefile - make/sun/management/Makefile - make/sun/management/jmxremote/Makefile From fredrik.ohrstrom at oracle.com Sat Nov 12 12:01:40 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Sat, 12 Nov 2011 20:01:40 +0000 Subject: hg: build-infra/jdk7: Corrected package names. Message-ID: <20111112200140.CA44B47350@hg.openjdk.java.net> Changeset: 6f26f5fa5ef9 Author: ohrstrom Date: 2011-11-12 21:01 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/6f26f5fa5ef9 Corrected package names. ! common/config/help.m4 From scf.code at gmail.com Sun Nov 13 16:35:46 2011 From: scf.code at gmail.com (Stephen Fitch) Date: Sun, 13 Nov 2011 16:35:46 -0800 Subject: --with-override-source-root= examples ? Message-ID: Hi Are there any examples of people using --with-override-source-root I was attempting to try it in order to build jdk7u. I used... ./configure --with-boot-jdk=/usr/lib/jvm/java-6-openjdk --disable-javac-multi-core --disable-javac-deps --disable-javac-server --with-override-source-root=/media/disk1/dev/jdk7u/ however it doesn't seem to compile the source tree under /media/disk1/dev/jdk7u ... it just proceeds to compile the one I got with the build infra. Any thoughts around this arg welcomed. Thanks Stephen From scf.code at gmail.com Sun Nov 13 16:45:55 2011 From: scf.code at gmail.com (Stephen Fitch) Date: Sun, 13 Nov 2011 16:45:55 -0800 Subject: Linking libsctp.so - inker failure on Ubuntu 11.10 Message-ID: A long shot... anyone seen this before (I'm on Ubuntu 11.10 - i.e., Linux Kernel 3.0 Linux sf-VirtualBox 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux ) Looked like a failure to link with -ldl Any advice welcomed Stephen //----------------- ######################################################################## ######################################################################## ##### Entering jdk for target(s) all ##### ######################################################################## Copying libjaas_unix.so Linking libsctp.so /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpServerChannelImpl.o: In function `Java_sun_nio_ch_SctpServerChannelImpl_initIDs': SctpServerChannelImpl.c:(.text+0x6): undefined reference to `Java_sun_nio_ch_ServerSocketChannelImpl_initIDs' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpServerChannelImpl.o: In function `Java_sun_nio_ch_SctpServerChannelImpl_accept0': SctpServerChannelImpl.c:(.text+0x16): undefined reference to `Java_sun_nio_ch_ServerSocketChannelImpl_accept0' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpChannelImpl.o: In function `Java_sun_nio_ch_SctpChannelImpl_send0': SctpChannelImpl.c:(.text+0xde8): undefined reference to `NET_InetAddressToSockaddr' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpChannelImpl.o: In function `Java_sun_nio_ch_SctpChannelImpl_checkConnect': SctpChannelImpl.c:(.text+0xf8d): undefined reference to `Java_sun_nio_ch_SocketChannelImpl_checkConnect' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `loadSocketExtensionFuncs': SctpNet.c:(.text+0x29): undefined reference to `dlopen' SctpNet.c:(.text+0x40): undefined reference to `dlsym' SctpNet.c:(.text+0x61): undefined reference to `dlsym' SctpNet.c:(.text+0x82): undefined reference to `dlsym' SctpNet.c:(.text+0x9f): undefined reference to `dlsym' SctpNet.c:(.text+0xbc): undefined reference to `dlsym' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o:SctpNet.c:(.text+0xd9): more undefined references to `dlsym' follow /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `loadSocketExtensionFuncs': SctpNet.c:(.text+0x101): undefined reference to `dlerror' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `Java_sun_nio_ch_SctpNet_socket0': SctpNet.c:(.text+0x261): undefined reference to `ipv6_available' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `Java_sun_nio_ch_SctpNet_bindx': SctpNet.c:(.text+0x3d8): undefined reference to `NET_InetAddressToSockaddr' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `Java_sun_nio_ch_SctpNet_connect0': SctpNet.c:(.text+0x4e4): undefined reference to `ipv6_available' SctpNet.c:(.text+0x50e): undefined reference to `NET_InetAddressToSockaddr' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `SockAddrToInetSocketAddress': SctpNet.c:(.text+0x6d8): undefined reference to `NET_SockaddrToInetAddress' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `Java_sun_nio_ch_SctpNet_getLocalAddresses0': SctpNet.c:(.text+0x7e4): undefined reference to `NET_SockaddrToInetAddress' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `getRemoteAddresses': SctpNet.c:(.text+0x94d): undefined reference to `NET_SockaddrToInetAddress' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `Java_sun_nio_ch_SctpNet_setIntOption0': SctpNet.c:(.text+0xac0): undefined reference to `NET_SetSockOpt' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `Java_sun_nio_ch_SctpNet_getIntOption0': SctpNet.c:(.text+0xbbd): undefined reference to `NET_GetSockOpt' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `Java_sun_nio_ch_SctpNet_setPrimAddrOption0': SctpNet.c:(.text+0xd3e): undefined reference to `NET_InetAddressToSockaddr' /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: In function `Java_sun_nio_ch_SctpNet_setPeerPrimAddrOption0': SctpNet.c:(.text+0xdfd): undefined reference to `NET_InetAddressToSockaddr' collect2: ld returned 1 exit status make[2]: *** [/media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp.so] Error 1 make[1]: *** [all] Error 2 make: *** [jdk] Error 2 sf at sf-VirtualBox:/media/disk1/dev/build-infra$ From erik.joelsson at oracle.com Mon Nov 14 00:53:28 2011 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Mon, 14 Nov 2011 09:53:28 +0100 Subject: Linking libsctp.so - inker failure on Ubuntu 11.10 In-Reply-To: References: Message-ID: <4EC0D708.7050702@oracle.com> If you are on Ubuntu 11.10, I suspect this is caused by the (new?) requirement by gcc that libraries are put after object files on the link command line. Since none of us working on this project so far are running with such a new gcc, we haven't hit the problem yet, but it's definitely something we need to fix. /Erik On 2011-11-14 01:45, Stephen Fitch wrote: > A long shot... anyone seen this before (I'm on Ubuntu 11.10 - i.e., > Linux Kernel 3.0 > Linux sf-VirtualBox 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 > 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux > ) > > Looked like a failure to link with -ldl > > Any advice welcomed > > Stephen > > //----------------- > > ######################################################################## > ######################################################################## > ##### Entering jdk for target(s) all ##### > ######################################################################## > > Copying libjaas_unix.so > Linking libsctp.so > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpServerChannelImpl.o: > In function `Java_sun_nio_ch_SctpServerChannelImpl_initIDs': > SctpServerChannelImpl.c:(.text+0x6): undefined reference to > `Java_sun_nio_ch_ServerSocketChannelImpl_initIDs' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpServerChannelImpl.o: > In function `Java_sun_nio_ch_SctpServerChannelImpl_accept0': > SctpServerChannelImpl.c:(.text+0x16): undefined reference to > `Java_sun_nio_ch_ServerSocketChannelImpl_accept0' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpChannelImpl.o: > In function `Java_sun_nio_ch_SctpChannelImpl_send0': > SctpChannelImpl.c:(.text+0xde8): undefined reference to > `NET_InetAddressToSockaddr' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpChannelImpl.o: > In function `Java_sun_nio_ch_SctpChannelImpl_checkConnect': > SctpChannelImpl.c:(.text+0xf8d): undefined reference to > `Java_sun_nio_ch_SocketChannelImpl_checkConnect' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `loadSocketExtensionFuncs': > SctpNet.c:(.text+0x29): undefined reference to `dlopen' > SctpNet.c:(.text+0x40): undefined reference to `dlsym' > SctpNet.c:(.text+0x61): undefined reference to `dlsym' > SctpNet.c:(.text+0x82): undefined reference to `dlsym' > SctpNet.c:(.text+0x9f): undefined reference to `dlsym' > SctpNet.c:(.text+0xbc): undefined reference to `dlsym' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o:SctpNet.c:(.text+0xd9): > more undefined references to `dlsym' follow > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `loadSocketExtensionFuncs': > SctpNet.c:(.text+0x101): undefined reference to `dlerror' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `Java_sun_nio_ch_SctpNet_socket0': > SctpNet.c:(.text+0x261): undefined reference to `ipv6_available' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `Java_sun_nio_ch_SctpNet_bindx': > SctpNet.c:(.text+0x3d8): undefined reference to `NET_InetAddressToSockaddr' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `Java_sun_nio_ch_SctpNet_connect0': > SctpNet.c:(.text+0x4e4): undefined reference to `ipv6_available' > SctpNet.c:(.text+0x50e): undefined reference to `NET_InetAddressToSockaddr' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `SockAddrToInetSocketAddress': > SctpNet.c:(.text+0x6d8): undefined reference to `NET_SockaddrToInetAddress' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `Java_sun_nio_ch_SctpNet_getLocalAddresses0': > SctpNet.c:(.text+0x7e4): undefined reference to `NET_SockaddrToInetAddress' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `getRemoteAddresses': > SctpNet.c:(.text+0x94d): undefined reference to `NET_SockaddrToInetAddress' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `Java_sun_nio_ch_SctpNet_setIntOption0': > SctpNet.c:(.text+0xac0): undefined reference to `NET_SetSockOpt' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `Java_sun_nio_ch_SctpNet_getIntOption0': > SctpNet.c:(.text+0xbbd): undefined reference to `NET_GetSockOpt' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `Java_sun_nio_ch_SctpNet_setPrimAddrOption0': > SctpNet.c:(.text+0xd3e): undefined reference to `NET_InetAddressToSockaddr' > /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: > In function `Java_sun_nio_ch_SctpNet_setPeerPrimAddrOption0': > SctpNet.c:(.text+0xdfd): undefined reference to `NET_InetAddressToSockaddr' > collect2: ld returned 1 exit status > make[2]: *** [/media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp.so] > Error 1 > make[1]: *** [all] Error 2 > make: *** [jdk] Error 2 > sf at sf-VirtualBox:/media/disk1/dev/build-infra$ From kelly.ohair at oracle.com Mon Nov 14 08:36:50 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Mon, 14 Nov 2011 08:36:50 -0800 Subject: Linking libsctp.so - inker failure on Ubuntu 11.10 In-Reply-To: <4EC0D708.7050702@oracle.com> References: <4EC0D708.7050702@oracle.com> Message-ID: Erik is right. This is also a 3.0 kernel I think, and I have no idea what the makefiles will do when they see 3.0 rather than 2.6. So this is new territory. -kto On Nov 14, 2011, at 12:53 AM, Erik Joelsson wrote: > If you are on Ubuntu 11.10, I suspect this is caused by the (new?) requirement by gcc that libraries are put after object files on the link command line. Since none of us working on this project so far are running with such a new gcc, we haven't hit the problem yet, but it's definitely something we need to fix. > > /Erik > > On 2011-11-14 01:45, Stephen Fitch wrote: >> A long shot... anyone seen this before (I'm on Ubuntu 11.10 - i.e., >> Linux Kernel 3.0 >> Linux sf-VirtualBox 3.0.0-12-generic #20-Ubuntu SMP Fri Oct 7 >> 14:56:25 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux >> ) >> >> Looked like a failure to link with -ldl >> >> Any advice welcomed >> >> Stephen >> >> //----------------- >> >> ######################################################################## >> ######################################################################## >> ##### Entering jdk for target(s) all ##### >> ######################################################################## >> >> Copying libjaas_unix.so >> Linking libsctp.so >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpServerChannelImpl.o: >> In function `Java_sun_nio_ch_SctpServerChannelImpl_initIDs': >> SctpServerChannelImpl.c:(.text+0x6): undefined reference to >> `Java_sun_nio_ch_ServerSocketChannelImpl_initIDs' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpServerChannelImpl.o: >> In function `Java_sun_nio_ch_SctpServerChannelImpl_accept0': >> SctpServerChannelImpl.c:(.text+0x16): undefined reference to >> `Java_sun_nio_ch_ServerSocketChannelImpl_accept0' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpChannelImpl.o: >> In function `Java_sun_nio_ch_SctpChannelImpl_send0': >> SctpChannelImpl.c:(.text+0xde8): undefined reference to >> `NET_InetAddressToSockaddr' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpChannelImpl.o: >> In function `Java_sun_nio_ch_SctpChannelImpl_checkConnect': >> SctpChannelImpl.c:(.text+0xf8d): undefined reference to >> `Java_sun_nio_ch_SocketChannelImpl_checkConnect' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `loadSocketExtensionFuncs': >> SctpNet.c:(.text+0x29): undefined reference to `dlopen' >> SctpNet.c:(.text+0x40): undefined reference to `dlsym' >> SctpNet.c:(.text+0x61): undefined reference to `dlsym' >> SctpNet.c:(.text+0x82): undefined reference to `dlsym' >> SctpNet.c:(.text+0x9f): undefined reference to `dlsym' >> SctpNet.c:(.text+0xbc): undefined reference to `dlsym' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o:SctpNet.c:(.text+0xd9): >> more undefined references to `dlsym' follow >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `loadSocketExtensionFuncs': >> SctpNet.c:(.text+0x101): undefined reference to `dlerror' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `Java_sun_nio_ch_SctpNet_socket0': >> SctpNet.c:(.text+0x261): undefined reference to `ipv6_available' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `Java_sun_nio_ch_SctpNet_bindx': >> SctpNet.c:(.text+0x3d8): undefined reference to `NET_InetAddressToSockaddr' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `Java_sun_nio_ch_SctpNet_connect0': >> SctpNet.c:(.text+0x4e4): undefined reference to `ipv6_available' >> SctpNet.c:(.text+0x50e): undefined reference to `NET_InetAddressToSockaddr' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `SockAddrToInetSocketAddress': >> SctpNet.c:(.text+0x6d8): undefined reference to `NET_SockaddrToInetAddress' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `Java_sun_nio_ch_SctpNet_getLocalAddresses0': >> SctpNet.c:(.text+0x7e4): undefined reference to `NET_SockaddrToInetAddress' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `getRemoteAddresses': >> SctpNet.c:(.text+0x94d): undefined reference to `NET_SockaddrToInetAddress' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `Java_sun_nio_ch_SctpNet_setIntOption0': >> SctpNet.c:(.text+0xac0): undefined reference to `NET_SetSockOpt' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `Java_sun_nio_ch_SctpNet_getIntOption0': >> SctpNet.c:(.text+0xbbd): undefined reference to `NET_GetSockOpt' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `Java_sun_nio_ch_SctpNet_setPrimAddrOption0': >> SctpNet.c:(.text+0xd3e): undefined reference to `NET_InetAddressToSockaddr' >> /media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp/SctpNet.o: >> In function `Java_sun_nio_ch_SctpNet_setPeerPrimAddrOption0': >> SctpNet.c:(.text+0xdfd): undefined reference to `NET_InetAddressToSockaddr' >> collect2: ld returned 1 exit status >> make[2]: *** [/media/disk1/dev/build-infra/build/linux-amd64-server-release/jdk/newobjs/libsctp.so] >> Error 1 >> make[1]: *** [all] Error 2 >> make: *** [jdk] Error 2 >> sf at sf-VirtualBox:/media/disk1/dev/build-infra$ From erik.joelsson at oracle.com Mon Nov 14 08:57:40 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 14 Nov 2011 16:57:40 +0000 Subject: hg: build-infra/jdk7: 2 new changesets Message-ID: <20111114165741.04D3D47359@hg.openjdk.java.net> Changeset: d7453e4f6af0 Author: erikj Date: 2011-11-14 17:45 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/d7453e4f6af0 Fixed an issue with duplicate rules for files being generated if one dir in SRC is a subdir of another. ! common/make/NativeCompilation.gmk Changeset: 6edc9e55ebb3 Author: erikj Date: 2011-11-14 17:55 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/6edc9e55ebb3 Merge From erik.joelsson at oracle.com Mon Nov 14 08:58:31 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Mon, 14 Nov 2011 16:58:31 +0000 Subject: hg: build-infra/jdk7/jdk: Converted sun/cmm/lcms and parts of sun/cmm. Message-ID: <20111114165852.356684735A@hg.openjdk.java.net> Changeset: 390c87d232c3 Author: erikj Date: 2011-11-14 17:53 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/390c87d232c3 Converted sun/cmm/lcms and parts of sun/cmm. ! make/CompileJavaClasses.gmk ! make/CompileNativeLibraries.gmk ! make/CopyFiles.gmk ! make/CopyIntoClasses.gmk ! make/sun/cmm/Makefile - make/sun/cmm/lcms/FILES_c_unix.gmk - make/sun/cmm/lcms/FILES_c_windows.gmk - make/sun/cmm/lcms/Makefile From tim.bell at gmail.com Mon Nov 14 21:08:46 2011 From: tim.bell at gmail.com (Tim Bell) Date: Mon, 14 Nov 2011 21:08:46 -0800 Subject: Linking libsctp.so - inker failure on Ubuntu 11.10 In-Reply-To: References: <4EC0D708.7050702@oracle.com> Message-ID: Kelly wrote: [...] > This is also a 3.0 kernel I think, and I have no idea what the makefiles will do when they see 3.0 rather than 2.6. There could be other version checks, but this was fixed for HotSpot in hs22 and 7u2 Bug ID: 7072341 "enable hotspot builds on Linux 3.0" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7072341 Also in icedtea: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/2011-July/015162.html I see the fix also made it into the build-infra/jdk8 tree: cat -n build-infra/jdk8/hotspot/make/linux/Makefile [...] 234 SUPPORTED_OS_VERSION = 2.4% 2.5% 2.6% 3% Hope this helps- Tim Bell From fredrik.ohrstrom at oracle.com Tue Nov 15 08:12:22 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 15 Nov 2011 16:12:22 +0000 Subject: hg: build-infra/jdk7/langtools: Debug duplicate class problem. Message-ID: <20111115161227.585CF47366@hg.openjdk.java.net> Changeset: 1607c4da260f Author: ohrstrom Date: 2011-11-15 17:12 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/1607c4da260f Debug duplicate class problem. ! src/share/classes/com/sun/tools/javac/comp/Dependencies.java ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javacserver/JavacServer.java From erik.joelsson at oracle.com Tue Nov 15 09:08:57 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Tue, 15 Nov 2011 17:08:57 +0000 Subject: hg: build-infra/jdk7/jdk: Converted sun/jpeg. Only open parts. Message-ID: <20111115170917.81C2A47369@hg.openjdk.java.net> Changeset: 906e62d93b0d Author: erikj Date: 2011-11-15 18:08 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/906e62d93b0d Converted sun/jpeg. Only open parts. ! make/CompileNativeLibraries.gmk ! make/sun/Makefile - make/sun/jpeg/FILES_c.gmk - make/sun/jpeg/Makefile From erik.joelsson at oracle.com Wed Nov 16 03:00:45 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Wed, 16 Nov 2011 11:00:45 +0000 Subject: hg: build-infra/jdk7/jdk: Missed adding the dependency to mapfile creation. Message-ID: <20111116110112.013504738D@hg.openjdk.java.net> Changeset: 675db8b6f99e Author: erikj Date: 2011-11-16 12:00 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/675db8b6f99e Missed adding the dependency to mapfile creation. ! make/CompileNativeLibraries.gmk From fredrik.ohrstrom at oracle.com Thu Nov 17 08:32:21 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Thu, 17 Nov 2011 16:32:21 +0000 Subject: hg: build-infra/jdk7/langtools: Deal properly with symlinked root, by changing from getCanonicalPath Message-ID: <20111117163226.477CC473B5@hg.openjdk.java.net> Changeset: 7d7065e16415 Author: ohrstrom Date: 2011-11-17 17:33 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/7d7065e16415 Deal properly with symlinked root, by changing from getCanonicalPath to getAbsolutePath in javac server client. ! src/share/classes/com/sun/tools/javac/comp/Enter.java ! src/share/classes/com/sun/tools/javacserver/JavacServer.java From fredrik.ohrstrom at oracle.com Thu Nov 17 08:41:18 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Thu, 17 Nov 2011 17:41:18 +0100 Subject: Fixed build problem when source was symlinked Message-ID: <4EC5392E.8060908@oracle.com> The build problem experienced by Max was caused by the source root being symlinked. For example the physical location was /some/where/location/build-infra/jdk7 but configure && make was run from /spaces/build-infra/jdk7 where /spaces was a symlink to /some/where/location. The fix was simple, change getCanonicalPath in the javac server client to getAbsolutePath. Thank you very much for the help in discovering the symlink problem Max! //Fredrik From fredrik.ohrstrom at oracle.com Mon Nov 21 04:09:09 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Mon, 21 Nov 2011 12:09:09 +0000 Subject: hg: build-infra/jdk7: Started working on --with-override-source-root and --with-add-souce-root Message-ID: <20111121120909.9F9A34740B@hg.openjdk.java.net> Changeset: 42990deafe8d Author: ohrstrom Date: 2011-11-21 13:10 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/42990deafe8d Started working on --with-override-source-root and --with-add-souce-root ! common/config/spec.gmk.in ! common/make/JavaCompilation.gmk ! configure ! configure.ac From fredrik.ohrstrom at oracle.com Mon Nov 21 06:24:44 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Mon, 21 Nov 2011 14:24:44 +0000 Subject: hg: build-infra/jdk7/jdk: Moving mapfiles and cleanup parameters to sub-macros. Message-ID: <20111121142508.A06D247411@hg.openjdk.java.net> Changeset: cc67fe5baaab Author: ohrstrom Date: 2011-11-21 15:26 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/cc67fe5baaab Moving mapfiles and cleanup parameters to sub-macros. ! make/CompileLaunchers.gmk ! make/CompileNativeLibraries.gmk - make/com/sun/java/pack/mapfile-vers - make/com/sun/java/pack/mapfile-vers-unpack200 - make/com/sun/security/auth/module/mapfile-vers ! make/java/Makefile - make/java/zip/FILES_c.gmk - make/java/zip/FILES_java.gmk - make/java/zip/Makefile - make/java/zip/mapfile-vers - make/java/zip/reorder-i586 - make/java/zip/reorder-sparc - make/java/zip/reorder-sparcv9 - make/jpda/back/mapfile-vers - make/jpda/transport/shmem/mapfile-vers - make/jpda/transport/socket/mapfile-vers + make/mapfiles/libattach/mapfile-linux + make/mapfiles/libattach/mapfile-solaris + make/mapfiles/libdt_socket/mapfile-vers + make/mapfiles/libjaas/mapfile-vers + make/mapfiles/libjdwp/mapfile-vers + make/mapfiles/libjpeg/mapfile-vers + make/mapfiles/libjpeg/mapfile-vers-closed + make/mapfiles/libjpeg/reorder-i586 + make/mapfiles/libjpeg/reorder-sparc + make/mapfiles/libjpeg/reorder-sparcv9 + make/mapfiles/libjsdt/mapfile-vers + make/mapfiles/liblcms/mapfile-vers + make/mapfiles/librmi/mapfile-vers + make/mapfiles/libsctp/mapfile-vers + make/mapfiles/libunpack/mapfile-vers + make/mapfiles/libunpack/mapfile-vers-unpack200 + make/mapfiles/libverify/mapfile-vers + make/mapfiles/libverify/reorder-i586 + make/mapfiles/libverify/reorder-sparc + make/mapfiles/libverify/reorder-sparcv9 + make/mapfiles/libzip/mapfile-vers + make/mapfiles/libzip/reorder-i586 + make/mapfiles/libzip/reorder-sparc + make/mapfiles/libzip/reorder-sparcv9 - make/sun/cmm/lcms/mapfile-vers - make/sun/jpeg/mapfile-vers - make/sun/jpeg/mapfile-vers-closed - make/sun/jpeg/reorder-i586 - make/sun/jpeg/reorder-sparc - make/sun/jpeg/reorder-sparcv9 - make/sun/rmi/rmi/mapfile-vers - make/sun/tracing/dtrace/mapfile-vers From fredrik.ohrstrom at oracle.com Tue Nov 22 03:10:38 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 22 Nov 2011 11:10:38 +0000 Subject: hg: build-infra/jdk7: Cleaning up linker and compiler flags. Message-ID: <20111122111038.4FD9B47422@hg.openjdk.java.net> Changeset: f89e63ee8e2f Author: ohrstrom Date: 2011-11-22 12:12 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/f89e63ee8e2f Cleaning up linker and compiler flags. ! common/make/NativeCompilation.gmk ! configure ! configure.ac From fredrik.ohrstrom at oracle.com Tue Nov 22 03:10:58 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 22 Nov 2011 11:10:58 +0000 Subject: hg: build-infra/jdk7/jdk: Cleaning up flags to compiler and linker. Message-ID: <20111122111121.18E6747423@hg.openjdk.java.net> Changeset: a5a258509634 Author: ohrstrom Date: 2011-11-22 12:10 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/a5a258509634 Cleaning up flags to compiler and linker. ! make/CompileLaunchers.gmk ! make/CompileNativeLibraries.gmk From david.holmes at oracle.com Wed Nov 23 12:48:38 2011 From: david.holmes at oracle.com (David Holmes) Date: Thu, 24 Nov 2011 06:48:38 +1000 Subject: jdk/src/solaris - time to re-visit it? In-Reply-To: <4ECCE31D.90007@oracle.com> References: <4ECCE31D.90007@oracle.com> Message-ID: <4ECD5C26.1040303@oracle.com> Alan, It's definitely tricky (lots of refactoring needed) but it definitely needs to be done at some point - however I think we already missed the opportunity to do this before integrating the BSD and MacOSX code (same on the VM side) David On 23/11/2011 10:12 PM, Alan Bateman wrote: > > In the jdk repository then src/solaris has all the Solaris and Linux > code. Most of it is used for both platforms with a small number of files > specific to one or the other. I'm sure this has come up before (probably > many times) but I'd like to bring it up again. > > One of motives for bringing this up now is the Mac OS X port is coming. > It adds/changes code in src/solaris and also adds a lot of code to a new > tree src/macosx. Another motivation is patches from IBM folks which are > really just changes to workaround the fact that we've got code for > several platforms in the same directory. As I look through src/solaris > now it is clear that we have taken several approaches to this. In some > cases we've got Solaris* files, in other cases we rename files during > the build. > > The purpose of this mail is just to probe and see if anyone has thought > about this problem recently. I'm not suggesting anything specific except > to see whether it's worth thinking about how we might change this in the > future. I've no doubt that there isn't a perfect solution to this and > clearly any changes will be disruptive (but there's no harm discussing > possible options). > > -Alan. > > From fredrik.ohrstrom at oracle.com Thu Nov 24 06:39:59 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Thu, 24 Nov 2011 15:39:59 +0100 Subject: jdk/src/solaris - time to re-visit it? In-Reply-To: <4ECE1867.8020302@oracle.com> References: <4ECCE31D.90007@oracle.com> <4ECD5C26.1040303@oracle.com> <4ECE1867.8020302@oracle.com> Message-ID: <4ECE573F.1050702@oracle.com> 2011-11-24 11:11, Alan Bateman skrev: > The immediate benefit of renaming is that it would allow us to move the > Solaris and Linux specific source files out of the src/unix tree into > src/ directories. That would eliminate the need for some of > the filtering in the build and would also allow us sort out some name > conflict issues that we have in several places > (UNIXProcess.java. for example). It would be great to do the rename. However, we should not do that before the build-infra changes are in place. The peculiarities of the current build have already been worked around and the new makefiles are useful, since it is easy to see where the warts are. Thus when build-infra is done, we will have a neat list of all things that needs to be cleaned up by moving source code and platform specific code in src/share is just one of many problems. I was hoping that when we start incrementally moving towards jigsaw-like structuring of the source, we can fix this then? When we rename directories, we lose a lot of information in the source control system. Necessary yes, but at least we should try to do it just once. As for the naming: posix is the name of a standardized API to unix-like operating systems. winapi is the name of the defacto API to windows systems. Using two trademarks instead of the actual names of the APIs would be silly. And you can run posix software on Windows by installing cygwin et al, and you can run winapi software on Linux by installing wine. But this is not the point, the point is that the built jvm will run primarily using winapi, or primarily using posix. No-one answered my question if we need to track the posix pedigree? I.e. gnu, sysv and bsd? //Fredrik From david.holmes at oracle.com Thu Nov 24 13:07:57 2011 From: david.holmes at oracle.com (David Holmes) Date: Fri, 25 Nov 2011 07:07:57 +1000 Subject: jdk/src/solaris - time to re-visit it? In-Reply-To: <4ECE573F.1050702@oracle.com> References: <4ECCE31D.90007@oracle.com> <4ECD5C26.1040303@oracle.com> <4ECE1867.8020302@oracle.com> <4ECE573F.1050702@oracle.com> Message-ID: <4ECEB22D.7040200@oracle.com> On 25/11/2011 12:39 AM, Fredrik ?hrstr?m wrote: > No-one answered my question if we need to track the posix pedigree? I.e. > gnu, sysv and bsd? I would hope this would not be necessary. There would have to be a "critical mass" of duplicated code (say between Solaris and BSD) to warrant a further refactor. Though maybe BSD and MacOSX are more tightly coupled. David From erik.joelsson at oracle.com Fri Nov 25 00:22:49 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 25 Nov 2011 08:22:49 +0000 Subject: hg: build-infra/jdk7: Fixed memory checking on solaris. Changed MSVCR100DLL find to look in Message-ID: <20111125082249.5A4814745C@hg.openjdk.java.net> Changeset: 957b5f9370d3 Author: erikj Date: 2011-11-25 09:20 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/957b5f9370d3 Fixed memory checking on solaris. Changed MSVCR100DLL find to look in VCINSTALLDIR. Added USING_SYSTEM_FT_LIB to configure so that we stop copying freetype lib on linux when we shouldn't. ! common/config/cores.m4 ! common/config/spec.gmk.in ! configure ! configure.ac From erik.joelsson at oracle.com Fri Nov 25 00:23:39 2011 From: erik.joelsson at oracle.com (erik.joelsson at oracle.com) Date: Fri, 25 Nov 2011 08:23:39 +0000 Subject: hg: build-infra/jdk7/jdk: Removed setting of USING_SYSTEM_FT_LIB since it's now handled by configure. Message-ID: <20111125082403.E87404745D@hg.openjdk.java.net> Changeset: 79ad12705a70 Author: erikj Date: 2011-11-25 09:21 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/79ad12705a70 Removed setting of USING_SYSTEM_FT_LIB since it's now handled by configure. ! make/common/Defs.gmk From fredrik.ohrstrom at oracle.com Fri Nov 25 00:42:29 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 25 Nov 2011 09:42:29 +0100 Subject: I nominate Per =?ISO-8859-1?Q?Lid=E9n_=28pliden=29_as_comm?= =?ISO-8859-1?Q?itter_to_build-infra-dev?= Message-ID: <4ECF54F5.4070401@oracle.com> I nominate Per Lid?n (pliden) as committer to build-infra-dev //Fredrik From fredrik.ohrstrom at oracle.com Fri Nov 25 02:11:26 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 25 Nov 2011 11:11:26 +0100 Subject: CFV: New build-infra Committers Message-ID: <4ECF69CE.80702@oracle.com> I hereby nominate the following people to build-infra Committer: Erik Joelsson Magnus Ihse-Bursie Robert Ottenhag These people have already been pushing patches to build-infra, and have the knowledge and experience to be committers. It was an oversight that they have not been nominated as committers before. As the project-lead Kelly Ohair specified, the build-infra project is a fast moving development sandbox to experiment and stabilize our build changes. Thus reviewing patches is not necessary. Votes are due by 12 noon CET, Friday December 9, 2011. Only current build-infra [1] are eligible to vote on this nomination. For Lazy Consensus voting instructions, see [2]. Fredrik ?hrstr?m [1] http://openjdk.java.net/census#build-infra [2] http://openjdk.java.net/projects#committer-vote From fredrik.ohrstrom at oracle.com Fri Nov 25 02:18:25 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Fri, 25 Nov 2011 11:18:25 +0100 Subject: I nominate Per =?ISO-8859-1?Q?Lid=E9n_=28pliden=29_as_?= =?ISO-8859-1?Q?committer_to_build-infra-dev?= In-Reply-To: <4ECF54F5.4070401@oracle.com> References: <4ECF54F5.4070401@oracle.com> Message-ID: <4ECF6B71.1090602@oracle.com> I withdraw my nomination for Per Lid?n since he has not yet published any patches externally. Even though he has done patches internally and has the experience to commit, we will wait until he has published 8 patches on build-infra-dev [1]. //Fredrik [1] http://openjdk.java.net/projects 2011-11-25 09:42, Fredrik ?hrstr?m skrev: > I nominate Per Lid?n (pliden) as committer to build-infra-dev > > //Fredrik From fredrik.ohrstrom at oracle.com Fri Nov 25 03:07:01 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 25 Nov 2011 11:07:01 +0000 Subject: hg: build-infra/jdk7: 2 new changesets Message-ID: <20111125110701.83E0447460@hg.openjdk.java.net> Changeset: 90b4eaab947a Author: ohrstrom Date: 2011-11-25 11:58 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/90b4eaab947a Added compareimage.sh and improved native compilation to support mixed C and C++ libraries. + common/bin/compareimage.sh - common/bin/diffjar.sh + common/bin/diffjarzip.sh ! common/make/JavaCompilation.gmk ! common/make/NativeCompilation.gmk Changeset: 5863d0750ed8 Author: ohrstrom Date: 2011-11-25 12:08 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/5863d0750ed8 Merge. From fredrik.ohrstrom at oracle.com Fri Nov 25 03:07:21 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 25 Nov 2011 11:07:21 +0000 Subject: hg: build-infra/jdk7/jdk: 2 new changesets Message-ID: <20111125110755.2AE1947461@hg.openjdk.java.net> Changeset: 3cbd9ea5eee5 Author: ohrstrom Date: 2011-11-25 11:58 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/3cbd9ea5eee5 Added jvmti demoes that had been forgotten. ! make/CompileDemos.gmk Changeset: f7b7c65f50b8 Author: ohrstrom Date: 2011-11-25 12:08 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/f7b7c65f50b8 Merge. From weijun.wang at oracle.com Fri Nov 25 03:16:23 2011 From: weijun.wang at oracle.com (Weijun Wang) Date: Fri, 25 Nov 2011 19:16:23 +0800 Subject: OT: jdk/build/solaris (was Re: jdk/src/solaris - time to re-visit it?) In-Reply-To: <4ECF74F5.1050609@oracle.com> References: <4ECCE31D.90007@oracle.com> <4ECD5C26.1040303@oracle.com> <4ECE1867.8020302@oracle.com> <4ECE573F.1050702@oracle.com> <4ECF74F5.1050609@oracle.com> Message-ID: <4ECF7907.4080907@oracle.com> Off topic. I don't have any suggestion on src and make at the moment but is it good to build platform-specific binaries into different directories and keep the common files at a single place? If so we can create a single merged image that is executable everywhere. -Max On 11/25/2011 06:59 PM, Alan Bateman wrote: > On 24/11/2011 14:39, Fredrik ?hrstr?m wrote: >> : >> It would be great to do the rename. However, we should not do that >> before the build-infra changes >> are in place. The peculiarities of the current build have already been >> worked around and the new >> makefiles are useful, since it is easy to see where the warts are. Thus >> when build-infra is done, we will >> have a neat list of all things that needs to be cleaned up by moving >> source code and platform >> specific code in src/share is just one of many problems. >> >> I was hoping that when we start incrementally moving towards jigsaw-like >> structuring of the source, >> we can fix this then? When we rename directories, we lose a lot of >> information in the source control system. >> Necessary yes, but at least we should try to do it just once. >> >> As for the naming: >> posix is the name of a standardized API to unix-like operating systems. >> winapi is the name of the defacto API to windows systems. >> >> Using two trademarks instead of the actual names of the APIs would be >> silly. >> >> And you can run posix software on Windows by installing cygwin et al, >> and you >> can run winapi software on Linux by installing wine. But this is not the >> point, >> the point is that the built jvm will run primarily using winapi, or >> primarily >> using posix. >> >> No-one answered my question if we need to track the posix pedigree? I.e. >> gnu, sysv and bsd? >> >> //Fredrik > I agree it's not a good time to do the renaming but I think it's good to > discuss and think about the how we might organize the code in the future. > > I don't have strong opinions on the names but "posix" doesn't seem quite > right just now as we have code in src/solaris/** that is making use of > APIs that aren't part of POSIX (I think this was Phil's point too). On > the pedigree then it might be better to cross that bridge when we come > to it, meaning that we could only really make use of it in conjunction > with refactoring work. > > You are right that the peculiarities have been worked around to date but > more have been proposed [1]. Maybe it would be prudent to hold off on > these changes until the new build is in place. > > -Alan. > > [1] > http://mail.openjdk.java.net/pipermail/nio-dev/2011-November/001466.html > From fredrik.ohrstrom at oracle.com Fri Nov 25 03:34:53 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 25 Nov 2011 11:34:53 +0000 Subject: hg: build-infra/jdk7/jdk: Added missing demo TransparentRuler and added missing cmm profiles. Message-ID: <20111125113504.6F80F47464@hg.openjdk.java.net> Changeset: 13c81807d54c Author: ohrstrom Date: 2011-11-25 12:36 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/13c81807d54c Added missing demo TransparentRuler and added missing cmm profiles. ! make/CompileDemos.gmk ! make/CopyFiles.gmk From fredrik.ohrstrom at oracle.com Fri Nov 25 08:11:28 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 25 Nov 2011 16:11:28 +0000 Subject: hg: build-infra/jdk7: Searching for msvcr100.dll up directory level above VCINSTALLDIR. Message-ID: <20111125161128.EFFD547466@hg.openjdk.java.net> Changeset: 9a2b28451ff8 Author: ohrstrom Date: 2011-11-25 16:55 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/9a2b28451ff8 Searching for msvcr100.dll up directory level above VCINSTALLDIR. Necessary for configure to work with VS Express. ! configure ! configure.ac From fredrik.ohrstrom at oracle.com Fri Nov 25 08:11:59 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 25 Nov 2011 16:11:59 +0000 Subject: hg: build-infra/jdk7/jdk: Added winapi specific libraries to hprof demo. Message-ID: <20111125161223.D943447467@hg.openjdk.java.net> Changeset: 4432921b9aa9 Author: ohrstrom Date: 2011-11-25 16:55 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/4432921b9aa9 Added winapi specific libraries to hprof demo. ! make/CompileDemos.gmk From fredrik.ohrstrom at oracle.com Fri Nov 25 10:45:35 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 25 Nov 2011 18:45:35 +0000 Subject: hg: build-infra/jdk7: Make sure the list of files is empty to start with. Message-ID: <20111125184535.9A75347469@hg.openjdk.java.net> Changeset: 854f31b51e64 Author: ohrstrom Date: 2011-11-25 19:47 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/854f31b51e64 Make sure the list of files is empty to start with. ! common/make/JavaCompilation.gmk From fredrik.ohrstrom at oracle.com Fri Nov 25 10:45:53 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 25 Nov 2011 18:45:53 +0000 Subject: hg: build-infra/jdk7/jdk: Fix the jpda demo. Message-ID: <20111125184610.EEBDA4746A@hg.openjdk.java.net> Changeset: 0d8c2ec18795 Author: ohrstrom Date: 2011-11-25 19:47 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/0d8c2ec18795 Fix the jpda demo. ! make/CompileDemos.gmk From fredrik.ohrstrom at oracle.com Fri Nov 25 13:04:42 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Fri, 25 Nov 2011 21:04:42 +0000 Subject: hg: build-infra/jdk7/langtools: Do not store final static unicode chars directly into the pubapi file. Message-ID: <20111125210446.A9E974746B@hg.openjdk.java.net> Changeset: 60eae3aa89ec Author: ohrstrom Date: 2011-11-25 22:06 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/60eae3aa89ec Do not store final static unicode chars directly into the pubapi file. Some unicode chars, like the surrogate pairs for example, do not survive a write to and subsequent read from the pubapi file. ! src/share/classes/com/sun/tools/javac/comp/ApiVisitor.java ! src/share/classes/com/sun/tools/javac/comp/Dependencies.java From fredrik.ohrstrom at oracle.com Sat Nov 26 09:16:40 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Sat, 26 Nov 2011 17:16:40 +0000 Subject: hg: build-infra/jdk7/jdk: Added final demo. Now the directory structure is identical to original build. Message-ID: <20111126171702.A84B74746C@hg.openjdk.java.net> Changeset: ce4754f8078d Author: ohrstrom Date: 2011-11-26 18:16 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/ce4754f8078d Added final demo. Now the directory structure is identical to original build. ! make/CompileDemos.gmk ! src/share/classes/java/lang/Object.java + src/share/demo/applets/WireFrame/Matrix.java - src/share/demo/applets/WireFrame/Matrix3D.java ! src/share/demo/applets/WireFrame/ThreeD.java From fredrik.ohrstrom at oracle.com Sat Nov 26 10:22:26 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Sat, 26 Nov 2011 18:22:26 +0000 Subject: hg: build-infra/jdk7/jdk: More demo fixes. Message-ID: <20111126182236.6B5DD4746D@hg.openjdk.java.net> Changeset: 8c96c38cfa98 Author: ohrstrom Date: 2011-11-26 19:24 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/8c96c38cfa98 More demo fixes. ! make/CompileDemos.gmk ! make/common/Release.gmk From fredrik.ohrstrom at oracle.com Sat Nov 26 10:22:56 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Sat, 26 Nov 2011 18:22:56 +0000 Subject: hg: build-infra/jdk7: Compare image now compare file names. Message-ID: <20111126182256.A8BD14746E@hg.openjdk.java.net> Changeset: da7bdee66b9a Author: ohrstrom Date: 2011-11-26 19:23 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/da7bdee66b9a Compare image now compare file names. ! common/bin/compareimage.sh From fredrik.ohrstrom at oracle.com Sat Nov 26 12:32:27 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Sat, 26 Nov 2011 20:32:27 +0000 Subject: hg: build-infra/jdk7/jdk: The zipfs.jar is built from DEMO sources and installed in jre/lib/ext! Woot? Message-ID: <20111126203236.D0D144746F@hg.openjdk.java.net> Changeset: abcfa5ff7fff Author: ohrstrom Date: 2011-11-26 21:33 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/abcfa5ff7fff The zipfs.jar is built from DEMO sources and installed in jre/lib/ext! Woot? Also hack to enable compilation of the wireframe demo. Filenames and directories are now identical. The file contents might not be though. ! make/CompileDemos.gmk ! make/Setup.gmk - src/share/demo/applets/WireFrame/Matrix.java + src/share/demo/applets/WireFrame/Matrix3D.java ! src/share/demo/applets/WireFrame/ThreeD.java From fredrik.ohrstrom at oracle.com Sat Nov 26 14:39:53 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Sat, 26 Nov 2011 22:39:53 +0000 Subject: hg: build-infra/jdk7/jdk: Remove legacy launcher makefiles. Message-ID: <20111126224003.7DB5447470@hg.openjdk.java.net> Changeset: be22cc3b267d Author: ohrstrom Date: 2011-11-26 23:41 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/be22cc3b267d Remove legacy launcher makefiles. ! make/CompileLaunchers.gmk ! make/LegacyMakefiles.gmk - make/launchers/Makefile - make/launchers/Makefile.launcher From fredrik.ohrstrom at oracle.com Sat Nov 26 15:13:34 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Sat, 26 Nov 2011 23:13:34 +0000 Subject: hg: build-infra/jdk7/jdk: Removed legacy makefiles. Message-ID: <20111126231343.E3A3147471@hg.openjdk.java.net> Changeset: 862bba741bf2 Author: ohrstrom Date: 2011-11-27 00:15 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/862bba741bf2 Removed legacy makefiles. ! make/CompileLaunchers.gmk ! make/com/sun/Makefile - make/com/sun/nio/sctp/Exportedfiles.gmk - make/com/sun/nio/sctp/FILES_c.gmk - make/com/sun/nio/sctp/FILES_java.gmk - make/com/sun/nio/sctp/mapfile-vers - make/com/sun/script/Makefile - make/com/sun/tools/attach/mapfile-linux - make/com/sun/tools/attach/mapfile-solaris ! make/sun/security/tools/Makefile From fredrik.ohrstrom at oracle.com Mon Nov 28 02:33:34 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Mon, 28 Nov 2011 10:33:34 +0000 Subject: hg: build-infra/jdk7: ./common/bin/compareimags.sh OLD_IMAGE NEW_IMAGES Message-ID: <20111128103334.7EFE947473@hg.openjdk.java.net> Changeset: da7637c6bcef Author: ohrstrom Date: 2011-11-28 11:35 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/da7637c6bcef ./common/bin/compareimags.sh OLD_IMAGE NEW_IMAGES Now compares directory structure, names and contents of zip archive. ! common/bin/compareimage.sh ! common/bin/diffjarzip.sh From per.liden at oracle.com Mon Nov 28 03:48:47 2011 From: per.liden at oracle.com (=?ISO-8859-1?Q?Per_Lid=E9n?=) Date: Mon, 28 Nov 2011 12:48:47 +0100 Subject: [PATCH] Fix for typo in ./configure help text Message-ID: <4ED3751F.70303@oracle.com> Patch for fixing --with-num_cores typo in ./configure help text. /Per From per.liden at oracle.com Mon Nov 28 03:52:28 2011 From: per.liden at oracle.com (=?ISO-8859-1?Q?Per_Lid=E9n?=) Date: Mon, 28 Nov 2011 12:52:28 +0100 Subject: [PATCH] Fix for typo in ./configure help text In-Reply-To: <4ED3751F.70303@oracle.com> References: <4ED3751F.70303@oracle.com> Message-ID: <4ED375FC.80601@oracle.com> Hmm, looks like the attachment was stripped for some reason. Inlining patch: diff --git a/configure.ac b/configure.ac --- a/configure.ac +++ b/configure.ac @@ -125,7 +125,7 @@ AC_SUBST(DATE_WHEN_CONFIGURED) # How many cores do we have on this build system? -AC_ARG_WITH(num-cores,[AS_HELP_STRING([--with-num_cores=32], +AC_ARG_WITH(num-cores,[AS_HELP_STRING([--with-num-cores=32], [specify the number of cores in the build system.])]) if test "x$with_num_cores" = x; then # The number of cores were not specified, try to probe them. /Per On 2011-11-28 12:48, Per Lid?n wrote: > Patch for fixing --with-num_cores typo in ./configure help text. > > /Per From fredrik.ohrstrom at oracle.com Mon Nov 28 07:42:02 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Mon, 28 Nov 2011 15:42:02 +0000 Subject: hg: build-infra/jdk7: More work on compare images. Message-ID: <20111128154202.565BF47478@hg.openjdk.java.net> Changeset: 49e19c1e9ffc Author: ohrstrom Date: 2011-11-28 16:43 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/49e19c1e9ffc More work on compare images. ! common/bin/compareimage.sh ! common/bin/diffjarzip.sh ! common/make/JavaCompilation.gmk ! version.numbers From fredrik.ohrstrom at oracle.com Mon Nov 28 07:43:04 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Mon, 28 Nov 2011 15:43:04 +0000 Subject: hg: build-infra/jdk7/jdk: More work on compare images, now going through the demos. Message-ID: <20111128154323.EC92147479@hg.openjdk.java.net> Changeset: a4d4e3411e29 Author: ohrstrom Date: 2011-11-28 16:43 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/a4d4e3411e29 More work on compare images, now going through the demos. ! make/CompileDemos.gmk ! make/CompileJavaClasses.gmk ! make/common/Release.gmk From tim.bell at gmail.com Mon Nov 28 07:53:20 2011 From: tim.bell at gmail.com (Tim Bell) Date: Mon, 28 Nov 2011 07:53:20 -0800 Subject: [PATCH] to common/bin/hide_important_warnings_from_javac.sh for OpenSolaris Message-ID: Hi All I know this script is a short time measure that will eventually go away. I'd still like to use it on OpenSolaris as well as on Linux. Fredrik, as build-infra committer, could sponsor this? Thanks- Tim Bell % hg out comparing with http://hg.openjdk.java.net/build-infra/jdk7/ searching for changes changeset: 431:c8572af8c1d0 tag: tip user: tbell date: Mon Nov 28 07:43:25 2011 -0800 summary: Use /usr/bin/ggrep on OpenSolaris % hg export -g 431:c8572af8c1d0 # HG changeset patch # User tbell # Date 1322495005 28800 # Node ID c8572af8c1d0cbee093f8695b8964dbd7823a1a2 # Parent da7bdee66b9afc26949f8aae17391f2ac7313b96 Use /usr/bin/ggrep on OpenSolaris Contributed-by: Tim Bell diff --git a/common/bin/hide_important_warnings_from_javac.sh b/common/bin/hide_important_warnings_from_javac.sh --- a/common/bin/hide_important_warnings_from_javac.sh +++ b/common/bin/hide_important_warnings_from_javac.sh @@ -1,7 +1,18 @@ -grep --line-buffered -v "Note: Some input files use or override a deprecated API." | \ -grep --line-buffered -v "Note: Recompile with -Xlint:deprecation for details." | \ -grep --line-buffered -v "Note: Some input files use unchecked or unsafe operations." | \ -grep --line-buffered -v "Note: Recompile with -Xlint:unchecked for details." | \ -grep --line-buffered -v " warning" | \ -grep --line-buffered -v "uses or overrides a deprecated API." | \ -grep --line-buffered -v "uses unchecked or unsafe operations." +#!/bin/sh +if [ -x /usr/bin/ggrep ] ; then + # Gnu grep on Solaris + # (reference configure and build/solaris-i586-clientANDserver-release/spec.gmk + GREP=/usr/bin/ggrep +else + GREP=/usr/bin/grep +fi +# +EXP="Note: Some input files use or override a deprecated API." +EXP="${EXP}|Note: Recompile with -Xlint:deprecation for details." +EXP="${EXP}|Note: Some input files use unchecked or unsafe operations." +EXP="${EXP}|Note: Recompile with -Xlint:unchecked for details." +EXP="${EXP}| warning" +EXP="${EXP}|uses or overrides a deprecated API." +EXP="${EXP}|uses unchecked or unsafe operations." +# +${GREP} --line-buffered -v -E "${EXP}" From tim.bell at gmail.com Mon Nov 28 08:05:41 2011 From: tim.bell at gmail.com (Tim Bell) Date: Mon, 28 Nov 2011 08:05:41 -0800 Subject: [PATCH] to common/make/JavaCompilation.gmk Use $(TOOL) macros defined by configure and spec.gmk Message-ID: Hi All These changes in 'common/make/JavaCompilation.gmk' were started because I needed to use the $(AWK) provided by configure. The legacy awk found by default on Solaris was not doing the right thing, instead throwing out errors like this: awk: string too long near line 1 awk: syntax error near line 1 awk: illegal statement near line 1 Once I converted awk to $(AWK), I did the same for sed, find, and so forth in this file, ending up with minor changes to quite a few lines. Fredrik, as build-infra committer, could you sponsor this? I put a webrev here, if that is an easier way to get the changes: http://cr.openjdk.java.net/~tbell/build-infra/webrev.00 Thanks- Tim Bell hg export -g 432:53b96caba8cb # HG changeset patch # User tbell # Date 1322495967 28800 # Node ID 53b96caba8cb337f8ba075549bb01f7e0776a7cd # Parent c8572af8c1d0cbee093f8695b8964dbd7823a1a2 Use $(TOOL) macros defined by configure and spec.gmk Contributed-by: Tim Bell diff --git a/common/make/JavaCompilation.gmk b/common/make/JavaCompilation.gmk --- a/common/make/JavaCompilation.gmk +++ b/common/make/JavaCompilation.gmk @@ -153,46 +153,46 @@ # The capture contents macro finds all files (matching the patterns, typically # *.class and *.prp) that are newer than the jar-file, ie the new content to be put into the jar. - $1_CAPTURE_CONTENTS=$$(foreach src,$$($1_SRCS),($(FIND) $$(src) -type f -a \( $$($1_PATTERNS) \) -a -newer $$@ | sed 's|$$(src)/||g' > $$(src)/_the.$$($1_JARNAME)_contents) && ) + $1_CAPTURE_CONTENTS=$$(foreach src,$$($1_SRCS),($(FIND) $$(src) -type f -a \( $$($1_PATTERNS) \) -a -newer $$@ | $(SED) 's|$$(src)/||g' > $$(src)/_the.$$($1_JARNAME)_contents) && ) # The capture metainf macro finds all files below the META-INF directory that are newer than the jar-file. ifeq (,$$($1_SKIP_METAINF)) - $1_CAPTURE_METAINF =$$(foreach src,$$($1_SRCS),($(FIND) $$(src)/META-INF -type f -a -newer $$@ 2> /dev/null | sed 's|$$(src)/||g' >> $$(src)/_the.$$($1_JARNAME)_contents ) && ) + $1_CAPTURE_METAINF =$$(foreach src,$$($1_SRCS),($(FIND) $$(src)/META-INF -type f -a -newer $$@ 2> /dev/null | $(SED) 's|$$(src)/||g' >> $$(src)/_the.$$($1_JARNAME)_contents ) && ) endif # The capture deletes macro finds all deleted files and concatenates them. The resulting file # tells us what to remove from the jar-file. - $1_CAPTURE_DELETES=$$(foreach src,$$($1_SRCS),($(FIND) $$(src) -name _the.package.deleted -newer $$@ -exec sed 's|$$(src)||g' \{\} >> $$($1_DELETES_FILE) \;) &&) + $1_CAPTURE_DELETES=$$(foreach src,$$($1_SRCS),($(FIND) $$(src) -name _the.package.deleted -newer $$@ -exec $(SED) 's|$$(src)||g' \{\} >> $$($1_DELETES_FILE) \;) &&) # The capture pubapi notifications scans for pubapi change notifications. If such notifications are # found, then we will build the classes leading up to the jar again, to take into account the new timestamps # on the changed pubapi files. $1_CAPTURE_PUBAPI_NOTIFICATIONS=$$(foreach src,$$($1_SRCS),\ - (cd $$(src) && \ + ($(CD) $$(src) && \ $(FIND) . -name _the.package.api.notify -exec dirname \{\} \; >> $$($1_PUBAPI_NOTIFICATIONS_FILE) ; \ true) &&) # The capture nativeapi macro scans for native api change notificiations. If such notifications are # found, then we will run javah on the changed classes. It also collects all classes with native methods # to be used to find out which classes no longer has native methods, to trigger deletion of those .h files. $1_CAPTURE_NATIVEAPI=$$(foreach src,$$($1_SRCS),\ - (cd $$(src) && \ - $(FIND) . -name _the.package.native.notify | sed 's/package.native.notify/package.native/' | \ - xargs cat | grep '^TYPE ' | sed 's/.*TYPE //' >> $$($1_NATIVEAPI_NOTIFICATIONS_FILE) ; \ - $(FIND) . -name _the.package.native -exec cat \{\} \; | $(SED) -n 's/^TYPE //p' >> $$($1_NATIVEAPI_FILE) ; \ + ($(CD) $$(src) && \ + $(FIND) . -name _the.package.native.notify | $(SED) 's/package.native.notify/package.native/' | \ + $(XARGS) $(CAT) | $(GREP) '^TYPE ' | $(SED) 's/.*TYPE //' >> $$($1_NATIVEAPI_NOTIFICATIONS_FILE) ; \ + $(FIND) . -name _the.package.native -exec $(CAT) \{\} \; | $(SED) -n 's/^TYPE //p' >> $$($1_NATIVEAPI_FILE) ; \ true) &&) # The update contents macro updates the jar file with the previously capture contents. $1_UPDATE_CONTENTS=$$(foreach src,$$($1_SRCS),\ - (cd $$(src) && \ + ($(CD) $$(src) && \ if [ -s _the.$$($1_JARNAME)_contents ]; then \ - echo " updating" `wc -l _the.$$($1_JARNAME)_contents | awk '{ print $$$$1 }'` files && \ + $(ECHO) " updating" `$(WC) -l _the.$$($1_JARNAME)_contents | $(AWK) '{ print $$$$1 }'` files && \ $(JAR) uf $$@ @_the.$$($1_JARNAME)_contents; \ fi) &&) # The s-variants of the above macros are used when the jar is created from scratch. $1_SCAPTURE_CONTENTS=$$(foreach src,$$($1_SRCS),\ - ($(FIND) $$(src) -type f -a \( $$($1_PATTERNS) \) | sed 's|$$(src)/||g' > $$(src)/_the.$$($1_JARNAME)_contents) && ) + ($(FIND) $$(src) -type f -a \( $$($1_PATTERNS) \) | $(SED) 's|$$(src)/||g' > $$(src)/_the.$$($1_JARNAME)_contents) && ) ifeq (,$$($1_SKIP_METAINF)) $1_SCAPTURE_METAINF=$$(foreach src,$$($1_SRCS),\ - ($(FIND) $$(src)/META-INF -type f 2> /dev/null | sed 's|$$(src)/||g' >> $$(src)/_the.$$($1_JARNAME)_contents) && ) + ($(FIND) $$(src)/META-INF -type f 2> /dev/null | $(SED) 's|$$(src)/||g' >> $$(src)/_the.$$($1_JARNAME)_contents) && ) endif $1_SUPDATE_CONTENTS=$$(foreach src,$$($1_SRCS),\ - (cd $$(src) && $(JAR) uf $$@ @$$(src)/_the.$$($1_JARNAME)_contents) &&) + ($(CD) $$(src) && $(JAR) uf $$@ @$$(src)/_the.$$($1_JARNAME)_contents) &&) # The TOUCH macro is used to make sure all timestamps are identical for package files and the pubapi files. # If we do not do this, we get random recompilations, the next time we run make, since the order of package building is random, # ie independent of package --dependes on-> public api of another package. This is of course @@ -206,56 +206,56 @@ # Here is the rule that creates/updates the jar file. $$($1_JAR) : $2 $(MKDIR) -p $$($1_BIN) - echo $$($1_MANIFEST) > $$($1_MANIFEST_FILE) + $(ECHO) $$($1_MANIFEST) > $$($1_MANIFEST_FILE) +if [ -s $$@ ]; then \ - rm -rf $$($1_PUBAPI_NOTIFICATIONS_FILE) && \ + $(RM) -r $$($1_PUBAPI_NOTIFICATIONS_FILE) && \ $$($1_CAPTURE_PUBAPI_NOTIFICATIONS) \ if [ -s $$($1_PUBAPI_NOTIFICATIONS_FILE) ]; then \ - echo Public api change detected in: && \ - cat $$($1_PUBAPI_NOTIFICATIONS_FILE) | tr '/' '.' | sed 's|^..||g' | sed 's|\.$$$$||g' | awk '{print " "$$$$1}' && \ + $(ECHO) Public api change detected in: && \ + $(CAT) $$($1_PUBAPI_NOTIFICATIONS_FILE) | $(TR) '/' '.' | $(SED) 's|^..||g' | $(SED) 's|\.$$$$||g' | $(AWK) '{print " "$$$$1}' && \ $$(foreach src,$$($1_SRCS),($(FIND) $$(src) -name _the.package.api.notify $(FIND_DELETE); true) &&) \ $(MAKE) -f $(word 1,$(MAKEFILE_LIST)) $$($1_JAR) ; \ else \ - echo Modifying $$($1_NAME) && \ + $(ECHO) Modifying $$($1_NAME) && \ $$($1_CAPTURE_CONTENTS) \ $$($1_CAPTURE_METAINF) \ - rm -f $$($1_DELETES_FILE) && \ + $(RM) $$($1_DELETES_FILE) && \ $$($1_CAPTURE_DELETES) \ - cat $$($1_DELETES_FILE) > $$($1_DELETESS_FILE) && \ + $(CAT) $$($1_DELETES_FILE) > $$($1_DELETESS_FILE) && \ if [ -s $$($1_DELETESS_FILE) ]; then \ - echo " deleting" `wc -l $$($1_DELETESS_FILE) | awk '{ print $$$$1 }'` files && \ - $(ZIP) -q -d $$@ `cat $$($1_DELETESS_FILE)` ; \ + $(ECHO) " deleting" `$(WC) -l $$($1_DELETESS_FILE) | $(AWK) '{ print $$$$1 }'` files && \ + $(ZIP) -q -d $$@ `$(CAT) $$($1_DELETESS_FILE)` ; \ fi && \ $$($1_UPDATE_CONTENTS) true && \ $$($1_TOUCH_API_FILES) true && \ - rm -rf $$($1_NATIVEAPI_NOTIFICATIONS_FILE) $$($1_NATIVEAPI_FILE) && \ + $(RM) -r $$($1_NATIVEAPI_NOTIFICATIONS_FILE) $$($1_NATIVEAPI_FILE) && \ $$($1_CAPTURE_NATIVEAPI) true && \ if [ "x$$($1_JAVAH)" != "x" ] && [ -s $$($1_NATIVEAPI_NOTIFICATIONS_FILE) ]; then \ - echo Native api change detected in: && cat $$($1_NATIVEAPI_NOTIFICATIONS_FILE) && \ + $(ECHO) Native api change detected in: && $(CAT) $$($1_NATIVEAPI_NOTIFICATIONS_FILE) && \ $$($1_JVM) $$($1_JAVAH) "-Xbootclasspath/p:$$($1_JAR)" -d $$($1_HEADERS) @$$($1_NATIVEAPI_NOTIFICATIONS_FILE) ; \ fi && \ - touch $$($1_NATIVEAPI_FILE)_prev ; \ + $(TOUCH) $$($1_NATIVEAPI_FILE)_prev ; \ ($(GREP) -xvf $$($1_NATIVEAPI_FILE) $$($1_NATIVEAPI_FILE)_prev > $$($1_NATIVEAPI_FILE)_deleted; true) && \ - cp $$($1_NATIVEAPI_FILE) $$($1_NATIVEAPI_FILE)_prev && \ + $(CP) $$($1_NATIVEAPI_FILE) $$($1_NATIVEAPI_FILE)_prev && \ if [ -s $$($1_NATIVEAPI_FILE)_deleted ]; then \ - echo Native methods dropped from classes: && cat $$($1_NATIVEAPI_FILE)_deleted && \ - $(RM) `cat $$($1_NATIVEAPI_FILE)_deleted | sed -e 's|\.|_|g' -e 's|.*|$$($1_HEADERS)/&.h $$($1_HEADERS)/&_*|'` ; \ + $(ECHO) Native methods dropped from classes: && $(CAT) $$($1_NATIVEAPI_FILE)_deleted && \ + $(RM) `$(CAT) $$($1_NATIVEAPI_FILE)_deleted | $(SED) -e 's|\.|_|g' -e 's|.*|$$($1_HEADERS)/&.h $$($1_HEADERS)/&_*|'` ; \ fi && \ $$(foreach src,$$($1_SRCS),($(FIND) $$(src) -name _the.package.api.notify $(FIND_DELETE); true) &&) true ; \ fi ; \ else \ - echo Creating $$($1_NAME) && $(JAR) cfm $$@ $$($1_MANIFEST_FILE) && \ + $(ECHO) Creating $$($1_NAME) && $(JAR) cfm $$@ $$($1_MANIFEST_FILE) && \ $$($1_SCAPTURE_CONTENTS) \ $$($1_SCAPTURE_METAINF) \ $$($1_SUPDATE_CONTENTS) \ $$($1_TOUCH_API_FILES) true && \ - rm -rf $$($1_NATIVEAPI_NOTIFICATIONS_FILE) $$($1_NATIVEAPI_FILE) && \ + $(RM) -r $$($1_NATIVEAPI_NOTIFICATIONS_FILE) $$($1_NATIVEAPI_FILE) && \ $$($1_CAPTURE_NATIVEAPI) true && \ if [ "x$$($1_JAVAH)" != "x" ] && [ -s $$($1_NATIVEAPI_FILE) ]; then \ - echo Generating native api headers for `cat $$($1_NATIVEAPI_FILE) | wc -l` classes && \ + $(ECHO) Generating native api headers for `$(CAT) $$($1_NATIVEAPI_FILE) | $(WC) -l` classes && \ $(RM) $$($1_HEADERS)/*.h && \ $$($1_JVM) $$($1_JAVAH) "-Xbootclasspath/p:$$($1_JAR)" -d $$($1_HEADERS) @$$($1_NATIVEAPI_FILE) && \ - cp $$($1_NATIVEAPI_FILE) $$($1_NATIVEAPI_FILE)_prev ; \ + $(CP) $$($1_NATIVEAPI_FILE) $$($1_NATIVEAPI_FILE)_prev ; \ fi && \ $$(foreach src,$$($1_SRCS),($(FIND) $$(src) -name "*.notify" $(FIND_DELETE); true) &&) true ; \ fi; @@ -263,7 +263,7 @@ endef define append_to - echo "$1" >> $2 + $(ECHO) "$1" >> $2 endef define SetupZipArchive @@ -300,9 +300,9 @@ # I.e. the zip -i and -x options should match the filtering done in the makefile. $$($1_ZIP) : $$($1_ALL_SRCS) $(MKDIR) -p $$(@D) - echo Updating $$($1_NAME) - $$(foreach i,$$($1_SRC),(cd $$i && $(ZIP) -qru $$@ . $$($1_ZIP_INCLUDES) $$($1_ZIP_EXCLUDES) -x \*_the.\*) ;) true - touch $$@ + $(ECHO) Updating $$($1_NAME) + $$(foreach i,$$($1_SRC),($(CD) $$i && $(ZIP) -qru $$@ . $$($1_ZIP_INCLUDES) $$($1_ZIP_EXCLUDES) -x \*_the.\*) ;) true + $(TOUCH) $$@ endef define add_file_to_copy @@ -407,12 +407,12 @@ # The next command rewrites the deps output from javac into a proper makefile dependency. # The dependencies are always to an .api file generated by the pubapi option above. # This is necessary since java package dependencies are almost always circular. - $2_APPEND_DEPS:=(cat $$($2_PACKAGE_BDIR)_the.package.deps | tr '.' '/' | awk '{ print "$4/" $$$$3 }' | sort > $$($2_PACKAGE_BDIR)_the.package.ddd && $(GREP) -f $$($2_PACKAGE_BDIR)_the.package.ddd $5 | awk '{ print "$(dir $2)_the.package : " $$$$1 "_the.package.api" }' > $$($2_PACKAGE_BDIR)_the.package.dddd ; true) + $2_APPEND_DEPS:=($(CAT) $$($2_PACKAGE_BDIR)_the.package.deps | $(TR) '.' '/' | $(AWK) '{ print "$4/" $$$$3 }' | sort > $$($2_PACKAGE_BDIR)_the.package.ddd && $(GREP) -f $$($2_PACKAGE_BDIR)_the.package.ddd $5 | $(AWK) '{ print "$(dir $2)_the.package : " $$$$1 "_the.package.api" }' > $$($2_PACKAGE_BDIR)_the.package.dddd ; true) else # If not using dependencies, use $2 as fallback to trigger regeneration of javah header files. # This will generate a surplus of header files, but this does not hurt compilation. $2_NATIVEAPICHANGE_TRIGGER:=$2 - $2_FETCH_NATIVEAPICHANGE_CLASSES:=cat $$($2_PACKAGE_BDIR)_the.package.now|grep -v '\$$$$'|sed -e 's|$4/||g'|sed 's|.class||g'| tr '/' '.' + $2_FETCH_NATIVEAPICHANGE_CLASSES:=$(CAT) $$($2_PACKAGE_BDIR)_the.package.now|$(GREP) -v '\$$$$'|$(SED) -e 's|$4/||g'|$(SED) 's|.class||g'| $(TR) '/' '.' endif # The _the.package file is dependent on the java files inside the package. @@ -422,19 +422,19 @@ $(MKDIR) -p $$($2_PACKAGE_BDIR) $(RM) $2.tmp $$(call ListPathsSafely,$2_PACKAGE_SRCS,\n, >> $2.tmp) - echo $$($2_PACKAGE_BDIR)*.class | $(GREP) -v \*.class | tr ' ' '\n' > $$($2_PACKAGE_BDIR)_the.package.prev - rm -f $$($2_PACKAGE_BDIR)*.class $$($2_PACKAGE_BDIR)*.notify $$($2_PACKAGE_BDIR)*.deleted - echo Compiling `wc $2.tmp | tr -s ' ' | cut -f 2 -d ' '` files in package $(patsubst $4/%/,%,$(dir $2.tmp)) + $(ECHO) $$($2_PACKAGE_BDIR)*.class | $(GREP) -v \*.class | $(TR) ' ' '\n' > $$($2_PACKAGE_BDIR)_the.package.prev + $(RM) $$($2_PACKAGE_BDIR)*.class $$($2_PACKAGE_BDIR)*.notify $$($2_PACKAGE_BDIR)*.deleted + $(ECHO) Compiling `$(WC) $2.tmp | $(TR) -s ' ' | $(CUT) -f 2 -d ' '` files in package $(patsubst $4/%/,%,$(dir $2.tmp)) $9 $$($2_REMOTE) $$($2_DEPS) $$($2_PUBAPI) $$($2_NATIVEAPI) $(10) -implicit:none -sourcepath "$$($2_SRCROOTSC)" -d $4 @$2.tmp - echo $$($2_PACKAGE_BDIR)*.class | $(GREP) -v \*.class | tr ' ' '\n' > $$($2_PACKAGE_BDIR)_the.package.now + $(ECHO) $$($2_PACKAGE_BDIR)*.class | $(GREP) -v \*.class | $(TR) ' ' '\n' > $$($2_PACKAGE_BDIR)_the.package.now ($(GREP) -xvf $$($2_PACKAGE_BDIR)_the.package.now $$($2_PACKAGE_BDIR)_the.package.prev > $$($2_PACKAGE_BDIR)_the.package.deleted;true) - echo $1_CLASSES += `cat $$($2_PACKAGE_BDIR)_the.package.now` | \ - sed 's/\$$$$/\$$$$\$$$$/g' > $$($2_PACKAGE_BDIR)_the.package.d - echo $1_JAVAS += $$($2_PACKAGE_SRCS) >> $$($2_PACKAGE_BDIR)_the.package.d - echo $2_NOTIFIED:=true > $$($2_PACKAGE_BDIR)_the.package.notify + $(ECHO) $1_CLASSES += `$(CAT) $$($2_PACKAGE_BDIR)_the.package.now` | \ + $(SED) 's/\$$$$/\$$$$\$$$$/g' > $$($2_PACKAGE_BDIR)_the.package.d + $(ECHO) $1_JAVAS += $$($2_PACKAGE_SRCS) >> $$($2_PACKAGE_BDIR)_the.package.d + $(ECHO) $2_NOTIFIED:=true > $$($2_PACKAGE_BDIR)_the.package.notify $$($2_APPEND_DEPS) $$($2_COPY_FILES) - mv -f $2.tmp $2 + $(MV) -f $2.tmp $2 endef define remove_string @@ -592,16 +592,16 @@ $(MKDIR) -p $$(@D) $(RM) $$($1_BIN)/_the.batch $$($1_BIN)/_the.batch.tmp $$(call ListPathsSafely,$1_SRCS,\n, >> $$($1_BIN)/_the.batch.tmp) - echo Compiling `wc $$($1_BIN)/_the.batch.tmp | tr -s ' ' | cut -f 2 -d ' '` files in batch $1 + $(ECHO) Compiling `$(WC) $$($1_BIN)/_the.batch.tmp | $(TR) -s ' ' | $(CUT) -f 2 -d ' '` files in batch $1 ($$($1_JVM) $$($1_JAVAC) $$($1_FLAGS) -implicit:none -sourcepath "$$($1_SRCROOTSC)" -d $$($1_BIN) @$$($1_BIN)/_the.batch.tmp && \ $$(if $$($1_JAVAH),\ - cat $$($1_BIN)/_the.batch.tmp | $(XARGS) $(GREP) -E "[[:space:]]native[[:space:]].*;|ForceNativeHeader" |\ + $(CAT) $$($1_BIN)/_the.batch.tmp | $(XARGS) $(GREP) -E "[[:space:]]native[[:space:]].*;|ForceNativeHeader" |\ $(GREP) -v '*' | $(GREP) -v '//' | $(CUT) -f 1 -d ':' | $(SORT) -u |\ $(SED) $$(REWRITE_INTO_CLASSES) > $$($1_BIN)/_the.batch.natives && \ if test -s $$($1_BIN)/_the.batch.natives; then \ $$($1_JVM) $$($1_JAVAH) "-Xbootclasspath/p:$$($1_BIN)" -d $$($1_HEADERS) @$$($1_BIN)/_the.batch.natives ; \ fi &&) \ - mv $$($1_BIN)/_the.batch.tmp $$($1_BIN)/_the.batch) + $(MV) $$($1_BIN)/_the.batch.tmp $$($1_BIN)/_the.batch) else # Ok, we have a modern javac server running! # Since a single Java file can generate zero to an infinity number of .class files @@ -650,7 +650,7 @@ # $$(info MESSED UP PACKAGES $$($1_FOO)) # endif - $$(shell $(RM) -f $$(addsuffix _the.package,$$(sort $$($1_PKGS_MISSING_CLASSES) \ + $$(shell $(RM) $$(addsuffix _the.package,$$(sort $$($1_PKGS_MISSING_CLASSES) \ $$($1_PKGS_SUPERFLUOUS_CLASSES) \ $$($1_PKGS_MISSING_JAVAS)))) @@ -679,5 +679,3 @@ endif endef - - From fredrik.ohrstrom at oracle.com Mon Nov 28 08:31:20 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Mon, 28 Nov 2011 16:31:20 +0000 Subject: hg: build-infra/jdk7: Use /usr/bin/ggrep on OpenSolaris Message-ID: <20111128163121.11D3E4747B@hg.openjdk.java.net> Changeset: 6f09ea841fcc Author: tbell Date: 2011-11-28 07:43 -0800 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/6f09ea841fcc Use /usr/bin/ggrep on OpenSolaris Contributed-by: Tim Bell ! common/bin/hide_important_warnings_from_javac.sh From fredrik.ohrstrom at oracle.com Mon Nov 28 08:58:08 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Mon, 28 Nov 2011 16:58:08 +0000 Subject: hg: build-infra/jdk7: Use $(TOOL) macros defined by configure and spec.gmk Message-ID: <20111128165808.C1A704747C@hg.openjdk.java.net> Changeset: 9fe51a565fd4 Author: ohrstrom Date: 2011-11-28 17:59 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/9fe51a565fd4 Use $(TOOL) macros defined by configure and spec.gmk Contributed-by: Tim Bell ! common/make/JavaCompilation.gmk From fredrik.ohrstrom at oracle.com Tue Nov 29 03:16:12 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 29 Nov 2011 11:16:12 +0000 Subject: hg: build-infra/jdk7: Removing $(CD) and using the shell builtin cd directly. Message-ID: <20111129111612.BE1E34748A@hg.openjdk.java.net> Changeset: dd8ba2ead5e0 Author: ohrstrom Date: 2011-11-29 12:17 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/dd8ba2ead5e0 Removing $(CD) and using the shell builtin cd directly. ! common/config/spec.gmk.in ! common/make/JavaCompilation.gmk ! configure ! configure.ac From fredrik.ohrstrom at oracle.com Tue Nov 29 06:51:04 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 29 Nov 2011 14:51:04 +0000 Subject: hg: build-infra/jdk7: Improved compareimages.sh now compares contents of zips, jars, libraries Message-ID: <20111129145104.915694748D@hg.openjdk.java.net> Changeset: 507374d896b3 Author: ohrstrom Date: 2011-11-29 15:52 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/507374d896b3 Improved compareimages.sh now compares contents of zips,jars,libraries and executables. ! common/bin/compareimage.sh + common/bin/diffexec.sh ! common/bin/diffjarzip.sh ! common/bin/difflib.sh ! common/make/JavaCompilation.gmk From fredrik.ohrstrom at oracle.com Tue Nov 29 06:51:20 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 29 Nov 2011 14:51:20 +0000 Subject: hg: build-infra/jdk7/jdk: More cleanups in demo. Message-ID: <20111129145148.65A0C4748E@hg.openjdk.java.net> Changeset: f379a3568ba6 Author: ohrstrom Date: 2011-11-29 15:52 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/f379a3568ba6 More cleanups in demo. ! make/CompileDemos.gmk ! src/share/classes/java/lang/Object.java From per.liden at oracle.com Tue Nov 29 07:29:50 2011 From: per.liden at oracle.com (=?ISO-8859-1?Q?Per_Lid=E9n?=) Date: Tue, 29 Nov 2011 16:29:50 +0100 Subject: [PATCH]: Limit number of compiler instances in JavacServer to avoid OOM Message-ID: <4ED4FA6E.4030201@oracle.com> Hi all, When I'm building on a 16 core machine the JavacServer will currently OOM. On this machine the ./configure script will correctly figure out that we should allow a maximum of 7 instances with the given 3G heap, and sets JAVAC_SERVER_CORES accordingly. However, JavacServer later fails to properly limit the number of compiler instances to JAVAC_SERVER_CORES, instead allowing a new compiler instances to be created for each concurrent connection it accepts (which will be equal to NUM_CORES, i.e. 16 in this case), resulting in an OOM. The JAVAC_SERVER_CORES value currently only dictates how many compilers can run concurrently, not the number of instances it's allowed to create. The patch fixes this by making sure Handler.grabHandle() never grows the handler pool to more than JAVAC_SERVER_CORES (which propagates into JavacServer as "poolsize"). Further, since the thread accepting incomming connections now risk blocking for a handler to become available, we need to increase the backlog on the server socket to avoid connection failures in the clients. This number should probably be something like NUM_CORE (or we should spawn a thread for each connection we accept), but right now I just increased it to 128. Keeping it at default 0 will not work. diff --git a/src/share/classes/com/sun/tools/javacserver/JavacServer.java b/src/share/classes/com/sun/tools/javacserver/JavacServer.java --- a/src/share/classes/com/sun/tools/javacserver/JavacServer.java +++ b/src/share/classes/com/sun/tools/javacserver/JavacServer.java @@ -53,10 +53,12 @@ import java.util.ArrayList; import java.util.Arrays; import java.util.List; +import java.util.Stack; import java.util.Random; import java.util.concurrent.ExecutorService; import java.util.concurrent.Executors; import java.util.concurrent.TimeUnit; +import java.util.concurrent.Semaphore; import java.util.logging.Logger; import javax.tools.ForwardingJavaFileManager; @@ -286,9 +288,10 @@ server_start = System.currentTimeMillis(); // Create a server socket on a random port that is bound to the localhost/127.0.0.1 interface. // I.e only local processes can connect to this port. - serverSocket = new ServerSocket(0,0,InetAddress.getByName(null)); + serverSocket = new ServerSocket(0,128,InetAddress.getByName(null)); int port = serverSocket.getLocalPort(); pool = Executors.newFixedThreadPool(poolSize); + Handler.setPoolSize(poolSize); Random rnd = new Random(); my_cookie = rnd.nextLong(); si.setValues(port, my_cookie); @@ -555,29 +558,44 @@ } static class Handler implements Runnable { - private static Handler[] handlers = new Handler[0]; - private static int available_handlers = 0; + private static Semaphore available; + private static Stack handlers = new Stack(); - public static synchronized Handler grabHandler() { - if (available_handlers==0) { - handlers = new Handler[handlers.length+1]; + public static void setPoolSize(int poolsize) { + if (available != null) { + log("Internal Error: Handler pool size already set!"); + System.exit(-1); + } + available = new Semaphore(poolsize, true); + } + + public static Handler grabHandler() throws InterruptedException { + available.acquire(); + return popHandler(); + } + + private static synchronized Handler popHandler() { + if (handlers.empty()) { return new Handler(); } - available_handlers--; - Handler tmp = handlers[available_handlers]; - tmp.returned = false; - handlers[available_handlers] = null; - return tmp; + + Handler h = handlers.pop(); + h.returned = false; + return h; } - public static synchronized void returnHandler(Handler h) { - if (h.returned == true) { + public static void returnHandler(Handler h) { + pushHandler(h); + available.release(); + } + + private static synchronized void pushHandler(Handler h) { + if (h.returned) { log("Internal Error: Handler already returned once!"); System.exit(-1); } h.returned = true; - handlers[available_handlers] = h; - available_handlers++; + handlers.push(h); } private boolean returned = false; /Per From fredrik.ohrstrom at oracle.com Tue Nov 29 07:43:56 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 29 Nov 2011 15:43:56 +0000 Subject: hg: build-infra/jdk7: Fixed typo in configure help string. Message-ID: <20111129154356.F0D274748F@hg.openjdk.java.net> Changeset: 365f3f8d81dd Author: ohrstrom Date: 2011-11-29 16:45 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/365f3f8d81dd Fixed typo in configure help string. Contributed-by: Per Liden ! configure ! configure.ac From kelly.ohair at oracle.com Tue Nov 29 09:02:42 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 29 Nov 2011 09:02:42 -0800 Subject: CFV: New build-infra Committers In-Reply-To: <4ECF69CE.80702@oracle.com> References: <4ECF69CE.80702@oracle.com> Message-ID: <65930914-CA61-470D-B08D-70DF9272AE18@oracle.com> Vote: yes -kto On Nov 25, 2011, at 2:11 AM, Fredrik ?hrstr?m wrote: > I hereby nominate the following people to build-infra Committer: > > Erik Joelsson > Magnus Ihse-Bursie > Robert Ottenhag > > These people have already been pushing patches to build-infra, > and have the knowledge and experience to be committers. It was > an oversight that they have not been nominated as committers before. > As the project-lead Kelly Ohair specified, the build-infra project > is a fast moving development sandbox to experiment and stabilize > our build changes. Thus reviewing patches is not necessary. > > Votes are due by 12 noon CET, Friday December 9, 2011. > Only current build-infra [1] are eligible to vote on this nomination. > For Lazy Consensus voting instructions, see [2]. > > Fredrik ?hrstr?m > > [1] http://openjdk.java.net/census#build-infra > [2] http://openjdk.java.net/projects#committer-vote > From fredrik.ohrstrom at oracle.com Tue Nov 29 08:39:39 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Tue, 29 Nov 2011 16:39:39 +0000 Subject: hg: build-infra/jdk7/langtools: Limit number of compiler instances in JavacServer to avoid OOM. Message-ID: <20111129163944.E809847495@hg.openjdk.java.net> Changeset: e4dd56efd30f Author: ohrstrom Date: 2011-11-29 17:41 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/langtools/rev/e4dd56efd30f Limit number of compiler instances in JavacServer to avoid OOM. Contributed-by: Per Liden ! src/share/classes/com/sun/tools/javacserver/JavacServer.java From kelly.ohair at oracle.com Tue Nov 29 13:41:17 2011 From: kelly.ohair at oracle.com (Kelly O'Hair) Date: Tue, 29 Nov 2011 13:41:17 -0800 Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx References: <4ED4E48E.8030800@oracle.com> Message-ID: Can someone review Michael's makefile changes? I've got a bit too much on my plate at the moment, and I suspect Michael would like to get this reviewed and in place soon. Might be good to know for the build-infra team anyway. -kto Begin forwarded message: > From: Michael McMahon > Date: November 29, 2011 5:56:30 AM PST > To: Kelly O'Hair > Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx > > Kelly, > > I forgot to include you in the original email. There are a number of makefile > changes (and new makefiles) included in this work. So, I was hoping you could > cast an eye over them.. The first two links below are probably all you are interested in. > > Thanks, > Michael. > > > -------- Original Message -------- > Subject: webrevs.2 for macosx changes to jdk7u-osx > Date: Mon, 28 Nov 2011 16:08:35 +0000 > From: Michael McMahon > To: macosx-port-dev at openjdk.java.net > > Hi, > > Here is another version of the macosx webrev. This time it includes > all of the modifications and new files from macosx-port. Hence many > of the problems pointed out earlier with the inconsistencies relative to > the bsd code > are gone now. It builds and runs on all platforms and has been synced with > jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in > to highlight changes that people may want to look at more closely. > > Lastly, this time I have also included a webrev showing the changes > relative to macosx-port > for reference. > > Changes relative to jdk7u-osx > http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ > > New files > http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ > > Changes relative to macosx-port > http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ > > Thanks, > Michael. > From david.holmes at oracle.com Tue Nov 29 22:47:31 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Nov 2011 16:47:31 +1000 Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: References: <4ED4E48E.8030800@oracle.com> Message-ID: <4ED5D183.9030305@oracle.com> Michael: where is the non-build review taking place? I hate to see so many changes to the Java code :( On 30/11/2011 7:41 AM, Kelly O'Hair wrote: > Can someone review Michael's makefile changes? Not a full review by any means ... make/common/Defs-linux.gmk: + override LIBDL = -ldl Why the "override"? make/common/Defs.gmk: Would it not make sense to create Defs-macosx.gmk, use it do define all the macosx specific stuff and then include Defs-bsd.gmk? We might be able to get rid of a number of macosx specific changes that way. It's not good to have all the PLATFORM checks we have, but it is worse when you have to add one special case all over the place. ifeq ($(PLATFORM), linux) LDLIBS_COMMON = -ldl endif Shouldn't this have been changed to use LIBDL? (else why are we defining LIBDL - or are we now setting it twice?) make/common/Release.gmk: I don't see Release-macosx.gmk in the webrev? And if we have it, can some of the macosx specific changes to the release targets not go into that file? Defs-utils.gmk: + 136 NM = $(UTILS_CCS_BIN_PATH)nm This needs to be deleted. NM is already set at line 90 inside a conditional. David ----- > I've got a bit too much on my plate at the moment, and I suspect Michael would like to get this > reviewed and in place soon. > > Might be good to know for the build-infra team anyway. > > -kto > > > Begin forwarded message: > >> From: Michael McMahon >> Date: November 29, 2011 5:56:30 AM PST >> To: Kelly O'Hair >> Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx >> >> Kelly, >> >> I forgot to include you in the original email. There are a number of makefile >> changes (and new makefiles) included in this work. So, I was hoping you could >> cast an eye over them.. The first two links below are probably all you are interested in. >> >> Thanks, >> Michael. >> >> >> -------- Original Message -------- >> Subject: webrevs.2 for macosx changes to jdk7u-osx >> Date: Mon, 28 Nov 2011 16:08:35 +0000 >> From: Michael McMahon >> To: macosx-port-dev at openjdk.java.net >> >> Hi, >> >> Here is another version of the macosx webrev. This time it includes >> all of the modifications and new files from macosx-port. Hence many >> of the problems pointed out earlier with the inconsistencies relative to >> the bsd code >> are gone now. It builds and runs on all platforms and has been synced with >> jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in >> to highlight changes that people may want to look at more closely. >> >> Lastly, this time I have also included a webrev showing the changes >> relative to macosx-port >> for reference. >> >> Changes relative to jdk7u-osx >> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >> >> New files >> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >> >> Changes relative to macosx-port >> http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ >> >> Thanks, >> Michael. >> > From david.holmes at oracle.com Wed Nov 30 01:35:48 2011 From: david.holmes at oracle.com (David Holmes) Date: Wed, 30 Nov 2011 19:35:48 +1000 Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED5F168.4020106@oracle.com> References: <4ED4E48E.8030800@oracle.com> <4ED5D183.9030305@oracle.com> <4ED5F168.4020106@oracle.com> Message-ID: <4ED5F8F4.6000302@oracle.com> On 30/11/2011 7:03 PM, Michael McMahon wrote: > David, > > The main review is happening on macosx-port-dev at openjdk.java.net Is that an initial review or final review? I would expect all this to go through the regular channels before being pushed into the mainline repos!. David > Thanks, > Michael. > > On 30/11/11 06:47, David Holmes wrote: >> Michael: where is the non-build review taking place? I hate to see so >> many changes to the Java code :( >> >> On 30/11/2011 7:41 AM, Kelly O'Hair wrote: >>> Can someone review Michael's makefile changes? >> >> Not a full review by any means ... >> >> make/common/Defs-linux.gmk: >> + override LIBDL = -ldl >> >> Why the "override"? >> >> make/common/Defs.gmk: >> >> Would it not make sense to create Defs-macosx.gmk, use it do define >> all the macosx specific stuff and then include Defs-bsd.gmk? We might >> be able to get rid of a number of macosx specific changes that way. >> It's not good to have all the PLATFORM checks we have, but it is worse >> when you have to add one special case all over the place. >> >> ifeq ($(PLATFORM), linux) >> LDLIBS_COMMON = -ldl >> endif >> >> Shouldn't this have been changed to use LIBDL? (else why are we >> defining LIBDL - or are we now setting it twice?) >> >> make/common/Release.gmk: >> >> I don't see Release-macosx.gmk in the webrev? And if we have it, can >> some of the macosx specific changes to the release targets not go into >> that file? >> >> Defs-utils.gmk: >> >> + 136 NM = $(UTILS_CCS_BIN_PATH)nm >> >> This needs to be deleted. NM is already set at line 90 inside a >> conditional. >> >> David >> ----- >> >> >>> I've got a bit too much on my plate at the moment, and I suspect >>> Michael would like to get this >>> reviewed and in place soon. >>> >>> Might be good to know for the build-infra team anyway. >>> >>> -kto >>> >>> >>> Begin forwarded message: >>> >>>> From: Michael McMahon >>>> Date: November 29, 2011 5:56:30 AM PST >>>> To: Kelly O'Hair >>>> Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx >>>> >>>> Kelly, >>>> >>>> I forgot to include you in the original email. There are a number of >>>> makefile >>>> changes (and new makefiles) included in this work. So, I was hoping >>>> you could >>>> cast an eye over them.. The first two links below are probably all >>>> you are interested in. >>>> >>>> Thanks, >>>> Michael. >>>> >>>> >>>> -------- Original Message -------- >>>> Subject: webrevs.2 for macosx changes to jdk7u-osx >>>> Date: Mon, 28 Nov 2011 16:08:35 +0000 >>>> From: Michael McMahon >>>> To: macosx-port-dev at openjdk.java.net >>>> >>>> Hi, >>>> >>>> Here is another version of the macosx webrev. This time it includes >>>> all of the modifications and new files from macosx-port. Hence many >>>> of the problems pointed out earlier with the inconsistencies >>>> relative to >>>> the bsd code >>>> are gone now. It builds and runs on all platforms and has been >>>> synced with >>>> jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in >>>> to highlight changes that people may want to look at more closely. >>>> >>>> Lastly, this time I have also included a webrev showing the changes >>>> relative to macosx-port >>>> for reference. >>>> >>>> Changes relative to jdk7u-osx >>>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>>> >>>> New files >>>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>>> >>>> Changes relative to macosx-port >>>> http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ >>>> >>>> Thanks, >>>> Michael. >>>> >>> > From fredrik.ohrstrom at oracle.com Wed Nov 30 02:10:54 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 30 Nov 2011 11:10:54 +0100 Subject: CFV: New build-infra Committers In-Reply-To: <4ECF69CE.80702@oracle.com> References: <4ECF69CE.80702@oracle.com> Message-ID: <4ED6012E.8010106@oracle.com> Vote: yes 2011-11-25 11:11, Fredrik ?hrstr?m skrev: > I hereby nominate the following people to build-infra Committer: > > Erik Joelsson > Magnus Ihse-Bursie > Robert Ottenhag > > These people have already been pushing patches to build-infra, > and have the knowledge and experience to be committers. It was > an oversight that they have not been nominated as committers before. > As the project-lead Kelly Ohair specified, the build-infra project > is a fast moving development sandbox to experiment and stabilize > our build changes. Thus reviewing patches is not necessary. > > Votes are due by 12 noon CET, Friday December 9, 2011. > Only current build-infra [1] are eligible to vote on this nomination. > For Lazy Consensus voting instructions, see [2]. > > Fredrik ?hrstr?m > > [1] http://openjdk.java.net/census#build-infra > [2] http://openjdk.java.net/projects#committer-vote > From fredrik.ohrstrom at oracle.com Wed Nov 30 02:15:52 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 30 Nov 2011 11:15:52 +0100 Subject: Result: New build-infra Group Member: Erik Joelsson Message-ID: <4ED60258.3020908@oracle.com> |The vote for Erik Joelsson [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Fredrik Ohrstrom [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2011-November/000323.html | From fredrik.ohrstrom at oracle.com Wed Nov 30 02:18:34 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 30 Nov 2011 11:18:34 +0100 Subject: Result: New build-infra Group Member: Robert Ottenhag Message-ID: <4ED602FA.7060009@oracle.com> The vote for Robert Ottenhag [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Fredrik Ohrstrom [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2011-November/000323.html From fredrik.ohrstrom at oracle.com Wed Nov 30 02:20:02 2011 From: fredrik.ohrstrom at oracle.com (=?ISO-8859-1?Q?Fredrik_=D6hrstr=F6m?=) Date: Wed, 30 Nov 2011 11:20:02 +0100 Subject: Result: New build-infra Group Member: Magnus Ihse-Bursie Message-ID: <4ED60352.3030406@oracle.com> The vote for Magnus Ihse-Bursie [1] is now closed. Yes: 2 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Fredrik Ohrstrom [1] http://mail.openjdk.java.net/pipermail/build-infra-dev/2011-November/000323.html From fredrik.ohrstrom at oracle.com Wed Nov 30 03:57:47 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Wed, 30 Nov 2011 11:57:47 +0000 Subject: hg: build-infra/jdk7: Define _LP64=1 instead of just _LP64 to be compatible with old Message-ID: <20111130115747.EF8AE474A8@hg.openjdk.java.net> Changeset: 17005863e635 Author: ohrstrom Date: 2011-11-30 12:58 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/17005863e635 Define _LP64=1 instead of just _LP64 to be compatible with old makefiles. Test if native language is C or C++, if not then fail. ! common/make/NativeCompilation.gmk ! configure ! configure.ac From fredrik.ohrstrom at oracle.com Wed Nov 30 03:58:13 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Wed, 30 Nov 2011 11:58:13 +0000 Subject: hg: build-infra/jdk7/jdk: Make all src.zip in the demo directories identical contentwise. Message-ID: <20111130115832.BCCEA474A9@hg.openjdk.java.net> Changeset: 2a66b6605cd5 Author: ohrstrom Date: 2011-11-30 12:59 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/2a66b6605cd5 Make all src.zip in the demo directories identical contentwise. Improve libraries, some are now identical, some same symbols and size, but some binary differences, some are still different. ! make/CompileDemos.gmk From magnus.ihse.bursie at oracle.com Wed Nov 30 04:15:41 2011 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Wed, 30 Nov 2011 12:15:41 +0000 Subject: hg: build-infra/jdk7: 2 new changesets Message-ID: <20111130121541.DD226474AA@hg.openjdk.java.net> Changeset: a0e915499945 Author: ihse Date: 2011-11-30 12:54 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/a0e915499945 Add checks for external autoconf files. ! configure.ac Changeset: 15a91292cebc Author: ihse Date: 2011-11-30 13:14 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/15a91292cebc ... and update the generated configure file. ! configure From stefan.karlsson at oracle.com Wed Nov 30 04:37:03 2011 From: stefan.karlsson at oracle.com (Stefan Karlsson) Date: Wed, 30 Nov 2011 13:37:03 +0100 Subject: Review request (s): 7116081: USE_PRECOMPILED_HEADER=0 triggers a single threaded build of the JVM In-Reply-To: <4ED49C05.5090306@oracle.com> References: <4ED39BF0.7040802@oracle.com> <4ED41DEB.2000600@oracle.com> <4ED49C05.5090306@oracle.com> Message-ID: <4ED6236F.9060608@oracle.com> Looping in build-dev and build-infra-dev. StefanK On 11/29/2011 09:47 AM, Stefan Karlsson wrote: > David, > > Thanks for the review. > > All, > > Updated webrev: http://cr.openjdk.java.net/~stefank/7116081/webrev.2/ > > The rationale for this change is inlined: > > On 11/29/2011 12:48 AM, David Holmes wrote: >> Hi Stefan, >> >> On 29/11/2011 12:34 AM, Stefan Karlsson wrote: >>> http://cr.openjdk.java.net/~stefank/7116081/webrev/ >>> >>> Turning off the precompiled headers is somewhat broken. It triggers a >>> single threaded build even when HOTSPOT_BUILD_JOBS has been set. With >>> this fix the compile times went from around 14 minutes to 2.5 minutes, >>> on an 8 core machine. >> >> Took me a while to figure out why this was the case :) >> >>> This affects both Linux and BSD builds, but has only been tested on >>> Linux. It would be great if someone with access to a BSD machine could >>> verify this fix. >> >> The problem here was using >> >> ifdef USE_PRECOMPILED_HEADER >> >> when defining it to 0 is used to turn it off - so it seems to me the >> better fix here was to simply change to: >> >> ifeq ($(USE_PRECOMPILED_HEADER),1) > > I've changed the conditional to check USE_PRECOMPILED_HEADER instead. > > While doing that I found another issue. In gcc.make we try to redefine > USE_PRECOMPILED_HEADER: > > 88 ifneq ($(USE_PRECOMPILED_HEADER),0) > 89 USE_PRECOMPILED_HEADER=1 > > > That doesn't work, so setting USE_PRECOMPILED_HEADER= (not 0)> on the command line will leave the precompiled headers on, > but later logic: > > 219 ifneq ($(USE_PRECOMPILED_HEADER),1) > 220 CFLAGS += -DDONT_USE_PRECOMPILED_HEADER > > will empty the precompiled.hpp file. From precompiled.hpp: > > // Precompiled headers are turned off for Sun Studion, > // or if the user passes USE_PRECOMPILED_HEADER=0 to the makefiles. > #ifndef DONT_USE_PRECOMPILED_HEADER > > In the new webrev I've changed all places where we read > USE_PRECOMPILED_HEADER to always compare against 0. > > thanks, > StefanK > >> >> >> The removal of: >> >> PrecompiledOption = -DUSE_PRECOMPILED_HEADER >> >> seems okay. >> >> Cheers, >> David >> >> > From magnus.ihse.bursie at oracle.com Wed Nov 30 04:46:19 2011 From: magnus.ihse.bursie at oracle.com (magnus.ihse.bursie at oracle.com) Date: Wed, 30 Nov 2011 12:46:19 +0000 Subject: hg: build-infra/jdk7: Re-generate configure; this time with a proper pkg.m4. (duh!) Message-ID: <20111130124619.8D7E8474AB@hg.openjdk.java.net> Changeset: 51ee11e931c7 Author: ihse Date: 2011-11-30 13:45 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/rev/51ee11e931c7 Re-generate configure; this time with a proper pkg.m4. (duh!) ! configure From fredrik.ohrstrom at oracle.com Wed Nov 30 05:18:53 2011 From: fredrik.ohrstrom at oracle.com (fredrik.ohrstrom at oracle.com) Date: Wed, 30 Nov 2011 13:18:53 +0000 Subject: hg: build-infra/jdk7/jdk: Now launchers are mostly identical. Message-ID: <20111130131903.27402474AD@hg.openjdk.java.net> Changeset: 50b025ddd47c Author: ohrstrom Date: 2011-11-30 14:20 +0100 URL: http://hg.openjdk.java.net/build-infra/jdk7/jdk/rev/50b025ddd47c Now launchers are mostly identical. ! make/CompileLaunchers.gmk + make/mapfiles/launchers/mapfile-amd64 + make/mapfiles/launchers/mapfile-i586 + make/mapfiles/launchers/mapfile-sparc + make/mapfiles/launchers/mapfile-sparcv9 From stephen.fitch at gmail.com Sat Nov 12 11:02:43 2011 From: stephen.fitch at gmail.com (Stephen Fitch) Date: Sat, 12 Nov 2011 19:02:43 -0000 Subject: Build Failure in langtools - Ubuntu 11.10/VBox... any ideas why? Message-ID: <4EBEC2CD.2050207@gmail.com> I've been experimenting with the new build infra on an Ubuntu 11.10 VBox env, but I hit a pretty early on issue... any ideas ?? << sf at sf-VirtualBox:~/dev/build-infra$ pwd /home/sf/dev/build-infra sf at sf-VirtualBox:~/dev/build-infra$ make 2>&1 | ./common/bin/hide_important_warnings_from_javac.sh ######################################################################## ######################################################################## ##### Entering langtools for target(s) all ##### ######################################################################## Compiling 60 files in package com/sun/mirror/declaration Compiling 15 files in package com/sun/mirror/type /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/WildcardType.java:55: error: duplicate class: com.sun.mirror.type.WildcardType public interface WildcardType extends TypeMirror { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/VoidType.java:48: error: duplicate class: com.sun.mirror.type.VoidType public interface VoidType extends TypeMirror { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/TypeVariable.java:49: error: duplicate class: com.sun.mirror.type.TypeVariable public interface TypeVariable extends ReferenceType { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/TypeMirror.java:60: error: duplicate class: com.sun.mirror.type.TypeMirror public interface TypeMirror { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/ReferenceType.java:44: error: duplicate class: com.sun.mirror.type.ReferenceType public interface ReferenceType extends TypeMirror { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/PrimitiveType.java:45: error: duplicate class: com.sun.mirror.type.PrimitiveType public interface PrimitiveType extends TypeMirror { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/InterfaceType.java:53: error: duplicate class: com.sun.mirror.type.InterfaceType public interface InterfaceType extends DeclaredType { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/EnumType.java:46: error: duplicate class: com.sun.mirror.type.EnumType public interface EnumType extends ClassType { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/DeclaredType.java:62: error: duplicate class: com.sun.mirror.type.DeclaredType public interface DeclaredType extends ReferenceType { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/ClassType.java:52: error: duplicate class: com.sun.mirror.type.ClassType public interface ClassType extends DeclaredType { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/ArrayType.java:45: error: duplicate class: com.sun.mirror.type.ArrayType public interface ArrayType extends ReferenceType { ^ /home/sf/dev/build-infra/langtools/src/share/classes/com/sun/mirror/type/AnnotationType.java:46: error: duplicate class: com.sun.mirror.type.AnnotationType public interface AnnotationType extends InterfaceType { ^ 12 errors Javac command line that failed: -XDserver:portfile=/home/sf/dev/build-infra/build/linux-amd64-server-release/javacservers/GENERATE_NEWBYTECODE.port,poolsize=1,javac=/usr/lib/jvm/java-6-openjdk/bin/java%20-XX:+UseParallelOldGC%20-verbosegc%20-Xms256M%20-Xmx512M%20-Xmn128M%20-Xbootclasspath/p:/home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/dist/bootstrap/lib/javac.jar%20-jar%20/home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/dist/bootstrap/lib/javac.jar -XDdeps=file=/home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/classes/com/sun/mirror/type/_the.package.deps,groupon=package -XDpubapi=file=/home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/classes/com/sun/mirror/type/_the.package.api,notify,package=com.sun.mirror.type -XDnativeapi=file=/home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/classes/com/sun/mirror/type/_the.package.native,notify,package=com.sun.mirror.type -Xprefer:source -XDignore.symbol.file=true -implicit:none -sourcepath /home/sf/dev/build-infra/langtools/src/share/classes:/home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/gensrc:/home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/genstubs -d /home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/classes @/home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/classes/com/sun/mirror/type/_the.package.tmp make[1]: *** [/home/sf/dev/build-infra/build/linux-amd64-server-release/langtools/classes/com/sun/mirror/type/_the.package] Error 1 make: *** [langtools] Error 2 sf at sf-VirtualBox:~/dev/build-infra$ >> My steps were << sudo apt-get build-dep openjdk-6 sudo apt-get install openjdk-6-jdk sudo apt-get install ccache In addition, it's necessary to setup the new build infra by hg clonehttp://hg.openjdk.java.net/build-infra/jdk7 build-infra cd build-infra/ sh ./get_source.sh cd common/config wgethttp://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.guess wgethttp://cvs.savannah.gnu.org/viewvc/*checkout*/config/config/config.sub wgethttp://www.opensource.apple.com/source/libdispatch/libdispatch-187.5/m4/pkg.m4?txt cd ../.. ./configure make 2>&1 | ./common/bin/hide_important_warnings_from_javac.sh > > I'm still working to figure out what went wrong, but would welcome any hints... I even tried with Iced-Tea via ./configure --with-boot-jdk=/usr/lib/jvm/java-6-openjdk --- From Alan.Bateman at oracle.com Thu Nov 24 02:12:02 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 24 Nov 2011 10:12:02 -0000 Subject: jdk/src/solaris - time to re-visit it? In-Reply-To: <4ECD5C26.1040303@oracle.com> References: <4ECCE31D.90007@oracle.com> <4ECD5C26.1040303@oracle.com> Message-ID: <4ECE1867.8020302@oracle.com> On 23/11/2011 20:48, David Holmes wrote: > Alan, > > It's definitely tricky (lots of refactoring needed) but it definitely > needs to be done at some point - however I think we already missed the > opportunity to do this before integrating the BSD and MacOSX code > (same on the VM side) I've often wondered how disruptive it would be if src/solaris were renamed to src/unix (like Phil, I view src/solaris tree as the unix tree). Clearly it would make it more awkward to move patches between jdk versions, and it would cause everyone with in-flight patches to re-base. If we did rename it then the ifdef code could stay. Over time (probably a long time) we could chip away at the refactoring. With the new build then the direction is to move to be based on capabilities so we're going to be re-visiting this code anyway. The immediate benefit of renaming is that it would allow us to move the Solaris and Linux specific source files out of the src/unix tree into src/ directories. That would eliminate the need for some of the filtering in the build and would also allow us sort out some name conflict issues that we have in several places (UNIXProcess.java. for example). -Alan. From Alan.Bateman at oracle.com Fri Nov 25 02:59:10 2011 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 25 Nov 2011 10:59:10 -0000 Subject: jdk/src/solaris - time to re-visit it? In-Reply-To: <4ECE573F.1050702@oracle.com> References: <4ECCE31D.90007@oracle.com> <4ECD5C26.1040303@oracle.com> <4ECE1867.8020302@oracle.com> <4ECE573F.1050702@oracle.com> Message-ID: <4ECF74F5.1050609@oracle.com> On 24/11/2011 14:39, Fredrik ?hrstr?m wrote: > : > It would be great to do the rename. However, we should not do that > before the build-infra changes > are in place. The peculiarities of the current build have already been > worked around and the new > makefiles are useful, since it is easy to see where the warts are. Thus > when build-infra is done, we will > have a neat list of all things that needs to be cleaned up by moving > source code and platform > specific code in src/share is just one of many problems. > > I was hoping that when we start incrementally moving towards jigsaw-like > structuring of the source, > we can fix this then? When we rename directories, we lose a lot of > information in the source control system. > Necessary yes, but at least we should try to do it just once. > > As for the naming: > posix is the name of a standardized API to unix-like operating systems. > winapi is the name of the defacto API to windows systems. > > Using two trademarks instead of the actual names of the APIs would be silly. > > And you can run posix software on Windows by installing cygwin et al, > and you > can run winapi software on Linux by installing wine. But this is not the > point, > the point is that the built jvm will run primarily using winapi, or > primarily > using posix. > > No-one answered my question if we need to track the posix pedigree? I.e. > gnu, sysv and bsd? > > //Fredrik I agree it's not a good time to do the renaming but I think it's good to discuss and think about the how we might organize the code in the future. I don't have strong opinions on the names but "posix" doesn't seem quite right just now as we have code in src/solaris/** that is making use of APIs that aren't part of POSIX (I think this was Phil's point too). On the pedigree then it might be better to cross that bridge when we come to it, meaning that we could only really make use of it in conjunction with refactoring work. You are right that the peculiarities have been worked around to date but more have been proposed [1]. Maybe it would be prudent to hold off on these changes until the new build is in place. -Alan. [1] http://mail.openjdk.java.net/pipermail/nio-dev/2011-November/001466.html From michael.x.mcmahon at oracle.com Wed Nov 30 01:03:36 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 30 Nov 2011 09:03:36 +0000 Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED5D183.9030305@oracle.com> References: <4ED4E48E.8030800@oracle.com> <4ED5D183.9030305@oracle.com> Message-ID: <4ED5F168.4020106@oracle.com> David, The main review is happening on macosx-port-dev at openjdk.java.net Thanks, Michael. On 30/11/11 06:47, David Holmes wrote: > Michael: where is the non-build review taking place? I hate to see so > many changes to the Java code :( > > On 30/11/2011 7:41 AM, Kelly O'Hair wrote: >> Can someone review Michael's makefile changes? > > Not a full review by any means ... > > make/common/Defs-linux.gmk: > + override LIBDL = -ldl > > Why the "override"? > > make/common/Defs.gmk: > > Would it not make sense to create Defs-macosx.gmk, use it do define > all the macosx specific stuff and then include Defs-bsd.gmk? We might > be able to get rid of a number of macosx specific changes that way. > It's not good to have all the PLATFORM checks we have, but it is worse > when you have to add one special case all over the place. > > ifeq ($(PLATFORM), linux) > LDLIBS_COMMON = -ldl > endif > > Shouldn't this have been changed to use LIBDL? (else why are we > defining LIBDL - or are we now setting it twice?) > > make/common/Release.gmk: > > I don't see Release-macosx.gmk in the webrev? And if we have it, can > some of the macosx specific changes to the release targets not go into > that file? > > Defs-utils.gmk: > > + 136 NM = $(UTILS_CCS_BIN_PATH)nm > > This needs to be deleted. NM is already set at line 90 inside a > conditional. > > David > ----- > > >> I've got a bit too much on my plate at the moment, and I suspect >> Michael would like to get this >> reviewed and in place soon. >> >> Might be good to know for the build-infra team anyway. >> >> -kto >> >> >> Begin forwarded message: >> >>> From: Michael McMahon >>> Date: November 29, 2011 5:56:30 AM PST >>> To: Kelly O'Hair >>> Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx >>> >>> Kelly, >>> >>> I forgot to include you in the original email. There are a number of >>> makefile >>> changes (and new makefiles) included in this work. So, I was hoping >>> you could >>> cast an eye over them.. The first two links below are probably all >>> you are interested in. >>> >>> Thanks, >>> Michael. >>> >>> >>> -------- Original Message -------- >>> Subject: webrevs.2 for macosx changes to jdk7u-osx >>> Date: Mon, 28 Nov 2011 16:08:35 +0000 >>> From: Michael McMahon >>> To: macosx-port-dev at openjdk.java.net >>> >>> Hi, >>> >>> Here is another version of the macosx webrev. This time it includes >>> all of the modifications and new files from macosx-port. Hence many >>> of the problems pointed out earlier with the inconsistencies >>> relative to >>> the bsd code >>> are gone now. It builds and runs on all platforms and has been >>> synced with >>> jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in >>> to highlight changes that people may want to look at more closely. >>> >>> Lastly, this time I have also included a webrev showing the changes >>> relative to macosx-port >>> for reference. >>> >>> Changes relative to jdk7u-osx >>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>> >>> New files >>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>> >>> Changes relative to macosx-port >>> http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ >>> >>> Thanks, >>> Michael. >>> >> From michael.x.mcmahon at oracle.com Wed Nov 30 01:26:47 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 30 Nov 2011 09:26:47 +0000 Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED5D183.9030305@oracle.com> References: <4ED4E48E.8030800@oracle.com> <4ED5D183.9030305@oracle.com> Message-ID: <4ED5F6D7.9040803@oracle.com> On 30/11/11 06:47, David Holmes wrote: > Michael: where is the non-build review taking place? I hate to see so > many changes to the Java code :( > > On 30/11/2011 7:41 AM, Kelly O'Hair wrote: >> Can someone review Michael's makefile changes? > > Not a full review by any means ... > > make/common/Defs-linux.gmk: > + override LIBDL = -ldl > > Why the "override"? > It's just using the same pattern as for other lib definitions. I'm not sure if the override is necessary, but it seems correct to me that LIBDL is a variable you wouldn't want set on the command line. Having said that, I can't say why this only applies to Linux. But, that's the way it always has been. > make/common/Defs.gmk: > > Would it not make sense to create Defs-macosx.gmk, use it do define > all the macosx specific stuff and then include Defs-bsd.gmk? We might > be able to get rid of a number of macosx specific changes that way. > It's not good to have all the PLATFORM checks we have, but it is worse > when you have to add one special case all over the place. > I agree those defs shouldn't be there. I will create a Defs-macosx.gmk > ifeq ($(PLATFORM), linux) > LDLIBS_COMMON = -ldl > endif > > Shouldn't this have been changed to use LIBDL? (else why are we > defining LIBDL - or are we now setting it twice?) > Right. That was overlooked. > make/common/Release.gmk: > > I don't see Release-macosx.gmk in the webrev? And if we have it, can > some of the macosx specific changes to the release targets not go into > that file? > Sorry, the second link in that original email was corrected, but I didn't forward that to this list: http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/new/ is where all the new files are. On the changes to make/common/Release.gmk, I agree unless there were equivalent definitions for the other platforms > Defs-utils.gmk: > > + 136 NM = $(UTILS_CCS_BIN_PATH)nm > > This needs to be deleted. NM is already set at line 90 inside a > conditional. > Right. > David > ----- > > >> I've got a bit too much on my plate at the moment, and I suspect >> Michael would like to get this >> reviewed and in place soon. >> >> Might be good to know for the build-infra team anyway. >> >> -kto >> >> >> Begin forwarded message: >> >>> From: Michael McMahon >>> Date: November 29, 2011 5:56:30 AM PST >>> To: Kelly O'Hair >>> Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx >>> >>> Kelly, >>> >>> I forgot to include you in the original email. There are a number of >>> makefile >>> changes (and new makefiles) included in this work. So, I was hoping >>> you could >>> cast an eye over them.. The first two links below are probably all >>> you are interested in. >>> >>> Thanks, >>> Michael. >>> >>> >>> -------- Original Message -------- >>> Subject: webrevs.2 for macosx changes to jdk7u-osx >>> Date: Mon, 28 Nov 2011 16:08:35 +0000 >>> From: Michael McMahon >>> To: macosx-port-dev at openjdk.java.net >>> >>> Hi, >>> >>> Here is another version of the macosx webrev. This time it includes >>> all of the modifications and new files from macosx-port. Hence many >>> of the problems pointed out earlier with the inconsistencies >>> relative to >>> the bsd code >>> are gone now. It builds and runs on all platforms and has been >>> synced with >>> jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in >>> to highlight changes that people may want to look at more closely. >>> >>> Lastly, this time I have also included a webrev showing the changes >>> relative to macosx-port >>> for reference. >>> >>> Changes relative to jdk7u-osx >>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>> >>> New files >>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>> >>> Changes relative to macosx-port >>> http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ >>> >>> Thanks, >>> Michael. >>> >> From michael.x.mcmahon at oracle.com Wed Nov 30 01:41:32 2011 From: michael.x.mcmahon at oracle.com (Michael McMahon) Date: Wed, 30 Nov 2011 09:41:32 +0000 Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx In-Reply-To: <4ED5F8F4.6000302@oracle.com> References: <4ED4E48E.8030800@oracle.com> <4ED5D183.9030305@oracle.com> <4ED5F168.4020106@oracle.com> <4ED5F8F4.6000302@oracle.com> Message-ID: <4ED5FA4C.8000806@oracle.com> On 30/11/11 09:35, David Holmes wrote: > On 30/11/2011 7:03 PM, Michael McMahon wrote: >> David, >> >> The main review is happening on macosx-port-dev at openjdk.java.net > > Is that an initial review or final review? I would expect all this to > go through the regular channels before being pushed into the mainline > repos!. > This is just a review to get it into "jdk7u-osx". It will certainly be reviewed through the regular channels before being pushed into mainline repos. Thanks, Michael > David > >> Thanks, >> Michael. >> >> On 30/11/11 06:47, David Holmes wrote: >>> Michael: where is the non-build review taking place? I hate to see so >>> many changes to the Java code :( >>> >>> On 30/11/2011 7:41 AM, Kelly O'Hair wrote: >>>> Can someone review Michael's makefile changes? >>> >>> Not a full review by any means ... >>> >>> make/common/Defs-linux.gmk: >>> + override LIBDL = -ldl >>> >>> Why the "override"? >>> >>> make/common/Defs.gmk: >>> >>> Would it not make sense to create Defs-macosx.gmk, use it do define >>> all the macosx specific stuff and then include Defs-bsd.gmk? We might >>> be able to get rid of a number of macosx specific changes that way. >>> It's not good to have all the PLATFORM checks we have, but it is worse >>> when you have to add one special case all over the place. >>> >>> ifeq ($(PLATFORM), linux) >>> LDLIBS_COMMON = -ldl >>> endif >>> >>> Shouldn't this have been changed to use LIBDL? (else why are we >>> defining LIBDL - or are we now setting it twice?) >>> >>> make/common/Release.gmk: >>> >>> I don't see Release-macosx.gmk in the webrev? And if we have it, can >>> some of the macosx specific changes to the release targets not go into >>> that file? >>> >>> Defs-utils.gmk: >>> >>> + 136 NM = $(UTILS_CCS_BIN_PATH)nm >>> >>> This needs to be deleted. NM is already set at line 90 inside a >>> conditional. >>> >>> David >>> ----- >>> >>> >>>> I've got a bit too much on my plate at the moment, and I suspect >>>> Michael would like to get this >>>> reviewed and in place soon. >>>> >>>> Might be good to know for the build-infra team anyway. >>>> >>>> -kto >>>> >>>> >>>> Begin forwarded message: >>>> >>>>> From: Michael McMahon >>>>> Date: November 29, 2011 5:56:30 AM PST >>>>> To: Kelly O'Hair >>>>> Subject: Fwd: webrevs.2 for macosx changes to jdk7u-osx >>>>> >>>>> Kelly, >>>>> >>>>> I forgot to include you in the original email. There are a number of >>>>> makefile >>>>> changes (and new makefiles) included in this work. So, I was hoping >>>>> you could >>>>> cast an eye over them.. The first two links below are probably all >>>>> you are interested in. >>>>> >>>>> Thanks, >>>>> Michael. >>>>> >>>>> >>>>> -------- Original Message -------- >>>>> Subject: webrevs.2 for macosx changes to jdk7u-osx >>>>> Date: Mon, 28 Nov 2011 16:08:35 +0000 >>>>> From: Michael McMahon >>>>> To: macosx-port-dev at openjdk.java.net >>>>> >>>>> Hi, >>>>> >>>>> Here is another version of the macosx webrev. This time it includes >>>>> all of the modifications and new files from macosx-port. Hence many >>>>> of the problems pointed out earlier with the inconsistencies >>>>> relative to >>>>> the bsd code >>>>> are gone now. It builds and runs on all platforms and has been >>>>> synced with >>>>> jdk7u-dev (as of Friday Nov 25). I left the // MacOSX comments in >>>>> to highlight changes that people may want to look at more closely. >>>>> >>>>> Lastly, this time I have also included a webrev showing the changes >>>>> relative to macosx-port >>>>> for reference. >>>>> >>>>> Changes relative to jdk7u-osx >>>>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>>>> >>>>> New files >>>>> http://cr.openjdk.java.net/~michaelm/7113349/2/jdk7u-osx/modified/ >>>>> >>>>> Changes relative to macosx-port >>>>> http://cr.openjdk.java.net/~michaelm/7113349/2/macosx-port/modified/ >>>>> >>>>> Thanks, >>>>> Michael. >>>>> >>>> >>