From xiomara.jayasena at sun.com Tue Mar 3 23:27:42 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Tue, 03 Mar 2009 23:27:42 +0000 Subject: hg: jdk7/build/jdk: 2 new changesets Message-ID: <20090303232820.7FBF4E6FB@hg.openjdk.java.net> Changeset: 58ba2cd5a250 Author: alanb Date: 2009-03-01 14:44 +0000 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/58ba2cd5a250 6811578: genSolarisConstants.c should not require kernel patch to compile on Solaris 10 Reviewed-by: tbell ! src/solaris/native/sun/nio/fs/genSolarisConstants.c Changeset: abfccc052872 Author: xdono Date: 2009-03-03 15:21 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/abfccc052872 Merge From roman.kennke at aicas.com Wed Mar 4 15:48:23 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 04 Mar 2009 16:48:23 +0100 Subject: Binary blobs for older trees? Message-ID: <1236181703.6197.24.camel@moonlight> Hi, I'm trying to build the 2d-tree, but it fails because it's missing some jsound library. I recently updated my version of the binary blobs for a plain openjdk7 build, but it seems like the 2d-tree still requires an older version. Are older versions of the blobs available somewhere? I think it would be very useful, not only because some group trees lag behind, but also when somebody wants to build an older version of a current tree. (Ideally, I'd think the build system should offer to fetch a matching blob via ant's get-tag or wget...) /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From Phil.Race at Sun.COM Wed Mar 4 17:19:36 2009 From: Phil.Race at Sun.COM (Phil Race) Date: Wed, 04 Mar 2009 09:19:36 -0800 Subject: Binary blobs for older trees? In-Reply-To: <1236181703.6197.24.camel@moonlight> References: <1236181703.6197.24.camel@moonlight> Message-ID: <49AEB828.9090805@sun.com> There's an archive here : http://download.java.net/jdk7/archive/ Its linked via http://openjdk.java.net/ -> http://download.java.net/openjdk/jdk7/ -> http://download.java.net/jdk7/binaries/ -> Also we should sync the 2D repo -phil. Roman Kennke wrote: > Hi, > > I'm trying to build the 2d-tree, but it fails because it's missing some > jsound library. I recently updated my version of the binary blobs for a > plain openjdk7 build, but it seems like the 2d-tree still requires an > older version. Are older versions of the blobs available somewhere? I > think it would be very useful, not only because some group trees lag > behind, but also when somebody wants to build an older version of a > current tree. (Ideally, I'd think the build system should offer to fetch > a matching blob via ant's get-tag or wget...) > > /Roman > From roman.kennke at aicas.com Wed Mar 4 19:18:55 2009 From: roman.kennke at aicas.com (Roman Kennke) Date: Wed, 04 Mar 2009 20:18:55 +0100 Subject: Binary blobs for older trees? In-Reply-To: <49AEB828.9090805@sun.com> References: <1236181703.6197.24.camel@moonlight> <49AEB828.9090805@sun.com> Message-ID: <1236194335.6197.41.camel@moonlight> Hi Phil, > There's an archive here : > http://download.java.net/jdk7/archive/ Cool, thanks. > Its linked via > http://openjdk.java.net/ -> > http://download.java.net/openjdk/jdk7/ -> > http://download.java.net/jdk7/binaries/ -> That was not at all obvious. And I was looking for a 0.7MB download, not a 70MB download, but I guess that'll do the job as well. > Also we should sync the 2D repo Yeah. Thanks /Roman -- Dipl.-Inform. (FH) Roman Kennke, Software Engineer, http://kennke.org aicas Allerton Interworks Computer Automated Systems GmbH Haid-und-Neu-Stra?e 18 * D-76131 Karlsruhe * Germany http://www.aicas.com * Tel: +49-721-663 968-48 USt-Id: DE216375633, Handelsregister HRB 109481, AG Karlsruhe Gesch?ftsf?hrer: Dr. James J. Hunt From martinrb at google.com Wed Mar 4 21:10:23 2009 From: martinrb at google.com (Martin Buchholz) Date: Wed, 4 Mar 2009 13:10:23 -0800 Subject: Binary blobs for older trees? In-Reply-To: <49AEB828.9090805@sun.com> References: <1236181703.6197.24.camel@moonlight> <49AEB828.9090805@sun.com> Message-ID: <1ccfd1c10903041310y2440bf7cx1dcb9f148dd8d26f@mail.gmail.com> The jdk7 builds at http://download.java.net/jdk7/archive/ are for the non-open-source jdk7. The binary plugs for recent openjdk7 builds are available in non-obvious places like http://download.java.net/openjdk/jdk7/promoted/b45/ but b45 is the oldest available build. I would like to see all of the historically downloadable bits to remain available. Current JDK sources for builds back to b20 or so are available via mercurial, but there's no way to build them properly without the binary plugs. Martin On Wed, Mar 4, 2009 at 09:19, Phil Race wrote: > There's an archive here : > http://download.java.net/jdk7/archive/ > > Its linked via > http://openjdk.java.net/ -> > http://download.java.net/openjdk/jdk7/ -> > http://download.java.net/jdk7/binaries/ -> > > Also we should sync the 2D repo > > -phil. > > Roman Kennke wrote: >> >> Hi, >> >> I'm trying to build the 2d-tree, but it fails because it's missing some >> jsound library. I recently updated my version of the binary blobs for a >> plain openjdk7 build, but it seems like the 2d-tree still requires an >> older version. Are older versions of the blobs available somewhere? I >> think it would be very useful, not only because some group trees lag >> behind, but also when somebody wants to build an older version of a >> current tree. (Ideally, I'd think the build system should offer to fetch >> a matching blob via ant's get-tag or wget...) >> >> /Roman >> > From gnu_andrew at member.fsf.org Wed Mar 4 22:11:29 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 4 Mar 2009 22:11:29 +0000 Subject: Binary blobs for older trees? In-Reply-To: <1ccfd1c10903041310y2440bf7cx1dcb9f148dd8d26f@mail.gmail.com> References: <1236181703.6197.24.camel@moonlight> <49AEB828.9090805@sun.com> <1ccfd1c10903041310y2440bf7cx1dcb9f148dd8d26f@mail.gmail.com> Message-ID: <17c6771e0903041411w432e20d7jacb82727bdd6230b@mail.gmail.com> 2009/3/4 Martin Buchholz : > The jdk7 builds at > http://download.java.net/jdk7/archive/ > are for the non-open-source jdk7. > > The binary plugs for recent openjdk7 builds > are available in non-obvious places like > > http://download.java.net/openjdk/jdk7/promoted/b45/ > > but b45 is the oldest available build. > > I would like to see all of the historically downloadable bits > to remain available. ?Current JDK sources for builds back to > b20 or so are available via mercurial, but there's no way to > build them properly without the binary plugs. > > Martin > > On Wed, Mar 4, 2009 at 09:19, Phil Race wrote: >> There's an archive here : >> http://download.java.net/jdk7/archive/ >> >> Its linked via >> http://openjdk.java.net/ -> >> http://download.java.net/openjdk/jdk7/ -> >> http://download.java.net/jdk7/binaries/ -> >> >> Also we should sync the 2D repo >> >> -phil. >> >> Roman Kennke wrote: >>> >>> Hi, >>> >>> I'm trying to build the 2d-tree, but it fails because it's missing some >>> jsound library. I recently updated my version of the binary blobs for a >>> plain openjdk7 build, but it seems like the 2d-tree still requires an >>> older version. Are older versions of the blobs available somewhere? I >>> think it would be very useful, not only because some group trees lag >>> behind, but also when somebody wants to build an older version of a >>> current tree. (Ideally, I'd think the build system should offer to fetch >>> a matching blob via ant's get-tag or wget...) >>> >>> /Roman >>> >> > The 2D tree definitely needs to sync -- the jsoundhs binary plug has gone from recent build drops (b46 on). -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Dmitri.Trembovetski at Sun.COM Thu Mar 5 01:24:47 2009 From: Dmitri.Trembovetski at Sun.COM (Dmitri Trembovetski) Date: Wed, 04 Mar 2009 17:24:47 -0800 Subject: Binary blobs for older trees? In-Reply-To: <17c6771e0903041411w432e20d7jacb82727bdd6230b@mail.gmail.com> References: <1236181703.6197.24.camel@moonlight> <49AEB828.9090805@sun.com> <1ccfd1c10903041310y2440bf7cx1dcb9f148dd8d26f@mail.gmail.com> <17c6771e0903041411w432e20d7jacb82727bdd6230b@mail.gmail.com> Message-ID: <49AF29DF.2000708@Sun.COM> The 2d forest has been sync-ed to master (thanks, Lana). Dmitri Andrew John Hughes wrote: > 2009/3/4 Martin Buchholz : >> The jdk7 builds at >> http://download.java.net/jdk7/archive/ >> are for the non-open-source jdk7. >> >> The binary plugs for recent openjdk7 builds >> are available in non-obvious places like >> >> http://download.java.net/openjdk/jdk7/promoted/b45/ >> >> but b45 is the oldest available build. >> >> I would like to see all of the historically downloadable bits >> to remain available. Current JDK sources for builds back to >> b20 or so are available via mercurial, but there's no way to >> build them properly without the binary plugs. >> >> Martin >> >> On Wed, Mar 4, 2009 at 09:19, Phil Race wrote: >>> There's an archive here : >>> http://download.java.net/jdk7/archive/ >>> >>> Its linked via >>> http://openjdk.java.net/ -> >>> http://download.java.net/openjdk/jdk7/ -> >>> http://download.java.net/jdk7/binaries/ -> >>> >>> Also we should sync the 2D repo >>> >>> -phil. >>> >>> Roman Kennke wrote: >>>> Hi, >>>> >>>> I'm trying to build the 2d-tree, but it fails because it's missing some >>>> jsound library. I recently updated my version of the binary blobs for a >>>> plain openjdk7 build, but it seems like the 2d-tree still requires an >>>> older version. Are older versions of the blobs available somewhere? I >>>> think it would be very useful, not only because some group trees lag >>>> behind, but also when somebody wants to build an older version of a >>>> current tree. (Ideally, I'd think the build system should offer to fetch >>>> a matching blob via ant's get-tag or wget...) >>>> >>>> /Roman >>>> > > The 2D tree definitely needs to sync -- the jsoundhs binary plug has > gone from recent build drops (b46 on). From dougfelt at google.com Thu Mar 5 17:16:09 2009 From: dougfelt at google.com (Doug Felt) Date: Thu, 5 Mar 2009 09:16:09 -0800 Subject: Fwd: clean build doesn't generate package private class In-Reply-To: <146f39a80903031352o4202cc5er64dc4efaed04421a@mail.gmail.com> References: <146f39a80903031352o4202cc5er64dc4efaed04421a@mail.gmail.com> Message-ID: <146f39a80903050916v5bb87d17te0a7a864b918ed3b@mail.gmail.com> resend, bounced the first time ---------- Forwarded message ---------- From: Doug Felt Date: Tue, Mar 3, 2009 at 1:52 PM Subject: clean build doesn't generate package private class To: build-dev at openjdk.java.net I recently fetched jdk7 (after not having done so for a few months) and did a clean rebuild, and the VM is failing to start. I'm building on Ubuntu (2.6.27-11-generic) on i586. Sanity passes. make all CC=gcc-4.1 CPP=g++-4.1 On startup I get the following stack trace: Error occurred during initialization of VM java.lang.NoClassDefFoundError: java/net/Parts at java.net.URL.(URL.java:396) at java.net.URL.(URL.java:300) at java.net.URL.(URL.java:323) at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:272) at sun.misc.Launcher.getFileURL(Launcher.java:442) at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:190) at sun.misc.Launcher$ExtClassLoader.(Launcher.java:161) at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:145) at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:139) at java.security.AccessController.doPrivileged(Native Method) at sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:138) at sun.misc.Launcher.(Launcher.java:71) at sun.misc.Launcher.(Launcher.java:59) at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1325) at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1307) Looking in the classes directory, I see that although URL.class is present, Parts.class is not. Parts.class is a package private class defined at the top level in the same source file as URL.java. Does anyone recognize this problem? How do I work around this? Do I need a new bootstrap build, or different compiler options? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Christopher.Hegarty at Sun.COM Fri Mar 6 11:54:15 2009 From: Christopher.Hegarty at Sun.COM (Christopher Hegarty - Sun Microsystems Ireland) Date: Fri, 06 Mar 2009 11:54:15 +0000 Subject: Fwd: clean build doesn't generate package private class In-Reply-To: <146f39a80903050916v5bb87d17te0a7a864b918ed3b@mail.gmail.com> References: <146f39a80903031352o4202cc5er64dc4efaed04421a@mail.gmail.com> <146f39a80903050916v5bb87d17te0a7a864b918ed3b@mail.gmail.com> Message-ID: <49B10EE7.2070604@Sun.COM> Hi Doug, This is very strange. I just synced with the latest JDK7 source from TL and did a clean build, everything went fine, I have a Parts.class As you said, this is a clean build, right? Not a incremental. Running a few tests with javac I can see that if you compile URL.java then you will always compile Parts, even if the compile of URL.java has been triggered implicitly by a reference from another class ( and this is typically the case when building the JDK ). The only thing I can suggest is to resync the repository and try a full clean build. Failing that cd jdk/make/java/net, make clobber, make all. That will rebuild URL.java which will produce Parts.class. -Chris. On 03/05/09 17:16, Doug Felt wrote: > resend, bounced the first time > > ---------- Forwarded message ---------- > From: Doug Felt > Date: Tue, Mar 3, 2009 at 1:52 PM > Subject: clean build doesn't generate package private class > To: build-dev at openjdk.java.net > > > I recently fetched jdk7 (after not having done so for a few months) and did > a clean rebuild, and the VM is failing to start. I'm building on Ubuntu > (2.6.27-11-generic) on i586. Sanity passes. > > make all CC=gcc-4.1 CPP=g++-4.1 > > On startup I get the following stack trace: > > Error occurred during initialization of VM > java.lang.NoClassDefFoundError: java/net/Parts > at java.net.URL.(URL.java:396) > at java.net.URL.(URL.java:300) > at java.net.URL.(URL.java:323) > at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:272) > at sun.misc.Launcher.getFileURL(Launcher.java:442) > at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:190) > at sun.misc.Launcher$ExtClassLoader.(Launcher.java:161) > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:145) > at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:139) > at java.security.AccessController.doPrivileged(Native Method) > at sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:138) > at sun.misc.Launcher.(Launcher.java:71) > at sun.misc.Launcher.(Launcher.java:59) > at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1325) > at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1307) > > Looking in the classes directory, I see that although URL.class is present, > Parts.class is not. Parts.class is a package private class defined at the > top level in the same source file as URL.java. > > Does anyone recognize this problem? How do I work around this? Do I need a > new bootstrap build, or different compiler options? > From dougfelt at google.com Fri Mar 6 17:33:52 2009 From: dougfelt at google.com (Doug Felt) Date: Fri, 6 Mar 2009 09:33:52 -0800 Subject: Fwd: clean build doesn't generate package private class In-Reply-To: <49B10EE7.2070604@Sun.COM> References: <146f39a80903031352o4202cc5er64dc4efaed04421a@mail.gmail.com> <146f39a80903050916v5bb87d17te0a7a864b918ed3b@mail.gmail.com> <49B10EE7.2070604@Sun.COM> Message-ID: <146f39a80903060933w4271b647q8ddbfb64799ae370@mail.gmail.com> Thanks. That's essentially what I did, and it worked. The only other difference is I didn't override the default environment compiler info on the make line. Since it is working for me now, I'm going to continue with my main task and not explore this further at the moment. Sometime next week I should have time to see if I can recreate this problem. Doug On Fri, Mar 6, 2009 at 3:54 AM, Christopher Hegarty - Sun Microsystems Ireland wrote: > Hi Doug, > > This is very strange. I just synced with the latest JDK7 source from TL and > did a clean build, everything went fine, I have a Parts.class > > As you said, this is a clean build, right? Not a incremental. > > Running a few tests with javac I can see that if you compile URL.java then > you will always compile Parts, even if the compile of URL.java has been > triggered implicitly by a reference from another class ( and this is > typically the case when building the JDK ). > > The only thing I can suggest is to resync the repository and try a full > clean build. Failing that cd jdk/make/java/net, make clobber, make all. > That will rebuild URL.java which will produce Parts.class. > > -Chris. > > > On 03/05/09 17:16, Doug Felt wrote: > >> resend, bounced the first time >> >> ---------- Forwarded message ---------- >> From: Doug Felt >> Date: Tue, Mar 3, 2009 at 1:52 PM >> Subject: clean build doesn't generate package private class >> To: build-dev at openjdk.java.net >> >> >> I recently fetched jdk7 (after not having done so for a few months) and >> did >> a clean rebuild, and the VM is failing to start. I'm building on Ubuntu >> (2.6.27-11-generic) on i586. Sanity passes. >> >> make all CC=gcc-4.1 CPP=g++-4.1 >> >> On startup I get the following stack trace: >> >> Error occurred during initialization of VM >> java.lang.NoClassDefFoundError: java/net/Parts >> at java.net.URL.(URL.java:396) >> at java.net.URL.(URL.java:300) >> at java.net.URL.(URL.java:323) >> at sun.net.www.ParseUtil.fileToEncodedURL(ParseUtil.java:272) >> at sun.misc.Launcher.getFileURL(Launcher.java:442) >> at sun.misc.Launcher$ExtClassLoader.getExtURLs(Launcher.java:190) >> at sun.misc.Launcher$ExtClassLoader.(Launcher.java:161) >> at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:145) >> at sun.misc.Launcher$ExtClassLoader$1.run(Launcher.java:139) >> at java.security.AccessController.doPrivileged(Native Method) >> at >> sun.misc.Launcher$ExtClassLoader.getExtClassLoader(Launcher.java:138) >> at sun.misc.Launcher.(Launcher.java:71) >> at sun.misc.Launcher.(Launcher.java:59) >> at java.lang.ClassLoader.initSystemClassLoader(ClassLoader.java:1325) >> at java.lang.ClassLoader.getSystemClassLoader(ClassLoader.java:1307) >> >> Looking in the classes directory, I see that although URL.class is >> present, >> Parts.class is not. Parts.class is a package private class defined at the >> top level in the same source file as URL.java. >> >> Does anyone recognize this problem? How do I work around this? Do I need >> a >> new bootstrap build, or different compiler options? >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From xiomara.jayasena at sun.com Mon Mar 9 18:50:48 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 18:50:48 +0000 Subject: hg: jdk7/build: 2 new changesets Message-ID: <20090309185048.3A131EA7D@hg.openjdk.java.net> Changeset: 28ba432554f4 Author: xdono Date: 2009-03-05 09:48 -0800 URL: http://hg.openjdk.java.net/jdk7/build/rev/28ba432554f4 Added tag jdk7-b50 for changeset 5111e13e44e5 ! .hgtags Changeset: c2a7f3471532 Author: xdono Date: 2009-03-09 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/c2a7f3471532 Merge From xiomara.jayasena at sun.com Mon Mar 9 18:53:42 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 18:53:42 +0000 Subject: hg: jdk7/build/corba: Added tag jdk7-b50 for changeset 0edbd0074b02 Message-ID: <20090309185344.05E3EEA84@hg.openjdk.java.net> Changeset: 12f178e7737f Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/12f178e7737f Added tag jdk7-b50 for changeset 0edbd0074b02 ! .hgtags From xiomara.jayasena at sun.com Mon Mar 9 18:59:28 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 18:59:28 +0000 Subject: hg: jdk7/build/hotspot: 2 new changesets Message-ID: <20090309185932.A5B31EA89@hg.openjdk.java.net> Changeset: 67f831f73d34 Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/67f831f73d34 Added tag jdk7-b50 for changeset dae503d9f04c ! .hgtags Changeset: f5eac45b1641 Author: xdono Date: 2009-03-09 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/f5eac45b1641 Merge From xiomara.jayasena at sun.com Mon Mar 9 19:08:04 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 19:08:04 +0000 Subject: hg: jdk7/build/jaxp: Added tag jdk7-b50 for changeset e8514e2be76d Message-ID: <20090309190806.71D99EA8E@hg.openjdk.java.net> Changeset: e2da22440463 Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/e2da22440463 Added tag jdk7-b50 for changeset e8514e2be76d ! .hgtags From xiomara.jayasena at sun.com Mon Mar 9 19:12:14 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 19:12:14 +0000 Subject: hg: jdk7/build/jaxws: Added tag jdk7-b50 for changeset 5be52db581f1 Message-ID: <20090309191215.BE72AEA93@hg.openjdk.java.net> Changeset: 3f309316d6bf Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/3f309316d6bf Added tag jdk7-b50 for changeset 5be52db581f1 ! .hgtags From xiomara.jayasena at sun.com Mon Mar 9 19:17:05 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 19:17:05 +0000 Subject: hg: jdk7/build/jdk: 2 new changesets Message-ID: <20090309191742.9B791EA98@hg.openjdk.java.net> Changeset: e0a8a9ccc4a4 Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/e0a8a9ccc4a4 Added tag jdk7-b50 for changeset 58ba2cd5a250 ! .hgtags Changeset: 83c0526fb9c9 Author: xdono Date: 2009-03-09 11:43 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/83c0526fb9c9 Merge From xiomara.jayasena at sun.com Mon Mar 9 19:28:22 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 19:28:22 +0000 Subject: hg: jdk7/build/langtools: Added tag jdk7-b50 for changeset 46f2f6ed96f1 Message-ID: <20090309192825.A7EBBEA9D@hg.openjdk.java.net> Changeset: 4b72dc8fc51e Author: xdono Date: 2009-03-05 09:49 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/4b72dc8fc51e Added tag jdk7-b50 for changeset 46f2f6ed96f1 ! .hgtags From xiomara.jayasena at sun.com Mon Mar 9 20:41:31 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 20:41:31 +0000 Subject: hg: jdk7/build: 2 new changesets Message-ID: <20090309204131.B1CFFEACB@hg.openjdk.java.net> Changeset: 93c2600a45a4 Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/93c2600a45a4 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! Makefile ! make/Defs-internal.gmk ! make/jdk-rules.gmk ! make/jprt.config ! make/jprt.gmk Changeset: 0f0189d55ce4 Author: xdono Date: 2009-03-09 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/rev/0f0189d55ce4 Merge From xiomara.jayasena at sun.com Mon Mar 9 20:46:24 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 20:46:24 +0000 Subject: hg: jdk7/build/corba: 2 new changesets Message-ID: <20090309204626.16558EAD0@hg.openjdk.java.net> Changeset: e2f388853a9d Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/e2f388853a9d 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/com/sun/corba/minclude/com_sun_corba_se_impl_dynamicany.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_encoding.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_ior.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_orbutil.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_impl_protocol.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_legacy_interceptor.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_monitoring.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_presentation_rmi.jmk ! make/com/sun/corba/minclude/com_sun_corba_se_spi_transport.jmk ! make/com/sun/corba/minclude/org_omg_CosNaming.jmk ! make/com/sun/corba/minclude/org_omg_DynamicAny.jmk ! make/com/sun/corba/minclude/org_omg_PortableInterceptor.jmk ! make/com/sun/corba/se/sources/Makefile ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-utils.gmk ! make/common/shared/Defs.gmk ! make/javax/xa/Makefile ! make/jprt.config ! make/org/omg/CORBA/Makefile ! src/share/classes/org/omg/CORBA/ir.idl ! src/share/classes/org/omg/DynamicAny/DynamicAny.idl Changeset: 3174f87bcd7c Author: xdono Date: 2009-03-09 13:33 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/3174f87bcd7c Merge From xiomara.jayasena at sun.com Mon Mar 9 20:51:27 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 20:51:27 +0000 Subject: hg: jdk7/build/hotspot: 2 new changesets Message-ID: <20090309205132.5419DEAD7@hg.openjdk.java.net> Changeset: 0fbdb4381b99 Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0fbdb4381b99 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! agent/src/os/linux/ps_core.c ! agent/src/os/solaris/proc/saproc.cpp ! make/hotspot_version ! make/linux/makefiles/adlc.make ! make/linux/makefiles/gcc.make ! make/solaris/makefiles/adlc.make ! src/cpu/sparc/vm/jni_sparc.h ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/bytecodeInterpreter_x86.inline.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/c1_Runtime1_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/frame_x86.inline.hpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_32.hpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/interpreterRT_x86_32.cpp ! src/cpu/x86/vm/jni_x86.h ! src/cpu/x86/vm/runtime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/stubGenerator_x86_32.cpp ! src/cpu/x86/vm/stubGenerator_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/vm/os_linux.cpp ! src/os/solaris/vm/os_solaris.cpp ! src/os/windows/vm/os_windows.cpp ! src/os_cpu/linux_x86/vm/os_linux_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/solaris_x86_32.il ! src/os_cpu/solaris_x86/vm/solaris_x86_64.il ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/adlparse.hpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/asm/codeBuffer.cpp ! src/share/vm/c1/c1_LIRGenerator.cpp ! src/share/vm/c1/c1_Optimizer.cpp ! src/share/vm/c1/c1_Runtime1.cpp ! src/share/vm/classfile/classFileParser.cpp ! src/share/vm/classfile/javaClasses.cpp ! src/share/vm/classfile/javaClasses.hpp ! src/share/vm/classfile/systemDictionary.cpp ! src/share/vm/classfile/systemDictionary.hpp ! src/share/vm/classfile/vmSymbols.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/compactibleFreeListSpace.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.hpp ! src/share/vm/gc_implementation/g1/collectionSetChooser.hpp ! src/share/vm/gc_implementation/g1/concurrentG1Refine.hpp ! src/share/vm/gc_implementation/g1/concurrentMark.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.inline.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1MMUTracker.hpp ! src/share/vm/gc_implementation/g1/g1OopClosures.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/g1_specialized_oop_closures.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.cpp ! src/share/vm/gc_implementation/g1/heapRegionRemSet.hpp ! src/share/vm/gc_implementation/g1/heapRegionSeq.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/g1/survRateGroup.cpp ! src/share/vm/gc_implementation/g1/survRateGroup.hpp ! src/share/vm/gc_implementation/includeDB_gc_concurrentMarkSweep ! src/share/vm/gc_implementation/includeDB_gc_g1 ! src/share/vm/gc_implementation/includeDB_gc_parallelScavenge ! src/share/vm/gc_implementation/includeDB_gc_shared ! src/share/vm/gc_implementation/parNew/parGCAllocBuffer.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.cpp ! src/share/vm/gc_implementation/parNew/parNewGeneration.hpp ! src/share/vm/gc_implementation/parallelScavenge/parallelScavengeHeap.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweepDecorator.cpp ! src/share/vm/gc_implementation/parallelScavenge/psOldGen.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.hpp ! src/share/vm/gc_implementation/parallelScavenge/psPromotionManager.cpp ! src/share/vm/gc_implementation/parallelScavenge/psScavenge.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.cpp ! src/share/vm/gc_implementation/parallelScavenge/psVirtualspace.hpp ! src/share/vm/gc_implementation/parallelScavenge/psYoungGen.cpp ! src/share/vm/gc_implementation/shared/ageTable.cpp ! src/share/vm/gc_implementation/shared/ageTable.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.hpp ! src/share/vm/gc_implementation/shared/mutableSpace.cpp ! src/share/vm/gc_implementation/shared/mutableSpace.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/gc_interface/collectedHeap.inline.hpp ! src/share/vm/includeDB_compiler2 ! src/share/vm/includeDB_core ! src/share/vm/includeDB_features ! src/share/vm/includeDB_gc ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.hpp ! src/share/vm/interpreter/rewriter.cpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/libadt/port.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/genCollectedHeap.hpp ! src/share/vm/memory/generation.cpp ! src/share/vm/memory/generation.hpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/oopFactory.cpp ! src/share/vm/memory/oopFactory.hpp ! src/share/vm/memory/permGen.cpp ! src/share/vm/memory/referenceProcessor.cpp ! src/share/vm/memory/sharedHeap.cpp ! src/share/vm/memory/sharedHeap.hpp ! src/share/vm/memory/space.cpp ! src/share/vm/memory/space.hpp ! src/share/vm/memory/tenuredGeneration.cpp ! src/share/vm/memory/threadLocalAllocBuffer.cpp ! src/share/vm/memory/universe.cpp ! src/share/vm/memory/universe.hpp ! src/share/vm/oops/arrayOop.hpp ! src/share/vm/oops/constMethodKlass.cpp ! src/share/vm/oops/constMethodKlass.hpp ! src/share/vm/oops/constMethodOop.hpp ! src/share/vm/oops/constantPoolKlass.cpp ! src/share/vm/oops/constantPoolKlass.hpp ! src/share/vm/oops/constantPoolOop.cpp ! src/share/vm/oops/constantPoolOop.hpp ! src/share/vm/oops/cpCacheKlass.cpp ! src/share/vm/oops/cpCacheKlass.hpp ! src/share/vm/oops/cpCacheOop.hpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.cpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/oops/oop.hpp ! src/share/vm/oops/oop.inline.hpp ! src/share/vm/oops/oopsHierarchy.hpp ! src/share/vm/oops/typeArrayKlass.cpp ! src/share/vm/oops/typeArrayKlass.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/c2_globals.hpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/graphKit.hpp ! src/share/vm/opto/idealGraphPrinter.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/lcm.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/opto/vectornode.cpp ! src/share/vm/prims/jni.cpp ! src/share/vm/prims/jvm.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiTagMap.cpp ! src/share/vm/runtime/arguments.cpp ! src/share/vm/runtime/arguments.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/javaCalls.cpp ! src/share/vm/runtime/memprofiler.cpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/os.hpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/synchronizer.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/management.cpp ! src/share/vm/utilities/globalDefinitions_gcc.hpp ! src/share/vm/utilities/globalDefinitions_sparcWorks.hpp ! src/share/vm/utilities/ostream.cpp ! src/share/vm/utilities/taskqueue.cpp ! src/share/vm/utilities/taskqueue.hpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp ! src/share/vm/utilities/workgroup.hpp ! test/Makefile ! test/compiler/6757316/Test6757316.java ! test/compiler/6758234/Test6758234.java ! test/compiler/6775880/Test.java ! test/compiler/6778657/Test.java Changeset: ce2272390558 Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ce2272390558 Merge From xiomara.jayasena at sun.com Mon Mar 9 20:56:09 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 20:56:09 +0000 Subject: hg: jdk7/build/jaxp: 2 new changesets Message-ID: <20090309205612.E54C9EADC@hg.openjdk.java.net> Changeset: 6698e1f801df Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/6698e1f801df 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/Makefile Changeset: ae890d80d5df Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/ae890d80d5df Merge From xiomara.jayasena at sun.com Mon Mar 9 21:00:56 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 21:00:56 +0000 Subject: hg: jdk7/build/jaxws: 2 new changesets Message-ID: <20090309210059.5E074EAE1@hg.openjdk.java.net> Changeset: d1525894c1a8 Author: xdono Date: 2009-03-09 13:28 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/d1525894c1a8 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/Makefile Changeset: 41a66a42791b Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/41a66a42791b Merge From xiomara.jayasena at sun.com Mon Mar 9 21:05:42 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 21:05:42 +0000 Subject: hg: jdk7/build/jdk: 2 new changesets Message-ID: <20090309210612.8599CEAE8@hg.openjdk.java.net> Changeset: ca0976a15868 Author: xdono Date: 2009-03-09 13:29 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ca0976a15868 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! src/share/classes/java/lang/Thread.java ! src/share/classes/java/util/regex/Matcher.java ! src/share/classes/java/util/regex/Pattern.java ! src/share/classes/sun/security/krb5/Realm.java ! src/share/classes/sun/security/x509/AuthorityInfoAccessExtension.java ! src/share/native/java/util/zip/zip_util.c ! src/share/native/java/util/zip/zip_util.h ! src/solaris/native/java/net/NetworkInterface.c Changeset: b1e3e3b8e6b2 Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b1e3e3b8e6b2 Merge From xiomara.jayasena at sun.com Mon Mar 9 21:10:48 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 09 Mar 2009 21:10:48 +0000 Subject: hg: jdk7/build/langtools: 2 new changesets Message-ID: <20090309211051.C09B6EAEF@hg.openjdk.java.net> Changeset: 03bcd66bd8e7 Author: xdono Date: 2009-03-09 13:29 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/03bcd66bd8e7 6814575: Update copyright year Summary: Update copyright for files that have been modified in 2009, up to 03/09 Reviewed-by: katleman, tbell, ohair ! make/build.properties ! make/build.xml ! make/netbeans/langtools/build.xml ! make/netbeans/langtools/nbproject/project.xml ! make/netbeans/langtools/nbproject/standard-context-menu-items.ent ! make/netbeans/langtools/nbproject/standard-ide-actions.ent ! make/tools/SelectTool/SelectToolTask.java ! src/share/classes/com/sun/tools/apt/comp/AnnotationProcessingError.java ! src/share/classes/com/sun/tools/apt/comp/Apt.java ! src/share/classes/com/sun/tools/apt/comp/UsageMessageNeededException.java ! src/share/classes/com/sun/tools/apt/main/JavaCompiler.java ! src/share/classes/com/sun/tools/apt/mirror/apt/RoundCompleteEventImpl.java ! src/share/classes/com/sun/tools/apt/mirror/declaration/AnnotationProxyMaker.java ! src/share/classes/com/sun/tools/apt/mirror/type/TypeVariableImpl.java ! src/share/classes/com/sun/tools/classfile/Annotation.java ! src/share/classes/com/sun/tools/classfile/AttributeException.java ! src/share/classes/com/sun/tools/classfile/Code_attribute.java ! src/share/classes/com/sun/tools/classfile/ConstantPool.java ! src/share/classes/com/sun/tools/classfile/ConstantPoolException.java ! src/share/classes/com/sun/tools/classfile/Descriptor.java ! src/share/classes/com/sun/tools/classfile/DescriptorException.java ! src/share/classes/com/sun/tools/classfile/StackMapTable_attribute.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConfigurationImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletOutputImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/Configuration.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/DocletAbortException.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/MessageRetriever.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/SourceToHTMLConverter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/util/Util.java ! src/share/classes/com/sun/tools/javac/api/DiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/api/Messages.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Attr.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/comp/Flow.java ! src/share/classes/com/sun/tools/javac/comp/Infer.java ! 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/main/OptionName.java ! src/share/classes/com/sun/tools/javac/main/RecognizedOptions.java ! src/share/classes/com/sun/tools/javac/parser/JavacParser.java ! src/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/resources/javac.properties ! src/share/classes/com/sun/tools/javac/tree/JCTree.java ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/LayoutCharacters.java ! src/share/classes/com/sun/tools/javac/util/Log.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javadoc/ClassDocImpl.java ! src/share/classes/com/sun/tools/javadoc/Comment.java ! src/share/classes/com/sun/tools/javadoc/DocEnv.java ! src/share/classes/com/sun/tools/javadoc/DocImpl.java ! src/share/classes/com/sun/tools/javadoc/DocletInvoker.java ! src/share/classes/com/sun/tools/javadoc/ExecutableMemberDocImpl.java ! src/share/classes/com/sun/tools/javadoc/FieldDocImpl.java ! src/share/classes/com/sun/tools/javadoc/JavadocClassReader.java ! src/share/classes/com/sun/tools/javadoc/JavadocTool.java ! src/share/classes/com/sun/tools/javadoc/Messager.java ! src/share/classes/com/sun/tools/javadoc/PackageDocImpl.java ! src/share/classes/com/sun/tools/javadoc/RootDocImpl.java ! src/share/classes/com/sun/tools/javadoc/SourcePositionImpl.java ! src/share/classes/com/sun/tools/javadoc/TypeMaker.java ! src/share/classes/com/sun/tools/javah/Gen.java ! src/share/classes/com/sun/tools/javap/InternalError.java ! src/share/classes/sun/tools/javap/JavapPrinter.java ! test/tools/javac/6668794/badClass/Test.java ! test/tools/javac/cast/6558559/T6558559a.java ! test/tools/javac/cast/6558559/T6558559b.java ! test/tools/javac/cast/6665356/T6665356.java ! test/tools/javac/generics/6723444/T6723444.java ! test/tools/javac/generics/6729401/T6729401.java ! test/tools/javac/generics/rare/6665356/T6665356.java ! test/tools/javac/processing/model/testgetallmembers/Main.java ! test/tools/javadoc/6176978/T6176978.java ! test/tools/javadoc/6176978/X.java Changeset: 2c0076945b1a Author: xdono Date: 2009-03-09 13:34 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/2c0076945b1a Merge From kelly.ohair at sun.com Thu Mar 12 04:52:11 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Thu, 12 Mar 2009 04:52:11 +0000 Subject: hg: jdk7/build/corba: 2 new changesets Message-ID: <20090312045214.31418ED1C@hg.openjdk.java.net> Changeset: 53d5b45f73ab Author: ohair Date: 2009-03-11 14:38 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/53d5b45f73ab 6790292: BOOTDIR of jdk6 u12 will not work with jdk7 builds Reviewed-by: tbell ! make/common/Rules.gmk Changeset: 9c0cc0d0eca2 Author: ohair Date: 2009-03-11 17:31 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/9c0cc0d0eca2 6816311: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Reviewed-by: tbell ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Defs-windows.gmk ! src/windows/resource/version.rc From Kelly.Ohair at Sun.COM Sun Mar 15 01:50:26 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Sat, 14 Mar 2009 18:50:26 -0700 Subject: Windows 64bit SDK changes (VS2008) Message-ID: <49BC5EE2.3060808@sun.com> I am currently working on the Windows 2003 64bit Platform SDK update. Thought Windows people might like to see a webrev. ;^) http://cr.openjdk.java.net/~ohair/win64-jdk/webrev/ (Had to try out Tim's cr.openjdk site. ;^) README-builds.html changes are yet to come. --- For those of you unfamiliar with Windows 64bit building, the 64bit version of the Visual Studio compilers are provided in the Windows SDK. This new 64bit compiler is basically Visual Studio 2008. The SDK is available at: http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en -kto From kelly.ohair at sun.com Mon Mar 16 21:26:14 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Mon, 16 Mar 2009 21:26:14 +0000 Subject: hg: jdk7/build/jdk: 6816311: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Message-ID: <20090316212647.36B38E06E@hg.openjdk.java.net> Changeset: 711a9fb838d1 Author: ohair Date: 2009-03-16 11:24 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/711a9fb838d1 6816311: Changes to allow builds with latest Windows SDK 6.1 on 64bit Windows 2003 Summary: These changes create a preference for the newer 6.1 SDK on Windows. Reviewed-by: tbell ! make/common/Defs-windows.gmk ! make/common/shared/Compiler-gcc.gmk ! make/common/shared/Compiler-msvc.gmk ! make/common/shared/Compiler-sun.gmk ! make/common/shared/Defs-versions.gmk ! make/common/shared/Defs-windows.gmk ! make/common/shared/Sanity-Settings.gmk ! make/common/shared/Sanity.gmk ! src/windows/native/sun/windows/awt.rc ! src/windows/resource/version.rc From xiomara.jayasena at sun.com Mon Mar 16 23:25:18 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 16 Mar 2009 23:25:18 +0000 Subject: hg: jdk7/build/corba: 6 new changesets Message-ID: <20090316232523.EB063E0A4@hg.openjdk.java.net> Changeset: 9e6c48c2582d Author: jjg Date: 2009-02-26 18:28 -0800 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/9e6c48c2582d 6809563: corba build in JDK uses invalid bootclasspath for javah Reviewed-by: ohair ! make/common/shared/Defs-java.gmk Changeset: db35452e8965 Author: jjg Date: 2009-02-26 18:32 -0800 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/db35452e8965 6810915: Sun proprietary warnings in JDK build Reviewed-by: ohair ! make/Makefile ! make/common/shared/Defs-java.gmk Changeset: 082f59f5ac64 Author: tbell Date: 2009-03-02 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/082f59f5ac64 Merge Changeset: ec634b3aa302 Author: tbell Date: 2009-03-06 10:52 -0800 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/ec634b3aa302 Merge Changeset: c471ac1a1770 Author: tbell Date: 2009-03-09 23:36 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/c471ac1a1770 Merge Changeset: 3eb8f1047a74 Author: xdono Date: 2009-03-16 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/corba/rev/3eb8f1047a74 Merge From xiomara.jayasena at sun.com Mon Mar 16 23:29:06 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 16 Mar 2009 23:29:06 +0000 Subject: hg: jdk7/build/jdk: 22 new changesets Message-ID: <20090316233336.99BEEE0AF@hg.openjdk.java.net> Changeset: 266358f13a6f Author: dl Date: 2009-02-24 14:01 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/266358f13a6f 6803402: Race condition in AbstractQueuedSynchronizer Summary: Read fields in reverse initialization order Reviewed-by: martin ! src/share/classes/java/util/concurrent/locks/AbstractQueuedLongSynchronizer.java ! src/share/classes/java/util/concurrent/locks/AbstractQueuedSynchronizer.java Changeset: f9c187839d72 Author: kevinw Date: 2009-02-24 19:03 +0000 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/f9c187839d72 6809463: Missing license header in test LargeZipFile.java Reviewed-by: alanb ! test/java/util/zip/ZipFile/LargeZipFile.java Changeset: dde3fe2e8164 Author: kevinw Date: 2009-02-25 14:32 +0000 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/dde3fe2e8164 Merge Changeset: 2fb53eb9df14 Author: mchung Date: 2009-02-26 14:36 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/2fb53eb9df14 6801467: Defer get the launcher resource bundle until it's needed Summary: Lazily initialize the launcher resource bundle Reviewed-by: ksrini, darcy ! src/share/classes/sun/launcher/LauncherHelper.java Changeset: 4f0b6455a977 Author: jjg Date: 2009-02-26 18:51 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/4f0b6455a977 6810915: Sun proprietary warnings in JDK build Reviewed-by: ohair ! make/common/shared/Defs-java.gmk ! make/docs/Makefile ! make/javax/swing/beaninfo/SwingBeans.gmk Changeset: de1d02ad2d1d Author: mchung Date: 2009-02-27 13:43 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/de1d02ad2d1d 6799689: Make sun.misc.FloatingDecimal.hexFloatPattern static field initialized lazily Summary: Lazily initialize the hexFloatPattern static field Reviewed-by: darcy ! src/share/classes/sun/misc/FloatingDecimal.java Changeset: 0da45c759116 Author: mchung Date: 2009-02-27 16:34 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/0da45c759116 6809504: Remove enctype="text/xml" from the offline registration page Summary: Remove enctype="text/xml" from register.html and other localized versions Reviewed-by: ksrini ! src/share/classes/com/sun/servicetag/resources/register.html ! src/share/classes/com/sun/servicetag/resources/register_ja.html ! src/share/classes/com/sun/servicetag/resources/register_zh_CN.html Changeset: b656e842e1be Author: xuelei Date: 2009-03-02 23:17 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/b656e842e1be 6549506: Specification of Permission.toString() method contradicts with JDK implementation Summary: update the spec, and add double quotes around component. Reviewed-by: weijun ! src/share/classes/java/security/Permission.java + test/java/security/Permission/ToString.java Changeset: 7546743f4cc0 Author: tbell Date: 2009-03-02 15:10 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7546743f4cc0 Merge Changeset: 07d2550f5c84 Author: mchung Date: 2009-03-03 19:26 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/07d2550f5c84 6799230: Lazily load java.lang.annotation.Annotation class Summary: Remove the static EMPTY_ANNOTATION_ARRAY field; add AnnotationParser.toArray method Reviewed-by: darcy ! src/share/classes/java/lang/Class.java ! src/share/classes/java/lang/reflect/Constructor.java ! src/share/classes/java/lang/reflect/Field.java ! src/share/classes/java/lang/reflect/Method.java ! src/share/classes/sun/reflect/annotation/AnnotationParser.java Changeset: a8d9e8cb38bb Author: weijun Date: 2009-03-04 15:09 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/a8d9e8cb38bb 6705872: SecureRandom number init is taking too long on a java.io.tmpdir with a large number of files. Reviewed-by: xuelei, alanb ! src/share/classes/sun/security/provider/SeedGenerator.java Changeset: 94d02968a504 Author: chegar Date: 2009-03-04 13:28 +0000 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/94d02968a504 6775145: ClassLoaderUtil.releaseLoader calls System.out.println ("classLoader = " + classLoader) Summary: Remove System.out debugging statements Reviewed-by: michaelm ! src/share/classes/sun/misc/ClassLoaderUtil.java Changeset: 03001e92d155 Author: chegar Date: 2009-03-04 13:36 +0000 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/03001e92d155 6737323: Typo in javadoc for SocketPermission Summary: Remove redundant line form class description Reviewed-by: jccollet ! src/share/classes/java/net/SocketPermission.java Changeset: 6568cd51ae12 Author: sherman Date: 2009-03-04 09:26 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/6568cd51ae12 6812879: Excess code line in ArrayList method Summary: Removed the line of "oldData" which is no longer used. Reviewed-by: martin ! src/share/classes/java/util/ArrayList.java Changeset: 97da21737d9e Author: weijun Date: 2009-03-05 14:49 +0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/97da21737d9e 6813402: keytool cannot -printcert entries without extensions Reviewed-by: xuelei ! src/share/classes/sun/security/tools/KeyTool.java + test/sun/security/tools/keytool/NoExtNPE.sh Changeset: da9d0283a496 Author: valeriep Date: 2009-03-03 19:50 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/da9d0283a496 6812738: SSL stress test with GF leads to 32 bit max process size in less than 5 minutes with PCKS11 provider Summary: Removed finalize() and add more error handling to native code Reviewed-by: vinnie ! src/share/classes/sun/security/pkcs11/P11Key.java ! src/share/classes/sun/security/pkcs11/P11RSACipher.java ! src/share/classes/sun/security/pkcs11/P11SecretKeyFactory.java ! src/share/native/sun/security/pkcs11/wrapper/p11_convert.c ! src/share/native/sun/security/pkcs11/wrapper/p11_crypt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_digest.c ! src/share/native/sun/security/pkcs11/wrapper/p11_dual.c ! src/share/native/sun/security/pkcs11/wrapper/p11_general.c ! src/share/native/sun/security/pkcs11/wrapper/p11_keymgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_mutex.c ! src/share/native/sun/security/pkcs11/wrapper/p11_objmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sessmgmt.c ! src/share/native/sun/security/pkcs11/wrapper/p11_sign.c ! src/share/native/sun/security/pkcs11/wrapper/p11_util.c ! src/share/native/sun/security/pkcs11/wrapper/pkcs11wrapper.h Changeset: 7b3cfde54812 Author: valeriep Date: 2009-03-05 11:44 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/7b3cfde54812 Merge Changeset: 2b6cf18aeb6f Author: tbell Date: 2009-03-06 10:52 -0800 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/2b6cf18aeb6f Merge Changeset: c769c46c27ce Author: mullan Date: 2009-03-09 09:46 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/c769c46c27ce 6787130: java.policy file contains stale link to http://java.sun.com/notes Reviewed-by: weijun ! src/share/lib/security/java.policy Changeset: aa48deaf9af4 Author: mullan Date: 2009-03-09 09:56 -0400 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/aa48deaf9af4 Merge Changeset: 175504cc095d Author: tbell Date: 2009-03-09 23:37 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/175504cc095d Merge Changeset: ece878b04159 Author: xdono Date: 2009-03-16 16:18 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/ece878b04159 Merge From xiomara.jayasena at sun.com Mon Mar 16 23:41:06 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Mon, 16 Mar 2009 23:41:06 +0000 Subject: hg: jdk7/build/langtools: 10 new changesets Message-ID: <20090316234124.EAA78E0B4@hg.openjdk.java.net> Changeset: 435d5d9bb87d Author: darcy Date: 2009-02-24 17:16 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/435d5d9bb87d 6501749: 6501749 Filer should state connection between created files and root elements Reviewed-by: jjg ! src/share/classes/javax/annotation/processing/Filer.java Changeset: 1fbc1cc6e260 Author: darcy Date: 2009-02-24 17:48 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/1fbc1cc6e260 6498938: Faulty comparison of TypeMirror objects in getElementsAnnotatedWith implementation Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/processing/JavacRoundEnvironment.java + test/tools/javac/processing/environment/round/Foo.java ! test/tools/javac/processing/environment/round/TestElementsAnnotatedWith.java Changeset: 5240b1120530 Author: bpatel Date: 2009-02-27 18:57 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/5240b1120530 6786690: Javadoc HTML WCAG 2.0 accessibility issues in standard doclet - DL tag and nesting issue Reviewed-by: jjg ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractIndexWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AbstractMemberWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeOptionalMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeRequiredMemberWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/AnnotationTypeWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/ConstructorWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/EnumConstantWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/FieldWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialMethodWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/MethodWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/NestedClassWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/PackageTreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/TagletWriterImpl.java ! src/share/classes/com/sun/tools/doclets/formats/html/TreeWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! test/com/sun/javadoc/AuthorDD/AuthorDD.java ! test/com/sun/javadoc/testClassCrossReferences/TestClassCrossReferences.java ! test/com/sun/javadoc/testConstructorIndent/TestConstructorIndent.java ! test/com/sun/javadoc/testDeprecatedDocs/TestDeprecatedDocs.java ! test/com/sun/javadoc/testExternalOverridenMethod/TestExternalOverridenMethod.java ! test/com/sun/javadoc/testHref/TestHref.java + test/com/sun/javadoc/testHtmlDefinitionListTag/TestHtmlDefinitionListTag.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C1.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C2.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C3.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C4.java + test/com/sun/javadoc/testHtmlDefinitionListTag/pkg1/C5.java ! test/com/sun/javadoc/testIndex/TestIndex.java ! test/com/sun/javadoc/testInterface/TestInterface.java ! test/com/sun/javadoc/testLinkOption/TestLinkOption.java ! test/com/sun/javadoc/testLinkTaglet/TestLinkTaglet.java ! test/com/sun/javadoc/testMemberInheritence/TestMemberInheritence.java ! test/com/sun/javadoc/testNewLanguageFeatures/TestNewLanguageFeatures.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethods.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPackageFlag.java ! test/com/sun/javadoc/testOverridenMethods/TestOverridenPrivateMethodsWithPrivateFlag.java ! test/com/sun/javadoc/testParamTaglet/TestParamTaglet.java ! test/com/sun/javadoc/testPrivateClasses/TestPrivateClasses.java ! test/com/sun/javadoc/testSerializedFormDeprecationInfo/TestSerializedFormDeprecationInfo.java ! test/com/sun/javadoc/testThrowsTag/TestThrowsTag.java Changeset: 2f4c4900ca2b Author: tbell Date: 2009-03-02 15:11 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/2f4c4900ca2b Merge Changeset: 850869f70213 Author: mcimadamore Date: 2009-03-05 17:24 +0000 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/850869f70213 6467183: javac fails to raise unchecked warning on cast of parameterized generic subclass Summary: cleanup code for generating unchecked cast warnings Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/code/Types.java + test/tools/javac/cast/6467183/T6467183a.java + test/tools/javac/cast/6467183/T6467183a.out + test/tools/javac/cast/6467183/T6467183b.java Changeset: 84a18d7da478 Author: mcimadamore Date: 2009-03-05 17:24 +0000 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/84a18d7da478 6804733: javac generates spourious diagnostics for ill-formed type-variable bounds Summary: fixed algorithm for checking cycles in typevar declarations Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Check.java + test/tools/javac/generics/typevars/6804733/T6804733.java + test/tools/javac/generics/typevars/6804733/T6804733.out Changeset: 9711a6c2db7e Author: mcimadamore Date: 2009-03-05 17:25 +0000 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/9711a6c2db7e 6807255: LineNumberTable wrong if enhanced-for-loops are used Summary: end position of iterable for-each loop was not set properly Reviewed-by: jjg ! src/share/classes/com/sun/tools/javac/comp/Lower.java Changeset: 86b60aa941c6 Author: mcimadamore Date: 2009-03-05 17:25 +0000 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/86b60aa941c6 6799605: Basic/Raw formatters should use type/symbol printer instead of toString() Summary: create new combo type/symbol visitor printer used by all diagnostic formatters Reviewed-by: jjg + src/share/classes/com/sun/tools/javac/code/Printer.java ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java + test/tools/javac/Diagnostics/6799605/T6799605.java + test/tools/javac/Diagnostics/6799605/T6799605.out ! test/tools/javac/NestedInnerClassNames.out ! test/tools/javac/T6241723.out ! test/tools/javac/depDocComment/SuppressDeprecation.out ! test/tools/javac/mandatoryWarnings/deprecated/Test3.out ! test/tools/javac/mandatoryWarnings/deprecated/Test3b.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4b.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4c.out ! test/tools/javac/mandatoryWarnings/deprecated/Test4d.out ! test/tools/javac/positions/T6253161.out ! test/tools/javac/positions/T6253161a.out ! test/tools/javac/warnings/Deprecation.lintAll.out ! test/tools/javac/warnings/Deprecation.lintDeprecation.out Changeset: 6d00caa683b3 Author: tbell Date: 2009-03-06 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/6d00caa683b3 Merge Changeset: 8c55d5b0ed71 Author: tbell Date: 2009-03-09 23:53 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/8c55d5b0ed71 Merge ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlDocletWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/HtmlSerialFieldWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlDocWriter.java ! src/share/classes/com/sun/tools/doclets/formats/html/markup/HtmlWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/SerializedFormWriter.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/builders/SerializedFormBuilder.java ! src/share/classes/com/sun/tools/doclets/internal/toolkit/resources/doclet.xml ! src/share/classes/com/sun/tools/javac/code/Types.java ! src/share/classes/com/sun/tools/javac/comp/Check.java ! src/share/classes/com/sun/tools/javac/resources/compiler.properties ! src/share/classes/com/sun/tools/javac/util/AbstractDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/BasicDiagnosticFormatter.java ! src/share/classes/com/sun/tools/javac/util/RawDiagnosticFormatter.java From aph at redhat.com Tue Mar 17 14:18:35 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 17 Mar 2009 14:18:35 +0000 Subject: Debug information Message-ID: <49BFB13B.2000602@redhat.com> In GNU/Linux/BSD/etc systems we normally want to be able to debug installed packages. So, in many distributions there is a rule that all packages must be built with full debug information. This isn't quite as bloated as it might sound, as we extract all such debug information files and put it into separate debug packages. So, when someone has a problem that we need to debug we can download the debug package to their computer and attach a debugger without needing to recompile anything. As far as I've been able to determine there is no simple way to turn on debug information in OpenJDK builds. So, in IcedTea we have a number of patches that turn on debugging in various makefiles and build.xml files, but of course we miss things. I recently tried to debug javac but discovered that it wasn't possible because it hadn't been compiled with full debug info: References: <49BFB13B.2000602@redhat.com> Message-ID: <49C019BF.6010804@sun.com> Andrew, A few pieces of information... you probably already know most of this... * Debugging -g -O code has it's limitations, I assume that is understood. Sometimes local variable information is not included, sometimes the source line to instruction mapping is a bit hectic or missing. It can be very valuable at times, just strange. * Using javac -g will just add information about local variables, source line information is always there by default. And you can't easily 'strip' debug information from class files that I am aware of. I'm a bit puzzled how you can remove the debug information from the classfiles and put that in a separate package. * It has been my experience that the resulting gcc object code (machine instructions in the .text and data in the .data sections) from building with and without -g can be different. An a.out built with 'cc -g -O' and then stripped, is not the same thing as an a.out built with just 'cc -O' in all cases. Or at least that has been my experience. If people are willing to accept any loss of optimization that '-g -O' might cause, that is fine, just making the observation. * A "debug" build sometimes means that the native code includes the assert() coding, valuable runtime checking, but potentially a major performance problem and does increase the code size. Did you mean to include assert() code? I assume not. Our JDK "fastdebug" builds are built with -g -O and include the assert checking code, so it's a bit of a compromise debug build runs reasonably fast, can be debugged to some degree, asserts can catch problems at runtime, etc. Having said those things, I have always been a supporter of the -g option just adding information to a .o or binary and not letting the desire to debug a program influence the optimizations you asked for. And an ability to just carry the debug information in a sidecar like package is a great concept. So if you come up with some kind of setting for this, I would support adding it, just not sure you will get exactly what you want at first, may need to play with it. -kto Andrew Haley wrote: > In GNU/Linux/BSD/etc systems we normally want to be able to debug > installed packages. So, in many distributions there is a rule that > all packages must be built with full debug information. This isn't > quite as bloated as it might sound, as we extract all such debug > information files and put it into separate debug packages. So, when > someone has a problem that we need to debug we can download the debug > package to their computer and attach a debugger without needing to > recompile anything. > > As far as I've been able to determine there is no simple way to turn > on debug information in OpenJDK builds. So, in IcedTea we have a > number of patches that turn on debugging in various makefiles and > build.xml files, but of course we miss things. I recently tried to > debug javac but discovered that it wasn't possible because it hadn't > been compiled with full debug info: > > source="${compiler.source.level}" debug="true" debuglevel="source,lines" > > Note that there's no way to override the debuglevel without editing > build.xml. > > I think we need a single overriding option when building OpenJDK that > enables debug information everywhere, no matter what the build target. > Note that I'm not talking here about any of OpenJDK's internal > debugging aids, just the -g options passed to javac and the various C > and C++ compilers. > > While I could write this as an IcedTea patch, I believe that it's > something that should go into OpenJDK proper. Would that be > acceptable? > > Thanks, > Andrew. > From kelly.ohair at sun.com Tue Mar 17 22:33:20 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Tue, 17 Mar 2009 22:33:20 +0000 Subject: hg: jdk7/build/jdk: 2 new changesets Message-ID: <20090317223401.18ADAE139@hg.openjdk.java.net> Changeset: bdb4b0b28407 Author: ohair Date: 2009-03-17 13:44 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/bdb4b0b28407 6818565: Regression with fix 6816311: COMPILER_VERSION -> REQUIRED_COMPILER_VERSION Reviewed-by: tbell - make/common/shared/Compiler.gmk ! make/common/shared/Defs-solaris.gmk ! make/common/shared/Defs.gmk Changeset: fea0898259ae Author: ohair Date: 2009-03-17 13:45 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/fea0898259ae Merge From aph at redhat.com Wed Mar 18 10:50:15 2009 From: aph at redhat.com (Andrew Haley) Date: Wed, 18 Mar 2009 10:50:15 +0000 Subject: Debug information In-Reply-To: <49C019BF.6010804@sun.com> References: <49BFB13B.2000602@redhat.com> <49C019BF.6010804@sun.com> Message-ID: <49C0D1E7.6030707@redhat.com> Kelly O'Hair wrote: > A few pieces of information... you probably already know most of this... > > * Debugging -g -O code has it's limitations, I assume that is > understood. Sometimes local variable information is not included, > sometimes the source line to instruction mapping is a bit hectic > or missing. It can be very valuable at times, just strange. Sure. As a matter of interest, we are trying to improve this in gcc. > * Using javac -g will just add information about local variables, > source line information is always there by default. > And you can't easily 'strip' debug information from class files that I > am aware of. I'm a bit puzzled how you can remove the debug > information from the classfiles and put that in a separate package. We can't; I was only referring to ELF format files. I'm not sure we'd want to go to all the palaver to separate debug info from classfiles, as it's not a huge difference in size. (In contrast, the debuginfo in ELF files can be huge.) > * It has been my experience that the resulting gcc object code (machine > instructions in the .text and data in the .data sections) from > building with and without -g can be different. > An a.out built with 'cc -g -O' and then stripped, is not the same > thing as an a.out built with just 'cc -O' in all cases. > Or at least that has been my experience. If so that is a bug in gcc, which is not allowed to change its code generation when debuginfo is enabled. If you find any cases where this happens I'll investigate. > If people are willing to accept any loss of optimization that > '-g -O' might cause, that is fine, just making the observation. > > * A "debug" build sometimes means that the native code includes > the assert() coding, valuable runtime checking, but potentially > a major performance problem and does increase the code size. > Did you mean to include assert() code? I assume not. > Our JDK "fastdebug" builds are built with -g -O and include the > assert checking code, so it's a bit of a compromise debug build > runs reasonably fast, can be debugged to some degree, asserts > can catch problems at runtime, etc. > Having said those things, I have always been a supporter of the -g > option just adding information to a .o or binary and not letting the > desire to debug a program influence the optimizations you asked for. > And an ability to just carry the debug information in a sidecar like > package is a great concept. > > So if you come up with some kind of setting for this, I would support > adding it, just not sure you will get exactly what you want at first, > may need to play with it. I understand. I'm quite happy to accept the fact that getting this upstream into the real OpenJDK repository is going to take longer than getting this into IcedTea. Thanks, Andrew. From xiomara.jayasena at sun.com Wed Mar 18 14:36:22 2009 From: xiomara.jayasena at sun.com (xiomara.jayasena at sun.com) Date: Wed, 18 Mar 2009 14:36:22 +0000 Subject: hg: jdk7/build/hotspot: 49 new changesets Message-ID: <20090318143757.D9880E19C@hg.openjdk.java.net> Changeset: 9e5a6ed08fc9 Author: jmasa Date: 2009-02-17 15:35 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9e5a6ed08fc9 6786346: intermittent Internal Error (src/share/vm/memory/cardTableModRefBS.cpp:226) Summary: Two assertions were incorrectly composed. Reviewed-by: tonyp ! src/share/vm/memory/cardTableModRefBS.cpp Changeset: a0576ae7045f Author: ysr Date: 2009-02-20 11:12 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a0576ae7045f Merge Changeset: 5d75ab5f6698 Author: kvn Date: 2009-02-18 13:53 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/5d75ab5f6698 6807084: AutoBox elimination is broken with compressed oops Summary: Add checks for DecodeN nodes into AutoBox elimination code. Reviewed-by: never ! src/share/vm/opto/memnode.cpp Changeset: 49a36a80b0c7 Author: kvn Date: 2009-02-19 17:38 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/49a36a80b0c7 6802499: EA: assert(false,"unknown node on this path") Summary: Add missing checks for SCMemProj node in Escape analysis code. Reviewed-by: never ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/macro.cpp Changeset: 22e09c0f4b47 Author: twisti Date: 2009-02-23 12:02 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/22e09c0f4b47 6808589: Merge vm_version_x86_{32,64}.{cpp,hpp} Summary: There is very much duplicated code in vm_version_x86_{32,64}.{cpp,hpp}. Refactoring these would help maintainability. Reviewed-by: kvn, never + src/cpu/x86/vm/vm_version_x86.cpp + src/cpu/x86/vm/vm_version_x86.hpp - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.hpp ! src/share/vm/includeDB_core Changeset: 6bea93606c11 Author: kvn Date: 2009-02-23 16:03 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/6bea93606c11 6791572: assert("duplicating node that's already been matched") Summary: Mark inputs for an address expression as shared if there are other uses besides address expressions. Reviewed-by: never ! src/share/vm/opto/matcher.cpp Changeset: e57b6f22d1f3 Author: kvn Date: 2009-02-24 09:53 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/e57b6f22d1f3 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp Changeset: ef3b3df478b9 Author: trims Date: 2009-02-25 22:55 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ef3b3df478b9 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp Changeset: 01ddca3f0730 Author: jcoomes Date: 2009-02-09 13:47 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/01ddca3f0730 Merge Changeset: 3264b1424f72 Author: apangin Date: 2009-02-15 20:09 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3264b1424f72 Merge Changeset: a53107650e8b Author: apangin Date: 2009-02-22 17:11 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/a53107650e8b Merge Changeset: 82e4d969e7cb Author: ikrylov Date: 2009-02-19 04:54 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/82e4d969e7cb 6806046: Hotspot build error when compiled from Visual Studio Summary: Define HOTSPOT_LIB_ARCH in the preprocessor flags of the generated projects Reviewed-by: kamg, xlu ! src/share/tools/MakeDeps/BuildConfig.java Changeset: 1b68c738c0d9 Author: apangin Date: 2009-02-22 17:21 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1b68c738c0d9 Merge Changeset: 7898caac2071 Author: apangin Date: 2009-02-26 14:25 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7898caac2071 Merge - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp Changeset: 3698e8f47799 Author: tonyp Date: 2009-02-24 15:50 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3698e8f47799 6804746: G1: guarantee(variance() > -1.0,"variance should be >= 0") (due to evacuation failure) Summary: Under certain circumstances (evacuation failure) the pause time is not communicated to the policy and, as a result, the pause time field is not initialized properly. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp Changeset: 83ef1482304c Author: jmasa Date: 2009-02-24 22:12 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/83ef1482304c 6806226: Signed integer overflow in growable array code causes JVM crash Summary: Workaround the overflow by doing the intermediate calculations in an unsigned variable. Reviewed-by: ysr, jcoomes ! src/share/vm/utilities/growableArray.cpp Changeset: 59150d6667e1 Author: jmasa Date: 2009-02-24 22:51 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/59150d6667e1 Merge Changeset: 1fa16c3565be Author: ysr Date: 2009-02-27 15:30 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/1fa16c3565be Merge Changeset: 0ad1cb407fa1 Author: never Date: 2009-02-25 10:53 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0ad1cb407fa1 6805427: adlc compiler may generate incorrect machnode emission code Reviewed-by: kvn, twisti ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp Changeset: 07d449658fc7 Author: never Date: 2009-02-25 14:36 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/07d449658fc7 6807963: need tool to make sense of LogCompilaton output Reviewed-by: kvn + src/share/tools/LogCompilation/Makefile + src/share/tools/LogCompilation/README + src/share/tools/LogCompilation/manifest.mf + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/BasicLogEvent.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/CallSite.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Compilation.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Constants.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCleanupReader.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogCompilation.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogEvent.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/LogParser.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/MakeNotEntrantEvent.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Method.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/NMethod.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/Phase.java + src/share/tools/LogCompilation/src/com/sun/hotspot/tools/compiler/UncommonTrapEvent.java Changeset: 523ded093c31 Author: kvn Date: 2009-02-26 14:26 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/523ded093c31 6809798: SafePointScalarObject node placed into incorrect block during GCM Summary: Replace the control edge of a pinned node before scheduling. Reviewed-by: never ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/callnode.cpp ! src/share/vm/opto/callnode.hpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/macro.cpp Changeset: ed6404fac86b Author: never Date: 2009-02-26 16:57 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ed6404fac86b 6810855: KILL vs. TEMP ordering restrictions are too strong Reviewed-by: kvn ! src/share/vm/adlc/formssel.cpp Changeset: dbbe28fc66b5 Author: twisti Date: 2009-02-27 03:35 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/dbbe28fc66b5 6778669: Patch from Red Hat -- fixes compilation errors Summary: Some fixes which are required to build on recent GCCs. Reviewed-by: never, kvn Contributed-by: langel at redhat.com ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! src/share/vm/adlc/adlc.hpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formsopt.cpp ! src/share/vm/adlc/formsopt.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/main.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/includeDB_core ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: ec59443af135 Author: kvn Date: 2009-02-27 08:34 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ec59443af135 6811267: Fix for 6809798 broke linux build Summary: Fix method's declaration. Reviewed-by: phh, twisti ! src/share/vm/opto/block.hpp Changeset: 98cb887364d3 Author: twisti Date: 2009-02-27 13:27 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/98cb887364d3 6810672: Comment typos Summary: I have collected some typos I have found while looking at the code. Reviewed-by: kvn, never ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/nativeInst_sparc.hpp ! src/cpu/sparc/vm/sparc.ad ! src/cpu/sparc/vm/templateTable_sparc.cpp ! src/cpu/x86/vm/c1_LIRGenerator_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os/linux/launcher/java.c ! src/os/linux/launcher/java_md.h ! src/os/linux/vm/perfMemory_linux.cpp ! src/os/solaris/launcher/java.c ! src/os/solaris/launcher/java_md.h ! src/os/solaris/vm/perfMemory_solaris.cpp ! src/os/windows/vm/perfMemory_windows.cpp ! src/os_cpu/solaris_sparc/vm/os_solaris_sparc.cpp ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/tools/MakeDeps/Database.java ! src/share/vm/adlc/Doc/Syntax.doc ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/dict2.hpp ! src/share/vm/adlc/filebuff.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/formssel.hpp ! src/share/vm/adlc/output_h.cpp ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp ! src/share/vm/ci/ciTypeFlow.cpp ! src/share/vm/classfile/symbolTable.cpp ! src/share/vm/code/nmethod.cpp ! src/share/vm/code/nmethod.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsAdaptiveSizePolicy.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/cmsGCAdaptivePolicyCounters.hpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/parallelScavenge/cardTableExtension.cpp ! src/share/vm/gc_implementation/parallelScavenge/objectStartArray.hpp ! src/share/vm/gc_implementation/parallelScavenge/prefetchQueue.hpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/interpreter/abstractInterpreter.hpp ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/interpreter/bytecodeInterpreter.inline.hpp ! src/share/vm/interpreter/cppInterpreter.hpp ! src/share/vm/interpreter/cppInterpreterGenerator.hpp ! src/share/vm/interpreter/interpreter.hpp ! src/share/vm/interpreter/interpreterGenerator.hpp ! src/share/vm/interpreter/templateInterpreter.hpp ! src/share/vm/interpreter/templateInterpreterGenerator.hpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/libadt/dict.hpp ! src/share/vm/memory/filemap.cpp ! src/share/vm/memory/permGen.hpp ! src/share/vm/oops/generateOopMap.cpp ! src/share/vm/oops/generateOopMap.hpp ! src/share/vm/oops/instanceKlass.cpp ! src/share/vm/oops/klass.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/block.hpp ! src/share/vm/opto/buildOopMap.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/coalesce.cpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/connode.cpp ! src/share/vm/opto/divnode.cpp ! src/share/vm/opto/domgraph.cpp ! src/share/vm/opto/escape.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/ifnode.cpp ! src/share/vm/opto/library_call.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/locknode.cpp ! src/share/vm/opto/loopTransform.cpp ! src/share/vm/opto/loopUnswitch.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/loopnode.hpp ! src/share/vm/opto/loopopts.cpp ! src/share/vm/opto/machnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/node.cpp ! src/share/vm/opto/node.hpp ! src/share/vm/opto/output.cpp ! src/share/vm/opto/parse.hpp ! src/share/vm/opto/parse1.cpp ! src/share/vm/opto/parse2.cpp ! src/share/vm/opto/phase.cpp ! src/share/vm/opto/phaseX.cpp ! src/share/vm/opto/postaloc.cpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/runtime.cpp ! src/share/vm/opto/split_if.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/superword.hpp ! src/share/vm/opto/type.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/extendedPC.hpp ! src/share/vm/runtime/fprofiler.cpp ! src/share/vm/runtime/frame.cpp ! src/share/vm/runtime/frame.inline.hpp ! src/share/vm/runtime/mutex.hpp ! src/share/vm/runtime/orderAccess.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/signature.hpp ! src/share/vm/runtime/threadCritical.hpp ! src/share/vm/utilities/globalDefinitions.hpp Changeset: 19962e74284f Author: never Date: 2009-03-01 20:49 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/19962e74284f 6811384: MacroAssembler::serialize_memory may touch next page on amd64 Reviewed-by: kvn, phh, twisti ! src/cpu/x86/vm/assembler_x86.cpp Changeset: d8c7fa77a6dc Author: kvn Date: 2009-03-03 10:34 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/d8c7fa77a6dc Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 0386097d43d8 Author: dcubed Date: 2009-03-02 13:57 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0386097d43d8 6700114: 3/4 Assertion (_thread->get_interp_only_mode() == 1,"leaving interp only when mode not one") Summary: Don't create JvmtiThreadState for an exiting JavaThread. Reviewed-by: coleenp, swamyv ! src/share/vm/prims/jvmtiThreadState.hpp Changeset: ea20d7ce26b0 Author: dcubed Date: 2009-03-02 14:00 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ea20d7ce26b0 6800721: 3/4 JavaThread::jvmti_thread_state() and JvmtiThreadState::state_for() robustness Summary: Check for NULL return values from jvmti_thread_state() and state_for() and return a JVM TI error code as appropriate. Reviewed-by: coleenp, swamyv ! src/share/vm/prims/jvmtiEnv.cpp ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEventController.cpp ! src/share/vm/prims/jvmtiExport.cpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/prims/jvmtiThreadState.hpp ! src/share/vm/runtime/thread.hpp Changeset: 70998f2e05ef Author: dcubed Date: 2009-03-02 14:03 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/70998f2e05ef 6805864: 4/3 Problem with jvmti->redefineClasses: some methods don't get redefined Summary: Remove incorrect optimization in klassItable::adjust_method_entries(). Add RedefineClasses() tracing support for obsolete method entry. Reviewed-by: acorn, swamyv ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/sparc/vm/sharedRuntime_sparc.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/includeDB_core ! src/share/vm/oops/klassVtable.cpp ! src/share/vm/prims/jvmtiRedefineClassesTrace.hpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/runtime/sharedRuntime.hpp Changeset: 2f716c0acb64 Author: dcubed Date: 2009-03-02 14:05 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2f716c0acb64 6567360: 3/4 SIGBUS in jvmti RawMonitor magic check for unaligned bad monitor pointer Summary: Change JvmtiEnvBase::is_valid() and JvmtiRawMonitor::is_valid() to fetch the _magic fields via Bytes::get_native_u[248](). Reviewed-by: coleenp, swamyv ! src/share/vm/prims/jvmtiEnvBase.cpp ! src/share/vm/prims/jvmtiEnvBase.hpp ! src/share/vm/prims/jvmtiImpl.cpp ! src/share/vm/prims/jvmtiImpl.hpp Changeset: afa80fa86d22 Author: dcubed Date: 2009-03-02 14:43 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/afa80fa86d22 Merge ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/includeDB_core ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/sharedRuntime.cpp Changeset: 5caef2219893 Author: dcubed Date: 2009-03-02 16:56 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/5caef2219893 Merge ! src/share/vm/includeDB_core Changeset: 3db67f76d308 Author: acorn Date: 2009-03-05 22:07 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/3db67f76d308 Merge ! src/cpu/sparc/vm/interp_masm_sparc.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/share/vm/includeDB_core ! src/share/vm/prims/jvmtiRedefineClasses.cpp Changeset: c6c601a0f2d6 Author: ysr Date: 2009-03-02 16:37 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/c6c601a0f2d6 6797870: Add -XX:+{HeapDump,PrintClassHistogram}{Before,After}FullGC Summary: Call newly created CollectedHeap::dump_{pre,post}_full_gc before and after every stop-world full collection cycle on GenCollectedHeap and ParallelScavengeHeap. (Support for G1CollectedHeap forthcoming under CR 6810861.) Small modifications to existing heap dumping and class histogram implementation, especially to allow multiple on-the-fly histos/dumps by the VM thread during a single safepoint. Reviewed-by: jmasa, alanb, mchung ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.cpp ! src/share/vm/gc_implementation/shared/vmGCOperations.hpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_gc ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/memory/heapInspection.hpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/services/attachListener.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/services/heapDumper.hpp Changeset: 4f360ec815ba Author: iveresov Date: 2009-03-06 13:50 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/4f360ec815ba 6720309: G1: don't synchronously update RSet during evacuation pauses 6720334: G1: don't update RSets of collection set regions during an evacuation pause Summary: Introduced a deferred update mechanism for delaying the rset updates during the collection pause Reviewed-by: apetrusenko, tonyp ! src/share/vm/gc_implementation/g1/concurrentG1RefineThread.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.cpp ! src/share/vm/gc_implementation/g1/dirtyCardQueue.hpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.cpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp Changeset: 0db4adb6e914 Author: tonyp Date: 2009-03-07 11:07 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/0db4adb6e914 6810698: G1: two small bugs in the sparse remembered sets Summary: The _expanded flag of the sparse RSets is not reset and this can leave a RSet in an inconsistent state if it is expanded more than once. Also, we should be iterating over the _cur, instead of the _next, sparse table Reviewed-by: apetrusenko, iveresov ! src/share/vm/gc_implementation/g1/sparsePRT.cpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp Changeset: ae1579717a57 Author: tonyp Date: 2009-03-07 11:07 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/ae1579717a57 6812428: G1: Error: assert(ret || obj_in_cs(obj),"sanity") Summary: The length of the fast cset test vector is decided at the beginning of a GC, but more regions can be added during the GC. The simple fix is to set the length of the fast cset test vector to the max. Reviewed-by: iveresov ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: 7ea5ca260b28 Author: tonyp Date: 2009-03-07 11:07 -0500 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7ea5ca260b28 6814467: G1: small fixes related to concurrent marking verboseness Summary: A few small fixes to remove some inconsistencies in the concurrent mark-related verbose GC output. Reviewed-by: jmasa ! src/share/vm/gc_implementation/g1/concurrentMark.cpp ! src/share/vm/gc_implementation/g1/concurrentMarkThread.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp Changeset: bcedf688d882 Author: tonyp Date: 2009-03-09 11:32 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/bcedf688d882 Merge ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/runtime/os.cpp Changeset: 19f25e603e7b Author: kvn Date: 2009-03-03 18:25 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/19f25e603e7b 6812721: Block's frequency should not be NaN Summary: Set MIN_BLOCK_FREQUENCY block's frequency when calculated block's frequency is NaN Reviewed-by: never ! src/share/vm/opto/gcm.cpp Changeset: 56aae7be60d4 Author: jrose Date: 2009-03-04 09:58 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/56aae7be60d4 6812678: macro assembler needs delayed binding of a few constants (for 6655638) Summary: minor assembler enhancements preparing for method handles Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateInterpreter_x86_64.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/asm/assembler.cpp ! src/share/vm/asm/assembler.hpp Changeset: 9adddb8c0fc8 Author: jrose Date: 2009-03-06 21:36 -0800 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/9adddb8c0fc8 6812831: factor duplicated assembly code for megamorphic invokeinterface (for 6655638) Summary: Code in vtableStubs and templateTable moved into MacroAssembler. Reviewed-by: kvn ! src/cpu/sparc/vm/assembler_sparc.cpp ! src/cpu/sparc/vm/assembler_sparc.hpp ! src/cpu/sparc/vm/assembler_sparc.inline.hpp ! src/cpu/sparc/vm/vtableStubs_sparc.cpp ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/templateTable_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_64.cpp ! src/cpu/x86/vm/vtableStubs_x86_32.cpp ! src/cpu/x86/vm/vtableStubs_x86_64.cpp Changeset: 337400e7a5dd Author: twisti Date: 2009-03-09 03:17 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/337400e7a5dd 6797305: Add LoadUB and LoadUI opcode class Summary: Add a LoadUB (unsigned byte) and LoadUI (unsigned int) opcode class so we have these load optimizations in the first place and do not need to handle them in the matcher. Reviewed-by: never, kvn ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/assembler_x86.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/forms.hpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/adlc/output_c.cpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/mulnode.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp + test/compiler/6797305/Test6797305.java Changeset: 2f2f54ed12ce Author: kvn Date: 2009-03-10 08:52 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2f2f54ed12ce Merge ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp Changeset: 87fa6e083d82 Author: apetrusenko Date: 2009-03-10 00:47 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/87fa6e083d82 6760309: G1: update remembered sets during Full GCs Reviewed-by: iveresov, tonyp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.inline.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp Changeset: fcf566137dbf Author: tonyp Date: 2009-03-12 11:34 -0400 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/fcf566137dbf Merge Changeset: 7bb995fbd3c0 Author: trims Date: 2009-03-12 18:16 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/7bb995fbd3c0 Merge ! make/linux/makefiles/adlc.make ! make/solaris/makefiles/adlc.make ! src/cpu/sparc/vm/sparc.ad ! src/cpu/x86/vm/assembler_x86.cpp ! src/cpu/x86/vm/c1_LIRAssembler_x86.cpp ! src/cpu/x86/vm/cppInterpreter_x86.cpp ! src/cpu/x86/vm/interp_masm_x86_32.cpp ! src/cpu/x86/vm/interp_masm_x86_64.cpp ! src/cpu/x86/vm/sharedRuntime_x86_32.cpp ! src/cpu/x86/vm/sharedRuntime_x86_64.cpp ! src/cpu/x86/vm/templateInterpreter_x86_32.cpp ! src/cpu/x86/vm/templateTable_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.cpp - src/cpu/x86/vm/vm_version_x86_32.hpp - src/cpu/x86/vm/vm_version_x86_64.cpp - src/cpu/x86/vm/vm_version_x86_64.hpp ! src/cpu/x86/vm/x86_32.ad ! src/cpu/x86/vm/x86_64.ad ! src/os_cpu/solaris_x86/vm/os_solaris_x86.cpp ! src/share/vm/adlc/adlparse.cpp ! src/share/vm/adlc/archDesc.cpp ! src/share/vm/adlc/dfa.cpp ! src/share/vm/adlc/dict2.cpp ! src/share/vm/adlc/filebuff.hpp ! src/share/vm/adlc/forms.cpp ! src/share/vm/adlc/formssel.cpp ! src/share/vm/gc_implementation/concurrentMarkSweep/concurrentMarkSweepGeneration.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.cpp ! src/share/vm/gc_implementation/g1/g1CollectedHeap.hpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.cpp ! src/share/vm/gc_implementation/g1/g1CollectorPolicy.hpp ! src/share/vm/gc_implementation/g1/g1RemSet.cpp ! src/share/vm/gc_implementation/g1/g1RemSet.hpp ! src/share/vm/gc_implementation/g1/g1_globals.hpp ! src/share/vm/gc_implementation/g1/heapRegion.hpp ! src/share/vm/gc_implementation/g1/ptrQueue.hpp ! src/share/vm/gc_implementation/g1/sparsePRT.hpp ! src/share/vm/gc_implementation/parallelScavenge/psMarkSweep.cpp ! src/share/vm/gc_implementation/parallelScavenge/psParallelCompact.cpp ! src/share/vm/gc_implementation/shared/mutableNUMASpace.cpp ! src/share/vm/gc_interface/collectedHeap.cpp ! src/share/vm/gc_interface/collectedHeap.hpp ! src/share/vm/includeDB_core ! src/share/vm/includeDB_gc ! src/share/vm/interpreter/bytecodeInterpreter.cpp ! src/share/vm/libadt/dict.cpp ! src/share/vm/memory/cardTableModRefBS.cpp ! src/share/vm/memory/cardTableModRefBS.hpp ! src/share/vm/memory/genCollectedHeap.cpp ! src/share/vm/memory/heapInspection.cpp ! src/share/vm/oops/klass.hpp ! src/share/vm/oops/methodOop.hpp ! src/share/vm/opto/block.cpp ! src/share/vm/opto/cfgnode.cpp ! src/share/vm/opto/chaitin.cpp ! src/share/vm/opto/chaitin.hpp ! src/share/vm/opto/classes.hpp ! src/share/vm/opto/compile.cpp ! src/share/vm/opto/gcm.cpp ! src/share/vm/opto/graphKit.cpp ! src/share/vm/opto/ifg.cpp ! src/share/vm/opto/live.cpp ! src/share/vm/opto/loopnode.cpp ! src/share/vm/opto/macro.cpp ! src/share/vm/opto/matcher.cpp ! src/share/vm/opto/memnode.cpp ! src/share/vm/opto/memnode.hpp ! src/share/vm/opto/reg_split.cpp ! src/share/vm/opto/superword.cpp ! src/share/vm/opto/type.cpp ! src/share/vm/opto/type.hpp ! src/share/vm/prims/jvmtiRedefineClasses.cpp ! src/share/vm/runtime/globals.hpp ! src/share/vm/runtime/os.cpp ! src/share/vm/runtime/safepoint.cpp ! src/share/vm/runtime/sharedRuntime.cpp ! src/share/vm/services/heapDumper.cpp ! src/share/vm/utilities/vmError.cpp ! src/share/vm/utilities/vmError.hpp Changeset: 2581d90c6c9b Author: trims Date: 2009-03-12 18:17 -0700 URL: http://hg.openjdk.java.net/jdk7/build/hotspot/rev/2581d90c6c9b 6816970: Bump HS15 build number to 03 Summary: Update the HS15 Build number to 03 Reviewed-by: jcoomes ! make/hotspot_version From Kelly.Ohair at Sun.COM Wed Mar 18 22:37:24 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Wed, 18 Mar 2009 15:37:24 -0700 Subject: Windows 64bit SDK changes (VS2008) In-Reply-To: <49BC5EE2.3060808@sun.com> References: <49BC5EE2.3060808@sun.com> Message-ID: <49C177A4.1040302@sun.com> FYI... (Windows only) The changes to allow for using the latest Windows 64bit SDK are starting to show up, but I wanted to caution people that until all the repositories get the necessary changesets, full JDK builds will likely not build or work with this newer SDK. The sanity warning messages about you not using the right compiler or OS on Windows should probably be ignored until our Release Engineering, Testing, and Performance teams have agreed it looks ok and taken down the caution flag, so to speak. Once that happens, Windows developers will have some upgrading to consider. Using the older SDKs and compilers will continue to work. The jdk7/corba and jdk7/jdk changesets are in: http://hg.openjdk.java.net/jdk7/jdk7-gate/jdk/rev/711a9fb838d1 http://hg.openjdk.java.net/jdk7/jdk7/corba/rev/9c0cc0d0eca2 The hotspot changeset should be available soon. -kto Kelly O'Hair wrote: > > I am currently working on the Windows 2003 64bit Platform SDK update. > Thought Windows people might like to see a webrev. ;^) > > http://cr.openjdk.java.net/~ohair/win64-jdk/webrev/ > > (Had to try out Tim's cr.openjdk site. ;^) > README-builds.html changes are yet to come. > > --- > > For those of you unfamiliar with Windows 64bit building, the 64bit > version of the Visual Studio compilers are provided in the Windows SDK. > This new 64bit compiler is basically Visual Studio 2008. > The SDK is available at: > > http://www.microsoft.com/downloads/details.aspx?FamilyId=E6E1C3DF-A74F-4207-8586-711EBE331CDC&displaylang=en > > > -kto > From Tim.Bell at Sun.COM Thu Mar 19 04:48:30 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Wed, 18 Mar 2009 21:48:30 -0700 Subject: Please review: 6695776 in OpenJDK7 (corba jscheme jar files in repository could be built from source) Message-ID: <49C1CE9E.1030003@sun.com> Hi Folks This is part of a project to move fixes that are already in OpenJDK6 forward to OpenJDK7. The fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6695776 will remove some binary artifacts from the source tree and instead build them from sources when required. Here are the code changes: http://cr.openjdk.java.net/~tbell/6695776/webrev.00/ These corba changes are building OK on our internal JPRT build system. I confirmed by inspecting the build logs that the expected sources (com.sun.tools.corba.se.logutil.MC) are built at the correct time. Thanks in advance- Tim Bell From Jonathan.Gibbons at Sun.COM Thu Mar 19 18:43:20 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Thu, 19 Mar 2009 11:43:20 -0700 Subject: Problems with building jmx for OpenJDK. Message-ID: <49C29248.4050100@sun.com> I'm trying to build the repositories in the open "tl" forest. (i.e. no closed repositories.) The build runs almost all the way to the end, but fails to build ct.sym because some class files are missing. > error: com.sun.jmx.snmp.SnmpValue: class file for > com.sun.jmx.snmp.SnmpValue not found > error: class file for com.sun.jmx.snmp.SnmpValue not found It's true, a lot of files in jdk/src/share/classes/com/sun/jmx/snmp did not get compiled. Looking further back in the make log, the only references to "jmx/snmp" are when importing some binary plugs. In addition, it looks like SUBDIRS is not set when processing the jmx directory, so it never gets into the snmp directory as it should. Looking at the jmk Makefile, there's this little bit of logic: > # When building the openjdk, build snmp only if importing binary plugs, > ifdef OPENJDK > ifeq ($(IMPORT_BINARY_PLUGS),true) > SUBDIRS = snmp > endif > else > SUBDIRS = snmp > endif When I invoke make, I'm not setting OPENJDK or IMPORT_BINARY_PLUGS, but I don't have closed directories (which should implicitly set OPENJDK, right?) and I have specified ALT_BINARY_PLUGS_PATH which I assume causes IMPORT_BINARY_PLUGS to be set. I am certainly seeing binary plugs for some snmp files being imported. So, I would think that together this would be enough to ensure SUBDIRS is set to snmp, right? Is anyone aware of recent changes that would cause this problematic behavior? -- Jon -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu_andrew at member.fsf.org Thu Mar 19 19:18:34 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Thu, 19 Mar 2009 19:18:34 +0000 Subject: Please review: 6695776 in OpenJDK7 (corba jscheme jar files in repository could be built from source) In-Reply-To: <49C1CE9E.1030003@sun.com> References: <49C1CE9E.1030003@sun.com> Message-ID: <17c6771e0903191218x34868f08sdf0f307d755b3477@mail.gmail.com> 2009/3/19 Tim Bell : > Hi Folks > > This is part of a project to move fixes that are already in OpenJDK6 forward > to OpenJDK7. > > The fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6695776 will > remove some binary artifacts from the source tree and instead build them > from sources when required. > > Here are the code changes: > > ?http://cr.openjdk.java.net/~tbell/6695776/webrev.00/ > > These corba changes are building OK on our internal JPRT build system. I > confirmed by inspecting the build logs that the expected sources > (com.sun.tools.corba.se.logutil.MC) are built at the correct time. > > Thanks in advance- > > Tim Bell > Funnily enough, being the original author of this one, I was just about to file a bug for it in the new OpenJDK bug database when I saw this mail. The patch went into OpenJDK6 a while ago but never reached OpenJDK7. As a result, we've been applying it to IcedTea7's builds of JDK7 all this time, so I can confirm that it does still apply fine :) It would be great to see it in JDK7 proper. Same goes for the IMPORT_BINARY_PLUGS stuff while you're at it... ;) Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Joe.Darcy at Sun.COM Mon Mar 23 23:23:25 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Mon, 23 Mar 2009 16:23:25 -0700 Subject: Please review: 6695776 in OpenJDK7 (corba jscheme jar files in repository could be built from source) In-Reply-To: <49C1CE9E.1030003@sun.com> References: <49C1CE9E.1030003@sun.com> Message-ID: <49C819ED.6020900@sun.com> Looks fine to me. -Joe Tim Bell wrote: > Hi Folks > > This is part of a project to move fixes that are already in OpenJDK6 > forward to OpenJDK7. > > The fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6695776 > will remove some binary artifacts from the source tree and instead build > them from sources when required. > > Here are the code changes: > > http://cr.openjdk.java.net/~tbell/6695776/webrev.00/ > > These corba changes are building OK on our internal JPRT build system. I > confirmed by inspecting the build logs that the expected sources > (com.sun.tools.corba.se.logutil.MC) are built at the correct time. > > Thanks in advance- > > Tim Bell From neale at sinenomine.net Thu Mar 26 13:38:48 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Thu, 26 Mar 2009 09:38:48 -0400 Subject: Error building openJDK7 Message-ID: I?m trying to build the JDK for the first time. I grabbed the sources from the mercurial repository and followed the FAQ to perform the build. It builds a heap of stuff before it dies with the following: error: com.sun.jmx.snmp.SnmpValue: class file for com.sun.jmx.snmp.SnmpValue not found error: class file for com.sun.jmx.snmp.SnmpValue not found The source code for the above class is there but it doesn?t appear to be being compiled. Is this a known problem or a newbie mistake easily fixed? Neale -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bell at Sun.COM Thu Mar 26 13:58:31 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Thu, 26 Mar 2009 06:58:31 -0700 Subject: Error building openJDK7 In-Reply-To: References: Message-ID: <49CB8A07.7050101@sun.com> Hi Neale: > I?m trying to build the JDK for the first time. I grabbed the sources > from the mercurial repository and followed the FAQ to perform the build. > It builds a heap of stuff before it dies with the following: > > error: com.sun.jmx.snmp.SnmpValue: class file for > com.sun.jmx.snmp.SnmpValue not found > error: class file for com.sun.jmx.snmp.SnmpValue not found > > The source code for the above class is there but it doesn?t appear to be > being compiled. Is this a known problem or a newbie mistake easily fixed? This is bug-id 6819847 "build is broken for OpenJDK with plugs" http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6819847 the work around is to define IMPORT_BINARY_PLUGS=true This was an unintended consequence of the fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6661448 Hope this helps- Tim Bell From aph at redhat.com Thu Mar 26 16:49:09 2009 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Mar 2009 16:49:09 +0000 Subject: Bug 100028 - Debug information is incomplete or missing In-Reply-To: <49C0D1E7.6030707@redhat.com> References: <49BFB13B.2000602@redhat.com> <49C019BF.6010804@sun.com> <49C0D1E7.6030707@redhat.com> Message-ID: <49CBB205.8040109@redhat.com> This is my first stab at moving patches from IcedTea into OpenJDK. Rather than creating a single overriding variable that enables debuginfo everywhere I've used two, one for native files and one for class files. Setting DEBUG_CLASSFILES=true in the toplevel forces all classes to be built with full debuginfo, and DEBUG_BINARIES does the same for native binaries. These make variables are entirely independent of the debug and optimization setting. This allows GNU/Linux distributions to build OpenJDK in a form fit for distribution without patching makefiles or Ant buildfiles. It also means that the Ant variables javac.debug and javac.debuginfo are respected everwhere in the build. https://bugs.openjdk.java.net/show_bug.cgi?id=100028 Is this OK? Andrew. -------------- next part -------------- --- openjdk/langtools/src/share/opensource/javac/build.xml~ 2008-11-25 09:17:57.000000000 +0000 +++ openjdk/langtools/src/share/opensource/javac/build.xml 2009-03-25 10:55:19.000000000 +0000 @@ -74,7 +74,7 @@ --- openjdk/langtools/make/Makefile~ 2008-11-25 09:17:52.000000000 +0000 +++ openjdk/langtools/make/Makefile 2009-03-25 10:52:39.000000000 +0000 @@ -101,6 +101,11 @@ endif endif +ifeq ($(DEBUG_CLASSFILES), true) + ANT_OPTIONS += -Djavac.debug=true + ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars +endif + # Note: jdk/make/common/Defs.gmk uses LANGUAGE_VERSION (-source NN) # and the somewhat misnamed CLASS_VERSION (-target NN) ifdef TARGET_CLASS_VERSION --- openjdk/jaxws/make/Makefile~ 2008-11-25 09:16:43.000000000 +0000 +++ openjdk/jaxws/make/Makefile 2009-03-25 10:52:23.000000000 +0000 @@ -69,6 +69,11 @@ endif endif +ifeq ($(DEBUG_CLASSFILES), true) + ANT_OPTIONS += -Djavac.debug=true + ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars +endif + # Note: jdk/make/common/Defs.gmk uses LANGUAGE_VERSION (-source NN) # and the somewhat misnamed CLASS_VERSION (-target NN) ifdef TARGET_CLASS_VERSION --- openjdk/jaxws/make/build.xml~ 2008-11-25 09:16:43.000000000 +0000 +++ openjdk/jaxws/make/build.xml 2009-03-25 10:55:39.000000000 +0000 @@ -107,6 +107,7 @@ destdir="${build.classes.dir}" memoryInitialSize="${javac.memoryInitialSize}" memoryMaximumSize="${javac.memoryMaximumSize}" + debug="${javac.debug}" target="${javac.target}" excludes="com/sun/tools/internal/txw2/**"> --- openjdk/jaxp/make/Makefile~ 2008-11-25 09:15:03.000000000 +0000 +++ openjdk/jaxp/make/Makefile 2009-03-25 10:52:03.000000000 +0000 @@ -69,6 +69,11 @@ endif endif +ifeq ($(DEBUG_CLASSFILES), true) + ANT_OPTIONS += -Djavac.debug=true + ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars +endif + # Note: jdk/make/common/Defs.gmk uses LANGUAGE_VERSION (-source NN) # and the somewhat misnamed CLASS_VERSION (-target NN) ifdef TARGET_CLASS_VERSION --- openjdk/jaxp/make/build.xml~ 2008-11-25 09:15:03.000000000 +0000 +++ openjdk/jaxp/make/build.xml 2009-03-25 10:49:13.000000000 +0000 @@ -85,6 +85,7 @@ destdir="${build.classes.dir}" memoryInitialSize="${javac.memoryInitialSize}" memoryMaximumSize="${javac.memoryMaximumSize}" + debug="${javac.debug}" target="${javac.target}"> --- openjdk/jdk/make/common/Defs-linux.gmk~ 2008-11-25 09:01:11.000000000 +0000 +++ openjdk/jdk/make/common/Defs-linux.gmk 2009-03-26 15:41:15.000000000 +0000 @@ -163,6 +163,12 @@ endif endif +# DEBUG_BINARIES overrides everything +ifeq ($(DEBUG_BINARIES), true) + CFLAGS_REQUIRED += -g + DEBUG_FLAG = -g +endif + CFLAGS_OPT = $(POPT) CFLAGS_DBG = $(DEBUG_FLAG) CFLAGS_COMMON += $(CFLAGS_REQUIRED) @@ -235,8 +241,11 @@ # ifeq ($(VARIANT), OPT) ifneq ($(NO_STRIP), true) - # Debug 'strip -g' leaves local function Elf symbols (better stack traces) - POST_STRIP_PROCESS = $(STRIP) -g + ifneq ($(DEBUG_BINARIES), true) + # Debug 'strip -g' leaves local function Elf symbols (better stack + # traces) + POST_STRIP_PROCESS = $(STRIP) -g + endif endif endif --- openjdk/jdk/make/sun/awt/mawt.gmk~ 2008-11-25 09:01:23.000000000 +0000 +++ openjdk/jdk/make/sun/awt/mawt.gmk 2009-03-26 15:44:28.000000000 +0000 @@ -129,7 +129,9 @@ # -#CFLAGS += -g +ifeq ($(DEBUG_BINARIES), true) + CFLAGS += -g +endif ifeq ($(HEADLESS),true) CFLAGS += -DHEADLESS=$(HEADLESS) CPPFLAGS += -DHEADLESS=$(HEADLESS) --- openjdk/control/make/make/sanity-rules.gmk~ 2008-11-25 08:30:07.000000000 +0000 +++ openjdk/control/make/make/sanity-rules.gmk 2009-03-26 16:47:03.000000000 +0000 @@ -360,6 +360,8 @@ ifeq ($(SPONSORS_SRC_AVAILABLE), true) @$(ECHO) " BUILD_SPONSORS = $(BUILD_SPONSORS) " >> $(MESSAGE_FILE) endif + @$(ECHO) " DEBUG_CLASSFILES = $(DEBUG_CLASSFILES) " >> $(MESSAGE_FILE) + @$(ECHO) " DEBUG_BINARIES = $(DEBUG_BINARIES) " >> $(MESSAGE_FILE) @$(ECHO) "" >> $(MESSAGE_FILE) .PHONY: sanity settings pre-sanity insane \ From kelly.ohair at sun.com Fri Mar 27 00:51:16 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 27 Mar 2009 00:51:16 +0000 Subject: hg: jdk7/build/jaxp: 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Message-ID: <20090327005118.C8C80EB24@hg.openjdk.java.net> Changeset: 996284fd4afe Author: ohair Date: 2009-03-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxp/rev/996284fd4afe 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell - make/jprt.config From kelly.ohair at sun.com Fri Mar 27 01:00:22 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 27 Mar 2009 01:00:22 +0000 Subject: hg: jdk7/build/langtools: 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Message-ID: <20090327010025.D80A8EB36@hg.openjdk.java.net> Changeset: 39c674c60a36 Author: ohair Date: 2009-03-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/build/langtools/rev/39c674c60a36 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell - make/jprt.config From kelly.ohair at sun.com Fri Mar 27 01:08:40 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 27 Mar 2009 01:08:40 +0000 Subject: hg: jdk7/build/jaxws: 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Message-ID: <20090327010843.0C045EB3F@hg.openjdk.java.net> Changeset: 0814199b8ee7 Author: ohair Date: 2009-03-26 16:48 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jaxws/rev/0814199b8ee7 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell - make/jprt.config From kelly.ohair at sun.com Fri Mar 27 02:09:13 2009 From: kelly.ohair at sun.com (kelly.ohair at sun.com) Date: Fri, 27 Mar 2009 02:09:13 +0000 Subject: hg: jdk7/build/jdk: 6822374: Windows: detect X64 when PROCESSOR_IDENTIFIER contains EM64T or Intel64; ... Message-ID: <20090327020944.633ACEB51@hg.openjdk.java.net> Changeset: 90873391a0e0 Author: ohair Date: 2009-03-26 16:52 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/90873391a0e0 6822374: Windows: detect X64 when PROCESSOR_IDENTIFIER contains EM64T or Intel64 6822913: Consolidate make/jprt.config files, let JPRT manage this file make it optional in repos Reviewed-by: tbell ! make/common/shared/Platform.gmk ! make/jdk_generic_profile.sh - make/jprt.config From ted at tedneward.com Fri Mar 27 10:17:13 2009 From: ted at tedneward.com (Ted Neward) Date: Fri, 27 Mar 2009 03:17:13 -0700 Subject: Grr.... Message-ID: <02e301c9aec5$3b0b81d0$b1228570$@com> I'm trying to reset my OpenJDK build environment back to a working state (after the Innovator's Challenge project more or less hacked it to death), and I'm running into some problems that I don't *think* are all that obvious to debug, but it could be my mental state at 3AM, after wrestling with this for close to 6 hours and feeling like I'm shaving a VERY big yak. Basically, freetypecheck fails to build. AGAIN. (This thing is my nemeis.) Here's what I'm getting. Somebody please tell me how to figure out where the ":convert integer expression expected" messages are coming from, or why I'm getting them, before I go insane. (Then you can tell me why cl.exe can't find "stdio.h" when it's on the INCLUDE environment variable path..) Oh and while you're at THAT, somebody tell me how to build a DLL version of FreeType. (I swear, I hate FreeType.) How in the heck do you debug makefiles, Kelly? Seriously? $ make sanity ( cd ./jdk/make && \ make sanity HOTSPOT_IMPORT_CHECK=false JDK_TOPDIR=c:/Prg/OpenJDK/openj dk/jdk JDK_MAKE_SHARED_DIR=c:/Prg/OpenJDK/openjdk/jdk/make/common/shared EXTERNA LSANITYCONTROL=true TARGET_CLASS_VERSION=5 MILESTONE=internal BUILD_NUMBER=b00 J DK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-ted_2009_03_27_03_08-b00 PREVIOU S_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 JDK_MAJOR_VERSION=1 JDK _MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 PREVIOUS_MINOR_VER SION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 ANT_HOM E="c:/Prg/apache-ant-1.7.0" ALT_OUTPUTDIR=c:/Prg/OpenJDK/openjdk/build/windows-i 586 ALT_LANGTOOLS_DIST=c:/Prg/OpenJDK/openjdk/build/windows-i586/langtools/dist ALT_CORBA_DIST=c:/Prg/OpenJDK/openjdk/build/windows-i586/corba/dist ALT_JAXP_DIS T=c:/Prg/OpenJDK/openjdk/build/windows-i586/jaxp/dist ALT_JAXWS_DIST=c:/Prg/Open JDK/openjdk/build/windows-i586/jaxws/dist ALT_HOTSPOT_IMPORT_PATH=c:/Prg/OpenJDK /openjdk/build/windows-i586/hotspot/import BUILD_HOTSPOT=true ; ) /bin/sh: line 0: [: cygpath:: integer expression expected /bin/sh: line 0: [: cygpath:: integer expression expected /bin/sh: line 0: [: cant -lt 6 ]; then echo older; elif [ cant: integer expressi on expected /bin/sh: line 0: [: convert: integer expression expected /bin/sh: line 0: [: convert: integer expression expected make[1]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/jdk/make' make[2]: *** [c:/Prg/OpenJDK/openjdk/build/windows-i586/btbins/freetype_versionc heck.exe] Error 2 make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/jdk/make' Build Machine Information: build machine = XPJava Build Directory Structure: CWD = /cygdrive/c/Prg/OpenJDK/openjdk TOPDIR = . CONTROL_TOPDIR = . LANGTOOLS_TOPDIR = ./langtools JAXP_TOPDIR = ./jaxp JAXWS_TOPDIR = ./jaxws CORBA_TOPDIR = ./corba HOTSPOT_TOPDIR = ./hotspot JDK_TOPDIR = ./jdk Build Directives: BUILD_LANGTOOLS = true BUILD_JAXP = true BUILD_JAXWS = true BUILD_CORBA = true BUILD_HOTSPOT = true BUILD_JDK = true Hotspot Settings: HOTSPOT_BUILD_JOBS = HOTSPOT_OUTPUTDIR = c:/Prg/OpenJDK/openjdk/build/windows-i586/hotspot/ou tputdir HOTSPOT_EXPORT_PATH = c:/Prg/OpenJDK/openjdk/build/windows-i586/hotspot/im port Bootstrap Settings: BOOTDIR = C:/Prg/jdk1.6.0 ALT_BOOTDIR = C:/Prg/jdk1.6.0 BOOT_VER = 1.6.0 [requires at least 1.5] OUTPUTDIR = c:/Prg/OpenJDK/openjdk/build/windows-i586 ALT_OUTPUTDIR = c:/Prg/OpenJDK/openjdk/build/windows-i586 ABS_OUTPUTDIR = c:/Prg/OpenJDK/openjdk/build/windows-i586 Build Tool Settings: SLASH_JAVA = J: ALT_SLASH_JAVA = VARIANT = OPT JDK_DEVTOOLS_DIR = J:/devtools ALT_JDK_DEVTOOLS_DIR = ANT_HOME = c:/Prg/apache-ant-1.7.0 UNIXCOMMAND_PATH = /usr/bin/ ALT_UNIXCOMMAND_PATH = COMPILER_PATH = C:/Prg/MSVS9.0/Common7/Tools/../../Vc/Bin/ ALT_COMPILER_PATH = DEVTOOLS_PATH = /usr/bin/ ALT_DEVTOOLS_PATH = MSVCRT_DLL_PATH = C:/WINDOWS/system32 ALT_MSVCRT_DLL_PATH = MSVCRNN_DLL_PATH = C:/Prg/OpenJDK/deps/MSVCR ALT_MSVCRNN_DLL_PATH = C:/Prg/OpenJDK/deps/MSVCR MSDEVTOOLS_PATH = C:/Prg/MSVS9.0/VC/bin/ ALT_MSDEVTOOLS_PATH = C:/Prg/MSVS9.0/VC/bin COMPILER_NAME = Visual Studio 9 COMPILER_VERSION = VS2008 CC_VER = 15.00.21022.08 [requires at least 15.00.21022.08] ZIP_VER = 2.32 [requires at least 2.2] UNZIP_VER = 5.52 [requires at least 5.12] LINK_VER = 9.00.21022.08 [requires at least 9.00.21022.08] ANT_VER = cygpath: can't convert empty path Unable to locate tools.jar. Expect ed to find it in C:\Program Files\Java\jre61.7.0 [requires at least 1.6.3] TEMPDIR = c:/Prg/OpenJDK/openjdk/build/windows-i586/tmp Build Directives: OPENJDK = true USE_HOTSPOT_INTERPRETER_MODE = PEDANTIC = DEV_ONLY = NO_DOCS = NO_IMAGES = TOOLS_ONLY = INSANE = COMPILE_APPROACH = normal FASTDEBUG = COMPILER_WARNINGS_FATAL = false COMPILER_WARNING_LEVEL = 3 INCREMENTAL_BUILD = false CC_HIGHEST_OPT = CC_HIGHER_OPT = CC_LOWER_OPT = CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB -Fdc:/Prg/OpenJDK/openjdk/b uild/windows-i586/tmp/obj/.pdb -Fmc:/Prg/OpenJDK/openjdk/build/windows-i586/tmp/ obj/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB -Fdc:/Prg/OpenJDK/openjdk/b uild/windows-i586/tmp/obj/.pdb -Fmc:/Prg/OpenJDK/openjdk/build/windows-i586/tmp/ obj/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE BOOT_JAVA_CMD = C:/Prg/jdk1.6.0/bin/java -client -Xmx383m -Xms128m -XX:PermSi ze=32m -XX:MaxPermSize=160m BOOT_JAVAC_CMD = C:/Prg/jdk1.6.0/bin/javac -J-XX:ThreadStackSize=768 -J-clien t -J-Xmx383m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m -encoding asci i -XDignore.symbol.file=true BOOT_JAR_CMD = C:/Prg/jdk1.6.0/bin/jar BOOT_JARSIGNER_CMD = C:/Prg/jdk1.6.0/bin/jarsigner Build Platform Settings: USER = Ted PLATFORM = windows ARCH = i586 LIBARCH = i386 ARCH_FAMILY = i586 ARCH_DATA_MODEL = 32 ARCHPROP = x86 PROCESSOR_ARCHITECTURE = x86 PROCESSOR_IDENTIFIER = x86 Family 6 Model 15 Stepping 10, GenuineIntel USING_CYGWIN = true CYGWIN_VER = 5.1 [requires at least 4.0] CYGPATH_CMD = cygpath -a -s -m OS_VERSION = 5.1 [requires at least 5.1] OS_VARIANT_NAME = WindowsXP OS_VARIANT_VERSION = 5.1 TEMP_FREE_SPACE = 1827916 FREE_SPACE = 1827916 MB_OF_MEMORY = 511 GNU Make Settings: MAKE = make MAKE_VER = 3.81 [requires at least 3.78] MAKECMDGOALS = sanity MAKEFLAGS = w SHELL = /bin/sh Target Build Versions: JDK_VERSION = 1.7.0 MILESTONE = internal RELEASE = 1.7.0-internal FULL_VERSION = 1.7.0-internal-ted_2009_03_27_03_08-b00 BUILD_NUMBER = b00 External File/Binary Locations: USRJDKINSTANCES_PATH = C:/PROGRA~1/Java BUILD_JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries ALT_BUILD_JDK_IMPORT_PATH = JDK_IMPORT_PATH = C:/Prg/JDK16~1.0 ALT_JDK_IMPORT_PATH = C:/Prg/jdk1.6.0 LANGTOOLS_DIST = ALT_LANGTOOLS_DIST = c:/Prg/OpenJDK/openjdk/build/windows-i586/langtools/dis t CORBA_DIST = ALT_CORBA_DIST = c:/Prg/OpenJDK/openjdk/build/windows-i586/corba/dist JAXP_DIST = ALT_JAXP_DIST = c:/Prg/OpenJDK/openjdk/build/windows-i586/jaxp/dist JAXWS_DIST = ALT_JAXWS_DIST = c:/Prg/OpenJDK/openjdk/build/windows-i586/jaxws/dist HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR ALT_HOTSPOT_DOCS_IMPORT_PATH = HOTSPOT_IMPORT_PATH = c:/Prg/OpenJDK/openjdk/build/WINDOW~1/hotspot/import ALT_HOTSPOT_IMPORT_PATH = c:/Prg/OpenJDK/openjdk/build/windows-i586/hotspot/ import HOTSPOT_CLIENT_PATH = c:/Prg/OpenJDK/openjdk/build/WINDOW~1/hotspot/import/jre /bin/client ALT_HOTSPOT_CLIENT_PATH = HOTSPOT_SERVER_PATH = c:/Prg/OpenJDK/openjdk/build/WINDOW~1/hotspot/import/jre /bin/server ALT_HOTSPOT_SERVER_PATH = HOTSPOT_LIB_PATH = c:/Prg/OpenJDK/openjdk/build/WINDOW~1/hotspot/import/lib ALT_HOTSPOT_LIB_PATH = DXSDK_VER = 0x0900 DXSDK_PATH = C:/Prg/MSDIRE~1 ALT_DXSDK_PATH = C:/Prg/MSDirectXSDK-03-2008 DXSDK_INCLUDE_PATH = C:/Prg/MSDIRE~1/Include ALT_DXSDK_INCLUDE_PATH = DXSDK_LIB_PATH = C:/Prg/MSDIRE~1/Lib ALT_DXSDK_LIB_PATH = CACERTS_FILE = ./../src/share/lib/security/cacerts ALT_CACERTS_FILE = OpenJDK-specific settings: FREETYPE_HEADERS_PATH = C:/Prg/OpenJDK/deps/freetype-2.3.9/windows/freetype-i5 86/include/freetype2 ALT_FREETYPE_HEADERS_PATH = C:/Prg/OpenJDK/deps/freetype-2.3.9/windows/freet ype-i586/include/freetype2 FREETYPE_LIB_PATH = C:/Prg/OpenJDK/deps/freetype-igor/windows/freetype-i586/li b ALT_FREETYPE_LIB_PATH = C:/Prg/OpenJDK/deps/freetype-igor/windows/freetype-i 586/lib OPENJDK Import Binary Plug Settings: BINARY_PLUGS_JARFILE = /cygdrive/c/Prg/OpenJDK/openjdk-binary-plugs/jre/lib/rt -closed.jar ALT_BINARY_PLUGS_JARFILE = BINARY_PLUGS_PATH = /cygdrive/c/Prg/OpenJDK/openjdk-binary-plugs ALT_BINARY_PLUGS_PATH = /cygdrive/c/Prg/OpenJDK/openjdk-binary-plugs BUILD_BINARY_PLUGS_PATH = J:/re/jdk/1.7.0/promoted/latest/openjdk/binaryplugs ALT_BUILD_BINARY_PLUGS_PATH = PLUG_LIBRARY_NAMES = Previous JDK Settings: PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE ALT_PREVIOUS_RELEASE_PATH = PREVIOUS_JDK_VERSION = 1.6.0 ALT_PREVIOUS_JDK_VERSION = PREVIOUS_JDK_FILE = ALT_PREVIOUS_JDK_FILE = PREVIOUS_JRE_FILE = ALT_PREVIOUS_JRE_FILE = PREVIOUS_RELEASE_IMAGE = C:/Prg/jdk1.6.0 ALT_PREVIOUS_RELEASE_IMAGE = WARNING: This machine appears to only have 511Mb of physical memory, builds on this machine could be slow. ERROR: FreeType version 2.3.0 or higher is required. make[2]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/jdk/make/tools/fre etypecheck' freetypecheck.c freetypecheck.c(29) : fatal error C1083: Cannot open include file: 'stdio.h': No such file or directory make[2]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/jdk/make/tools/freet ypecheck' Failed to build freetypecheck. Exiting because of the above error(s). make: *** [post-sanity] Error 1 :/cygdrive/c/Prg/OpenJDK/openjdk $ Ted Neward | Principal Consultant, ThoughtWorks Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.thoughtworks.com | http://www.tedneward.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted at tedneward.com Fri Mar 27 12:24:37 2009 From: ted at tedneward.com (Ted Neward) Date: Fri, 27 Mar 2009 05:24:37 -0700 Subject: RC.exe location change? Message-ID: <02f301c9aed7$04e15e10$0ea41a30$@com> While building the OpenJDK (finally got past the FreeType issues, though I'm not entirely sure how or why, which bugs me), I've run across an error where the make files seem to assume that rc.exe lives in the compiler directory. and it doesn't-it's been moved to the Platform SDK. For example, the problem first shows up in corba/make/common/shared/Compiler-msvc.gmk: # # MSVC Compiler settings # ifeq ($(PLATFORM), windows) CC = $(COMPILER_PATH)cl CPP = $(COMPILER_PATH)cl CXX = $(COMPILER_PATH)cl CCC = $(COMPILER_PATH)cl LIBEXE = $(COMPILER_PATH)lib LINK = $(COMPILER_PATH)link # # Begin TKN mod # # RC = $(MSDEVTOOLS_PATH)rc RC = $(MSDEVTOOLS_PATH)/../MicrosoftSDKs/Windows/v6.1/Bin/rc # # End TKN mod # LINK32 = $(LINK) RSC = $(RC) Now I'm not sure if MSDEVTOOLS_PATH is supposed to point to the PlatformSDK bin, or the MSVS9.0/VC/bin (which is what other parts of the build system seem to assume), or what, but rc.exe pretty definitively isn't in the VC directory of VS 2008, from what I can tell. (I checked on another machine that had a "go ahead install everything" install experience, and it's not there, either.) Dunno if this is a bug, or what, but the Compiler-msvc file should probably be patched to read something like: ifeq ($(CC_MAJORVER), 15) # This should be: CC_VER=15.00.21022.08 LINK_VER=9.00.21022.08 REQUIRED_CC_VER = 15.00.21022.08 REQUIRED_LINK_VER = 9.00.21022.08 COMPILER_NAME=Visual Studio 9 COMPILER_VERSION=VS2008 #rebase and midl moved out of Visual Studio into the SDK: REBASE = $(MSDEVTOOLS_PATH)/rebase MTL = $(MSDEVTOOLS_PATH)/midl.exe RC = $(MSDEVTOOLS_PATH)/rc.exe RCS = $(RC) ifndef COMPILER_PATH COMPILER_PATH := $(error COMPILER_PATH cannot be empty here) endif endif . assuming MSDEVTOOLS_PATH is supposed to point to the PlatformSDK bin (and not MSVS9.0/VC/bin). Is that the breakdown between COMPILER_PATH and MSDEVTOOLS_PATH? The README implies that the latter is derived from the former, and it probably shouldn't be.. Ted Neward | Principal Consultant, ThoughtWorks Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.thoughtworks.com | http://www.tedneward.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From Kelly.Ohair at Sun.COM Fri Mar 27 16:40:36 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 27 Mar 2009 09:40:36 -0700 Subject: Grr.... In-Reply-To: <02e301c9aec5$3b0b81d0$b1228570$@com> References: <02e301c9aec5$3b0b81d0$b1228570$@com> Message-ID: <49CD0184.9060004@sun.com> Ted Neward wrote: > I?m trying to reset my OpenJDK build environment back to a working state > (after the Innovator?s Challenge project more or less hacked it to > death), and I?m running into some problems that I don?t **think** are > all that obvious to debug, but it could be my mental state at 3AM, after > wrestling with this for close to 6 hours and feeling like I?m shaving a > VERY big yak. > > > > Basically, freetypecheck fails to build. AGAIN. (This thing is my nemeis.) > freetypecheck has been a royal major pain in the you know what.... So you are not alone. > > > Here?s what I?m getting. Somebody please tell me how to figure out where > the ?:convert integer expression expected? messages are coming from, or > why I?m getting them, before I go insane. (Then you can tell me why > cl.exe can?t find ?stdio.h? when it?s on the INCLUDE environment > variable path?.) The problem is when the freetype include files are living with the cygwin stdio.h, which is not the one that cl.exe wants or likes. I ran into this when I tried to use the freetype in cygwin, so I finally gave up on using a cygwin freetype. > > > > Oh and while you?re at THAT, somebody tell me how to build a DLL version > of FreeType. I went down that path and pulled my hair out for a couple of hours. The instructions are missing and everything I found on the web didn't work. I finally copied the files in our shared nfs area that was obviously built by someone who knew what he was doing (unlike me). I'll try and dig up the copies I have and put them at: http://cr.openjdk.java.net/~ohair/windows-i586-freetype/ http://cr.openjdk.java.net/~ohair/windows-x64-freetype/ Let me know if you can access those files. You should be able to do something like: scp -r cr.openjdk.java.net:~ohair/windows-i586-freetype . I think... > > > > (I swear, I hate FreeType.) Me too. :^( Or maybe it's just the way we use it. :^( > > > > How in the heck do you debug makefiles, Kelly? Seriously? In this case, the Makefile is purposely being silent using the '@' prefix, which I never like to do on compile lines. But in this case I had to cd into the make/tools/freetypecheck directory and run the makefile there, after removing the '@' prefix on the compile line. These sanity checks that actually run the compiler are something I try to avoid, and freetype is particularly nasty. I plan on filing a couple bugs on this, one for the lack of instructions in the README-builds.html file for how to build it, and second on the sanity check needing to be torn down and re-implemented. Sorry you ran into this problem. -kto > > > > $ make sanity > > ( cd ./jdk/make && \ > > make sanity HOTSPOT_IMPORT_CHECK=false > JDK_TOPDIR=c:/Prg/OpenJDK/openj > > dk/jdk JDK_MAKE_SHARED_DIR=c:/Prg/OpenJDK/openjdk/jdk/make/common/shared > EXTERNA > > LSANITYCONTROL=true TARGET_CLASS_VERSION=5 MILESTONE=internal > BUILD_NUMBER=b00 J > > DK_BUILD_NUMBER=b00 FULL_VERSION=1.7.0-internal-ted_2009_03_27_03_08-b00 > PREVIOU > > S_JDK_VERSION=1.6.0 JDK_VERSION=1.7.0 JDK_MKTG_VERSION=7 > JDK_MAJOR_VERSION=1 JDK > > _MINOR_VERSION=7 JDK_MICRO_VERSION=0 PREVIOUS_MAJOR_VERSION=1 > PREVIOUS_MINOR_VER > > SION=6 PREVIOUS_MICRO_VERSION=0 ARCH_DATA_MODEL=32 COOKED_BUILD_NUMBER=0 > ANT_HOM > > E="c:/Prg/apache-ant-1.7.0" > ALT_OUTPUTDIR=c:/Prg/OpenJDK/openjdk/build/windows-i > > 586 > ALT_LANGTOOLS_DIST=c:/Prg/OpenJDK/openjdk/build/windows-i586/langtools/dist > > ALT_CORBA_DIST=c:/Prg/OpenJDK/openjdk/build/windows-i586/corba/dist > ALT_JAXP_DIS > > T=c:/Prg/OpenJDK/openjdk/build/windows-i586/jaxp/dist > ALT_JAXWS_DIST=c:/Prg/Open > > JDK/openjdk/build/windows-i586/jaxws/dist > ALT_HOTSPOT_IMPORT_PATH=c:/Prg/OpenJDK > > /openjdk/build/windows-i586/hotspot/import BUILD_HOTSPOT=true ; ) > > /bin/sh: line 0: [: cygpath:: integer expression expected > > /bin/sh: line 0: [: cygpath:: integer expression expected > > /bin/sh: line 0: [: cant -lt 6 ]; then echo older; elif [ cant: integer > expressi > > on expected > > /bin/sh: line 0: [: convert: integer expression expected > > /bin/sh: line 0: [: convert: integer expression expected > > make[1]: Entering directory `/cygdrive/c/Prg/OpenJDK/openjdk/jdk/make' > > make[2]: *** > [c:/Prg/OpenJDK/openjdk/build/windows-i586/btbins/freetype_versionc > > heck.exe] Error 2 > > make[1]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/jdk/make' > > > > Build Machine Information: > > build machine = XPJava > > > > Build Directory Structure: > > CWD = /cygdrive/c/Prg/OpenJDK/openjdk > > TOPDIR = . > > CONTROL_TOPDIR = . > > LANGTOOLS_TOPDIR = ./langtools > > JAXP_TOPDIR = ./jaxp > > JAXWS_TOPDIR = ./jaxws > > CORBA_TOPDIR = ./corba > > HOTSPOT_TOPDIR = ./hotspot > > JDK_TOPDIR = ./jdk > > > > Build Directives: > > BUILD_LANGTOOLS = true > > BUILD_JAXP = true > > BUILD_JAXWS = true > > BUILD_CORBA = true > > BUILD_HOTSPOT = true > > BUILD_JDK = true > > > > Hotspot Settings: > > HOTSPOT_BUILD_JOBS = > > HOTSPOT_OUTPUTDIR = > c:/Prg/OpenJDK/openjdk/build/windows-i586/hotspot/ou > > tputdir > > HOTSPOT_EXPORT_PATH = > c:/Prg/OpenJDK/openjdk/build/windows-i586/hotspot/im > > port > > > > > > > > > > Bootstrap Settings: > > BOOTDIR = C:/Prg/jdk1.6.0 > > ALT_BOOTDIR = C:/Prg/jdk1.6.0 > > BOOT_VER = 1.6.0 [requires at least 1.5] > > OUTPUTDIR = c:/Prg/OpenJDK/openjdk/build/windows-i586 > > ALT_OUTPUTDIR = c:/Prg/OpenJDK/openjdk/build/windows-i586 > > ABS_OUTPUTDIR = c:/Prg/OpenJDK/openjdk/build/windows-i586 > > > > Build Tool Settings: > > SLASH_JAVA = J: > > ALT_SLASH_JAVA = > > VARIANT = OPT > > JDK_DEVTOOLS_DIR = J:/devtools > > ALT_JDK_DEVTOOLS_DIR = > > ANT_HOME = c:/Prg/apache-ant-1.7.0 > > UNIXCOMMAND_PATH = /usr/bin/ > > ALT_UNIXCOMMAND_PATH = > > COMPILER_PATH = C:/Prg/MSVS9.0/Common7/Tools/../../Vc/Bin/ > > ALT_COMPILER_PATH = > > DEVTOOLS_PATH = /usr/bin/ > > ALT_DEVTOOLS_PATH = > > MSVCRT_DLL_PATH = C:/WINDOWS/system32 > > ALT_MSVCRT_DLL_PATH = > > MSVCRNN_DLL_PATH = C:/Prg/OpenJDK/deps/MSVCR > > ALT_MSVCRNN_DLL_PATH = C:/Prg/OpenJDK/deps/MSVCR > > MSDEVTOOLS_PATH = C:/Prg/MSVS9.0/VC/bin/ > > ALT_MSDEVTOOLS_PATH = C:/Prg/MSVS9.0/VC/bin > > COMPILER_NAME = Visual Studio 9 > > COMPILER_VERSION = VS2008 > > CC_VER = 15.00.21022.08 [requires at least 15.00.21022.08] > > ZIP_VER = 2.32 [requires at least 2.2] > > UNZIP_VER = 5.52 [requires at least 5.12] > > LINK_VER = 9.00.21022.08 [requires at least 9.00.21022.08] > > ANT_VER = cygpath: can't convert empty path Unable to locate > tools.jar. Expect > > ed to find it in C:\Program Files\Java\jre61.7.0 [requires at least 1.6.3] > > TEMPDIR = c:/Prg/OpenJDK/openjdk/build/windows-i586/tmp > > > > Build Directives: > > OPENJDK = true > > USE_HOTSPOT_INTERPRETER_MODE = > > PEDANTIC = > > DEV_ONLY = > > NO_DOCS = > > NO_IMAGES = > > TOOLS_ONLY = > > INSANE = > > COMPILE_APPROACH = normal > > FASTDEBUG = > > COMPILER_WARNINGS_FATAL = false > > COMPILER_WARNING_LEVEL = 3 > > INCREMENTAL_BUILD = false > > CC_HIGHEST_OPT = > > CC_HIGHER_OPT = > > CC_LOWER_OPT = > > CXXFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB > -Fdc:/Prg/OpenJDK/openjdk/b > > uild/windows-i586/tmp/obj/.pdb > -Fmc:/Prg/OpenJDK/openjdk/build/windows-i586/tmp/ > > obj/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE > > CFLAGS = -O1 -Zi -nologo -MD /D _STATIC_CPPLIB > -Fdc:/Prg/OpenJDK/openjdk/b > > uild/windows-i586/tmp/obj/.pdb > -Fmc:/Prg/OpenJDK/openjdk/build/windows-i586/tmp/ > > obj/.map -wd4800 -W3 -D _CRT_SECURE_NO_DEPRECATE > > BOOT_JAVA_CMD = C:/Prg/jdk1.6.0/bin/java -client -Xmx383m -Xms128m > -XX:PermSi > > ze=32m -XX:MaxPermSize=160m > > BOOT_JAVAC_CMD = C:/Prg/jdk1.6.0/bin/javac -J-XX:ThreadStackSize=768 > -J-clien > > t -J-Xmx383m -J-Xms128m -J-XX:PermSize=32m -J-XX:MaxPermSize=160m > -encoding asci > > i -XDignore.symbol.file=true > > BOOT_JAR_CMD = C:/Prg/jdk1.6.0/bin/jar > > BOOT_JARSIGNER_CMD = C:/Prg/jdk1.6.0/bin/jarsigner > > > > Build Platform Settings: > > USER = Ted > > PLATFORM = windows > > ARCH = i586 > > LIBARCH = i386 > > ARCH_FAMILY = i586 > > ARCH_DATA_MODEL = 32 > > ARCHPROP = x86 > > PROCESSOR_ARCHITECTURE = x86 > > PROCESSOR_IDENTIFIER = x86 Family 6 Model 15 Stepping 10, GenuineIntel > > USING_CYGWIN = true > > CYGWIN_VER = 5.1 [requires at least 4.0] > > CYGPATH_CMD = cygpath -a -s -m > > OS_VERSION = 5.1 [requires at least 5.1] > > OS_VARIANT_NAME = WindowsXP > > OS_VARIANT_VERSION = 5.1 > > TEMP_FREE_SPACE = 1827916 > > FREE_SPACE = 1827916 > > MB_OF_MEMORY = 511 > > > > GNU Make Settings: > > MAKE = make > > MAKE_VER = 3.81 [requires at least 3.78] > > MAKECMDGOALS = sanity > > MAKEFLAGS = w > > SHELL = /bin/sh > > > > Target Build Versions: > > JDK_VERSION = 1.7.0 > > MILESTONE = internal > > RELEASE = 1.7.0-internal > > FULL_VERSION = 1.7.0-internal-ted_2009_03_27_03_08-b00 > > BUILD_NUMBER = b00 > > > > External File/Binary Locations: > > USRJDKINSTANCES_PATH = C:/PROGRA~1/Java > > BUILD_JDK_IMPORT_PATH = J:/re/jdk/1.7.0/promoted/latest/binaries > > ALT_BUILD_JDK_IMPORT_PATH = > > JDK_IMPORT_PATH = C:/Prg/JDK16~1.0 > > ALT_JDK_IMPORT_PATH = C:/Prg/jdk1.6.0 > > LANGTOOLS_DIST = > > ALT_LANGTOOLS_DIST = > c:/Prg/OpenJDK/openjdk/build/windows-i586/langtools/dis > > t > > CORBA_DIST = > > ALT_CORBA_DIST = c:/Prg/OpenJDK/openjdk/build/windows-i586/corba/dist > > JAXP_DIST = > > ALT_JAXP_DIST = c:/Prg/OpenJDK/openjdk/build/windows-i586/jaxp/dist > > JAXWS_DIST = > > ALT_JAXWS_DIST = c:/Prg/OpenJDK/openjdk/build/windows-i586/jaxws/dist > > HOTSPOT_DOCS_IMPORT_PATH = /NO_DOCS_DIR > > ALT_HOTSPOT_DOCS_IMPORT_PATH = > > HOTSPOT_IMPORT_PATH = c:/Prg/OpenJDK/openjdk/build/WINDOW~1/hotspot/import > > ALT_HOTSPOT_IMPORT_PATH = > c:/Prg/OpenJDK/openjdk/build/windows-i586/hotspot/ > > import > > HOTSPOT_CLIENT_PATH = > c:/Prg/OpenJDK/openjdk/build/WINDOW~1/hotspot/import/jre > > /bin/client > > ALT_HOTSPOT_CLIENT_PATH = > > HOTSPOT_SERVER_PATH = > c:/Prg/OpenJDK/openjdk/build/WINDOW~1/hotspot/import/jre > > /bin/server > > ALT_HOTSPOT_SERVER_PATH = > > HOTSPOT_LIB_PATH = > c:/Prg/OpenJDK/openjdk/build/WINDOW~1/hotspot/import/lib > > ALT_HOTSPOT_LIB_PATH = > > DXSDK_VER = 0x0900 > > DXSDK_PATH = C:/Prg/MSDIRE~1 > > ALT_DXSDK_PATH = C:/Prg/MSDirectXSDK-03-2008 > > DXSDK_INCLUDE_PATH = C:/Prg/MSDIRE~1/Include > > ALT_DXSDK_INCLUDE_PATH = > > DXSDK_LIB_PATH = C:/Prg/MSDIRE~1/Lib > > ALT_DXSDK_LIB_PATH = > > CACERTS_FILE = ./../src/share/lib/security/cacerts > > ALT_CACERTS_FILE = > > > > OpenJDK-specific settings: > > FREETYPE_HEADERS_PATH = > C:/Prg/OpenJDK/deps/freetype-2.3.9/windows/freetype-i5 > > 86/include/freetype2 > > ALT_FREETYPE_HEADERS_PATH = > C:/Prg/OpenJDK/deps/freetype-2.3.9/windows/freet > > ype-i586/include/freetype2 > > FREETYPE_LIB_PATH = > C:/Prg/OpenJDK/deps/freetype-igor/windows/freetype-i586/li > > b > > ALT_FREETYPE_LIB_PATH = > C:/Prg/OpenJDK/deps/freetype-igor/windows/freetype-i > > 586/lib > > > > OPENJDK Import Binary Plug Settings: > > BINARY_PLUGS_JARFILE = > /cygdrive/c/Prg/OpenJDK/openjdk-binary-plugs/jre/lib/rt > > -closed.jar > > ALT_BINARY_PLUGS_JARFILE = > > BINARY_PLUGS_PATH = /cygdrive/c/Prg/OpenJDK/openjdk-binary-plugs > > ALT_BINARY_PLUGS_PATH = /cygdrive/c/Prg/OpenJDK/openjdk-binary-plugs > > BUILD_BINARY_PLUGS_PATH = > J:/re/jdk/1.7.0/promoted/latest/openjdk/binaryplugs > > ALT_BUILD_BINARY_PLUGS_PATH = > > PLUG_LIBRARY_NAMES = > > > > Previous JDK Settings: > > PREVIOUS_RELEASE_PATH = USING-PREVIOUS_RELEASE_IMAGE > > ALT_PREVIOUS_RELEASE_PATH = > > PREVIOUS_JDK_VERSION = 1.6.0 > > ALT_PREVIOUS_JDK_VERSION = > > PREVIOUS_JDK_FILE = > > ALT_PREVIOUS_JDK_FILE = > > PREVIOUS_JRE_FILE = > > ALT_PREVIOUS_JRE_FILE = > > PREVIOUS_RELEASE_IMAGE = C:/Prg/jdk1.6.0 > > ALT_PREVIOUS_RELEASE_IMAGE = > > > > > > WARNING: This machine appears to only have 511Mb of physical memory, > > builds on this machine could be slow. > > > > ERROR: FreeType version 2.3.0 or higher is required. > > make[2]: Entering directory > `/cygdrive/c/Prg/OpenJDK/openjdk/jdk/make/tools/fre > > etypecheck' > > freetypecheck.c > > freetypecheck.c(29) : fatal error C1083: Cannot open include file: > 'stdio.h': No > > such file or directory > > make[2]: Leaving directory > `/cygdrive/c/Prg/OpenJDK/openjdk/jdk/make/tools/freet > > ypecheck' > > Failed to build freetypecheck. > > > > Exiting because of the above error(s). > > > > make: *** [post-sanity] Error 1 > > :/cygdrive/c/Prg/OpenJDK/openjdk > > $ > > > > > > > > Ted Neward | Principal Consultant, ThoughtWorks > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.thoughtworks.com | > http://www.tedneward.com > > > > > From Tim.Bell at Sun.COM Fri Mar 27 16:50:25 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Fri, 27 Mar 2009 09:50:25 -0700 Subject: Grr.... In-Reply-To: <49CD0184.9060004@sun.com> References: <02e301c9aec5$3b0b81d0$b1228570$@com> <49CD0184.9060004@sun.com> Message-ID: <49CD03D1.3030905@sun.com> Hi Kelly > freetypecheck has been a royal major pain in the you know what.... > So you are not alone. I thought I reviewed some changes you wrote that eliminated the freetypecheck program and instead used something like grep to check for the version information in the freetype header files. Was I dreaming? ;-) Ted wrote: >> Here?s what I?m getting. Somebody please tell me how to figure out >> where the ?:convert integer expression expected? messages are coming >> from, or why I?m getting them, before I go insane. (Then you can tell >> me why cl.exe can?t find ?stdio.h? when it?s on the INCLUDE >> environment variable path?.) Kelly wrote: > The problem is when the freetype include files are living with the cygwin > stdio.h, which is not the one that cl.exe wants or likes. > > I ran into this when I tried to use the freetype in cygwin, so I finally > gave up on using a cygwin freetype. Ted wrote: >> Oh and while you?re at THAT, somebody tell me how to build a DLL >> version of FreeType. See step 8 of my blog posting: http://blogs.sun.com/TimBell/entry/building_openjdk7_on_32_bit That's what worked for me, way back when. Let me know if the instructions are stale. Tim From Kelly.Ohair at Sun.COM Fri Mar 27 16:57:06 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 27 Mar 2009 09:57:06 -0700 Subject: Grr.... In-Reply-To: <49CD03D1.3030905@sun.com> References: <02e301c9aec5$3b0b81d0$b1228570$@com> <49CD0184.9060004@sun.com> <49CD03D1.3030905@sun.com> Message-ID: <49CD0562.4090503@sun.com> Tim Bell wrote: > Hi Kelly > >> freetypecheck has been a royal major pain in the you know what.... >> So you are not alone. > > I thought I reviewed some changes you wrote that eliminated the > freetypecheck program and instead used something like grep to check for > the version information in the freetype header files. Was I dreaming? ;-) > I think that was the ALSA sound version check, Linux only. I'd like to do the same thing with freetype, but the catch is that you really need to verify that the DLL works on windows. > Ted wrote: > >>> Here?s what I?m getting. Somebody please tell me how to figure out >>> where the ?:convert integer expression expected? messages are coming >>> from, or why I?m getting them, before I go insane. (Then you can tell >>> me why cl.exe can?t find ?stdio.h? when it?s on the INCLUDE >>> environment variable path?.) > > Kelly wrote: > >> The problem is when the freetype include files are living with the cygwin >> stdio.h, which is not the one that cl.exe wants or likes. >> >> I ran into this when I tried to use the freetype in cygwin, so I finally >> gave up on using a cygwin freetype. > > Ted wrote: > >>> Oh and while you?re at THAT, somebody tell me how to build a DLL >>> version of FreeType. > > See step 8 of my blog posting: > http://blogs.sun.com/TimBell/entry/building_openjdk7_on_32_bit > That's what worked for me, way back when. Let me know if the > instructions are stale. That would have helped, not sure why I couldn't find it when I googled. But the instructions seem quite complicated, we should probably script this or bury this in a Makefile that builds it from a source bundle. -kto > > Tim From Kelly.Ohair at Sun.COM Fri Mar 27 17:08:38 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 27 Mar 2009 10:08:38 -0700 Subject: RC.exe location change? In-Reply-To: <02f301c9aed7$04e15e10$0ea41a30$@com> References: <02f301c9aed7$04e15e10$0ea41a30$@com> Message-ID: <49CD0816.8090701@sun.com> What forest are you pulling your changes from? We have been working on the VS2008 transition on 32bit, and also on 64bit for the v6.1 SDK, so it's pretty fresh stuff. I've been wrestling with the 64bit Windows v6.1 SDK changes, and Tim Bell has been working on the 32bit VS2008 compiler changes. But we haven't yet got to the 32bit v6.1 SDK changes. Tim Bell may have more to say on this. a few more comments below... Ted Neward wrote: > While building the OpenJDK (finally got past the FreeType issues, though > I?m not entirely sure how or why, which bugs me), I?ve run across an > error where the make files seem to assume that rc.exe lives in the > compiler directory? and it doesn?t?it?s been moved to the Platform SDK. > > > > For example, the problem first shows up in > corba/make/common/shared/Compiler-msvc.gmk: Yes, an unfortunate copy of the jdk file. :^( > > > > # > > # MSVC Compiler settings > > # > > > > ifeq ($(PLATFORM), windows) > > CC = $(COMPILER_PATH)cl > > CPP = $(COMPILER_PATH)cl > > CXX = $(COMPILER_PATH)cl > > CCC = $(COMPILER_PATH)cl > > LIBEXE = $(COMPILER_PATH)lib > > LINK = $(COMPILER_PATH)link > > # > > # Begin TKN mod > > # > > # RC = $(MSDEVTOOLS_PATH)rc > > RC = $(MSDEVTOOLS_PATH)/../MicrosoftSDKs/Windows/v6.1/Bin/rc > > # > > # End TKN mod > > # > > LINK32 = $(LINK) > > RSC = $(RC) > > > > Now I?m not sure if MSDEVTOOLS_PATH is supposed to point to the > PlatformSDK bin, or the MSVS9.0/VC/bin (which is what other parts of the > build system seem to assume), or what, but rc.exe pretty definitively > isn?t in the VC directory of VS 2008, from what I can tell. (I checked > on another machine that had a ?go ahead install everything? install > experience, and it?s not there, either.) Yes, it appears to move around with each compile release. And also between the free Express edition and the paid for products I think. The MSDEVTOOLS_PATH variable may need to be trashed. We should be referring to the SDK area, in the many places that might be. :^( > > > > Dunno if this is a bug, or what, but the Compiler-msvc file should > probably be patched to read something like: > > > > ifeq ($(CC_MAJORVER), 15) > > # This should be: CC_VER=15.00.21022.08 LINK_VER=9.00.21022.08 > > REQUIRED_CC_VER = 15.00.21022.08 > > REQUIRED_LINK_VER = 9.00.21022.08 > > COMPILER_NAME=Visual Studio 9 > > COMPILER_VERSION=VS2008 > > #rebase and midl moved out of Visual Studio into the SDK: > > REBASE = $(MSDEVTOOLS_PATH)/rebase > > MTL = $(MSDEVTOOLS_PATH)/midl.exe > > RC = $(MSDEVTOOLS_PATH)/rc.exe > > RCS = $(RC) > > ifndef COMPILER_PATH > > COMPILER_PATH := $(error COMPILER_PATH cannot be empty here) > > endif > > endif > > > > ? assuming MSDEVTOOLS_PATH is supposed to point to the PlatformSDK bin > (and not MSVS9.0/VC/bin). Yes, I think that is right. > > > > Is that the breakdown between COMPILER_PATH and MSDEVTOOLS_PATH? The > README implies that the latter is derived from the former, and it > probably shouldn?t be?. > Correct. We should toss MSDEVTOOLS_PATH in my opinion. And not assume the SDK is in the compiler area, like it was with Visual Studio 2003 Professional Edition. -kto > > > Ted Neward | Principal Consultant, ThoughtWorks > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.thoughtworks.com | > http://www.tedneward.com > > > > > From Kelly.Ohair at Sun.COM Fri Mar 27 18:15:28 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 27 Mar 2009 11:15:28 -0700 Subject: Bug 100028 - Debug information is incomplete or missing In-Reply-To: <49CBB205.8040109@redhat.com> References: <49BFB13B.2000602@redhat.com> <49C019BF.6010804@sun.com> <49C0D1E7.6030707@redhat.com> <49CBB205.8040109@redhat.com> Message-ID: <49CD17C0.9010106@sun.com> Seems ok to me, just a few observations: Do we need this: ifeq ($(DEBUG_CLASSFILES), true) ANT_OPTIONS += -Djavac.debug=true ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars endif to be ifeq ($(DEBUG_CLASSFILES), true) ANT_OPTIONS += -Djavac.debug=true ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars else ANT_OPTIONS += -Djavac.debug=false ANT_OPTIONS += -Djavac.debuglevel= endif Not sure what happens in ant if a property is not set but used???. On this: # DEBUG_BINARIES overrides everything ifeq ($(DEBUG_BINARIES), true) CFLAGS_REQUIRED += -g DEBUG_FLAG = -g endif I think the idea with isolating the -g to a variable was to allow for needing to globally set it to -gstabs or -g1 or some custom debug form for everyone. e.g. being able to do a top level 'make DEBUG_BINARIES=true DEBUG_FLAG=-g1'. So how about: # DEBUG_BINARIES overrides everything, use full -g debug information ifeq ($(DEBUG_BINARIES), true) DEBUG_FLAG = -g CFLAGS_REQUIRED += $(DEBUG_FLAG) endif Otherwise it seems fine. If you have patch files for each repository (hg diff > patch) I can run them through our test build system JPRT for you, and send you the results. -kto Andrew Haley wrote: > This is my first stab at moving patches from IcedTea into OpenJDK. > > Rather than creating a single overriding variable that enables debuginfo > everywhere I've used two, one for native files and one for class files. > Setting DEBUG_CLASSFILES=true in the toplevel forces all classes to be built > with full debuginfo, and DEBUG_BINARIES does the same for native binaries. > These make variables are entirely independent of the debug and optimization > setting. This allows GNU/Linux distributions to build OpenJDK in a form > fit for distribution without patching makefiles or Ant buildfiles. It also > means that the Ant variables javac.debug and javac.debuginfo are respected > everwhere in the build. > > https://bugs.openjdk.java.net/show_bug.cgi?id=100028 > > Is this OK? > > Andrew. > > > From ted at tedneward.com Fri Mar 27 22:17:10 2009 From: ted at tedneward.com (Ted Neward) Date: Fri, 27 Mar 2009 15:17:10 -0700 Subject: RC.exe location change? In-Reply-To: <49CD0816.8090701@sun.com> References: <02f301c9aed7$04e15e10$0ea41a30$@com> <49CD0816.8090701@sun.com> Message-ID: <042b01c9af29$ca8e67a0$5fab36e0$@com> This was the b52 source drop on the openjdk website, not a Mercurial pull. (Trying to get back to basics here.) Which compiler are you using for the Windows JDK builds? VS2005? Rather than toss MSDEVTOOLS, I would propose two variables: ALT_MSDEVTOOLS_PATH - for the root of the Visual Studio installation ALT_MSSDKTOOLS_PATH - for the root of the Microsoft SDK installation Such that COMPILER_PATH = $ALT_MSDEVTOOLS_PATH/VC/bin and RC = $ALT_MSSDKTOOLS_PATH/bin/rc.exe Where on my box, I would set ALT_MSDEVTOOLS_PATH=C:/Prg/MSVS9.0 ALT_MSSDKTOOLS_PATH=C:/Prg/MicrosoftSDKs/Windows/v6.1 This would also work for previous installations of VS, since they install the SDK at C:/Prg/MSVS/SDK/v1.1 or something similar. Tim? Does this sound workable? Ted Neward | Principal Consultant, ThoughtWorks Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.thoughtworks.com | http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Friday, March 27, 2009 10:09 AM > To: Ted Neward > Cc: 'build-dev' > Subject: Re: RC.exe location change? > > What forest are you pulling your changes from? > > We have been working on the VS2008 transition on 32bit, and also > on 64bit for the v6.1 SDK, so it's pretty fresh stuff. > I've been wrestling with the 64bit Windows v6.1 SDK changes, and > Tim Bell has been working on the 32bit VS2008 compiler changes. > But we haven't yet got to the 32bit v6.1 SDK changes. > Tim Bell may have more to say on this. > > a few more comments below... > > > Ted Neward wrote: > > While building the OpenJDK (finally got past the FreeType issues, > though > > I'm not entirely sure how or why, which bugs me), I've run across an > > error where the make files seem to assume that rc.exe lives in the > > compiler directory. and it doesn't-it's been moved to the Platform > SDK. > > > > > > > > For example, the problem first shows up in > > corba/make/common/shared/Compiler-msvc.gmk: > > Yes, an unfortunate copy of the jdk file. :^( > > > > > > > > > # > > > > # MSVC Compiler settings > > > > # > > > > > > > > ifeq ($(PLATFORM), windows) > > > > CC = $(COMPILER_PATH)cl > > > > CPP = $(COMPILER_PATH)cl > > > > CXX = $(COMPILER_PATH)cl > > > > CCC = $(COMPILER_PATH)cl > > > > LIBEXE = $(COMPILER_PATH)lib > > > > LINK = $(COMPILER_PATH)link > > > > # > > > > # Begin TKN mod > > > > # > > > > # RC = $(MSDEVTOOLS_PATH)rc > > > > RC = > $(MSDEVTOOLS_PATH)/../MicrosoftSDKs/Windows/v6.1/Bin/rc > > > > # > > > > # End TKN mod > > > > # > > > > LINK32 = $(LINK) > > > > RSC = $(RC) > > > > > > > > Now I'm not sure if MSDEVTOOLS_PATH is supposed to point to the > > PlatformSDK bin, or the MSVS9.0/VC/bin (which is what other parts of > the > > build system seem to assume), or what, but rc.exe pretty definitively > > isn't in the VC directory of VS 2008, from what I can tell. (I > checked > > on another machine that had a "go ahead install everything" install > > experience, and it's not there, either.) > > Yes, it appears to move around with each compile release. > And also between the free Express edition and the paid for products I > think. > > The MSDEVTOOLS_PATH variable may need to be trashed. > We should be referring to the SDK area, in the many places that might > be. :^( > > > > > > > > > Dunno if this is a bug, or what, but the Compiler-msvc file should > > probably be patched to read something like: > > > > > > > > ifeq ($(CC_MAJORVER), 15) > > > > # This should be: CC_VER=15.00.21022.08 LINK_VER=9.00.21022.08 > > > > REQUIRED_CC_VER = 15.00.21022.08 > > > > REQUIRED_LINK_VER = 9.00.21022.08 > > > > COMPILER_NAME=Visual Studio 9 > > > > COMPILER_VERSION=VS2008 > > > > #rebase and midl moved out of Visual Studio into the SDK: > > > > REBASE = $(MSDEVTOOLS_PATH)/rebase > > > > MTL = $(MSDEVTOOLS_PATH)/midl.exe > > > > RC = $(MSDEVTOOLS_PATH)/rc.exe > > > > RCS = $(RC) > > > > ifndef COMPILER_PATH > > > > COMPILER_PATH := $(error COMPILER_PATH cannot be > empty here) > > > > endif > > > > endif > > > > > > > > . assuming MSDEVTOOLS_PATH is supposed to point to the PlatformSDK > bin > > (and not MSVS9.0/VC/bin). > > Yes, I think that is right. > > > > > > > > > Is that the breakdown between COMPILER_PATH and MSDEVTOOLS_PATH? The > > README implies that the latter is derived from the former, and it > > probably shouldn't be.. > > > > Correct. We should toss MSDEVTOOLS_PATH in my opinion. > And not assume the SDK is in the compiler area, like it was with > Visual Studio 2003 Professional Edition. > > -kto > > > > > > > Ted Neward | Principal Consultant, ThoughtWorks > > > > Java, .NET, XML Services > > > > Consulting, Teaching, Speaking, Writing > > > > http://www.thoughtworks.com | > > http://www.tedneward.com > > > > > > > > > > From Kelly.Ohair at Sun.COM Fri Mar 27 23:17:38 2009 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Fri, 27 Mar 2009 16:17:38 -0700 Subject: RC.exe location change? In-Reply-To: <042b01c9af29$ca8e67a0$5fab36e0$@com> References: <02f301c9aed7$04e15e10$0ea41a30$@com> <49CD0816.8090701@sun.com> <042b01c9af29$ca8e67a0$5fab36e0$@com> Message-ID: <49CD5E92.8060901@sun.com> Ted Neward wrote: > This was the b52 source drop on the openjdk website, not a Mercurial pull. > (Trying to get back to basics here.) > > Which compiler are you using for the Windows JDK builds? VS2005? Currently we are still using VS2003, but we are trying to transition to VS2008 for official builds but also allow for VS2005 for developers. It may take more time for us to completely get off VS2003. > > > Rather than toss MSDEVTOOLS, I would propose two variables: > > ALT_MSDEVTOOLS_PATH - for the root of the Visual Studio installation > ALT_MSSDKTOOLS_PATH - for the root of the Microsoft SDK installation > > Such that > > COMPILER_PATH = $ALT_MSDEVTOOLS_PATH/VC/bin > > and > > RC = $ALT_MSSDKTOOLS_PATH/bin/rc.exe > > Where on my box, I would set > > ALT_MSDEVTOOLS_PATH=C:/Prg/MSVS9.0 > ALT_MSSDKTOOLS_PATH=C:/Prg/MicrosoftSDKs/Windows/v6.1 > > This would also work for previous installations of VS, since they install > the SDK at C:/Prg/MSVS/SDK/v1.1 or something similar. > > Tim? Does this sound workable? Seems ok to me. Of course, as always with Windows, proof is in the pudding, so to speak. ;^) -kto > > Ted Neward | Principal Consultant, ThoughtWorks > Java, .NET, XML Services > Consulting, Teaching, Speaking, Writing > http://www.thoughtworks.com | http://www.tedneward.com > >> -----Original Message----- >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] >> Sent: Friday, March 27, 2009 10:09 AM >> To: Ted Neward >> Cc: 'build-dev' >> Subject: Re: RC.exe location change? >> >> What forest are you pulling your changes from? >> >> We have been working on the VS2008 transition on 32bit, and also >> on 64bit for the v6.1 SDK, so it's pretty fresh stuff. >> I've been wrestling with the 64bit Windows v6.1 SDK changes, and >> Tim Bell has been working on the 32bit VS2008 compiler changes. >> But we haven't yet got to the 32bit v6.1 SDK changes. >> Tim Bell may have more to say on this. >> >> a few more comments below... >> >> >> Ted Neward wrote: >>> While building the OpenJDK (finally got past the FreeType issues, >> though >>> I'm not entirely sure how or why, which bugs me), I've run across an >>> error where the make files seem to assume that rc.exe lives in the >>> compiler directory. and it doesn't-it's been moved to the Platform >> SDK. >>> >>> >>> For example, the problem first shows up in >>> corba/make/common/shared/Compiler-msvc.gmk: >> Yes, an unfortunate copy of the jdk file. :^( >> >>> >>> >>> # >>> >>> # MSVC Compiler settings >>> >>> # >>> >>> >>> >>> ifeq ($(PLATFORM), windows) >>> >>> CC = $(COMPILER_PATH)cl >>> >>> CPP = $(COMPILER_PATH)cl >>> >>> CXX = $(COMPILER_PATH)cl >>> >>> CCC = $(COMPILER_PATH)cl >>> >>> LIBEXE = $(COMPILER_PATH)lib >>> >>> LINK = $(COMPILER_PATH)link >>> >>> # >>> >>> # Begin TKN mod >>> >>> # >>> >>> # RC = $(MSDEVTOOLS_PATH)rc >>> >>> RC = >> $(MSDEVTOOLS_PATH)/../MicrosoftSDKs/Windows/v6.1/Bin/rc >>> # >>> >>> # End TKN mod >>> >>> # >>> >>> LINK32 = $(LINK) >>> >>> RSC = $(RC) >>> >>> >>> >>> Now I'm not sure if MSDEVTOOLS_PATH is supposed to point to the >>> PlatformSDK bin, or the MSVS9.0/VC/bin (which is what other parts of >> the >>> build system seem to assume), or what, but rc.exe pretty definitively >>> isn't in the VC directory of VS 2008, from what I can tell. (I >> checked >>> on another machine that had a "go ahead install everything" install >>> experience, and it's not there, either.) >> Yes, it appears to move around with each compile release. >> And also between the free Express edition and the paid for products I >> think. >> >> The MSDEVTOOLS_PATH variable may need to be trashed. >> We should be referring to the SDK area, in the many places that might >> be. :^( >> >>> >>> >>> Dunno if this is a bug, or what, but the Compiler-msvc file should >>> probably be patched to read something like: >>> >>> >>> >>> ifeq ($(CC_MAJORVER), 15) >>> >>> # This should be: CC_VER=15.00.21022.08 LINK_VER=9.00.21022.08 >>> >>> REQUIRED_CC_VER = 15.00.21022.08 >>> >>> REQUIRED_LINK_VER = 9.00.21022.08 >>> >>> COMPILER_NAME=Visual Studio 9 >>> >>> COMPILER_VERSION=VS2008 >>> >>> #rebase and midl moved out of Visual Studio into the SDK: >>> >>> REBASE = $(MSDEVTOOLS_PATH)/rebase >>> >>> MTL = $(MSDEVTOOLS_PATH)/midl.exe >>> >>> RC = $(MSDEVTOOLS_PATH)/rc.exe >>> >>> RCS = $(RC) >>> >>> ifndef COMPILER_PATH >>> >>> COMPILER_PATH := $(error COMPILER_PATH cannot be >> empty here) >>> endif >>> >>> endif >>> >>> >>> >>> . assuming MSDEVTOOLS_PATH is supposed to point to the PlatformSDK >> bin >>> (and not MSVS9.0/VC/bin). >> Yes, I think that is right. >> >>> >>> >>> Is that the breakdown between COMPILER_PATH and MSDEVTOOLS_PATH? The >>> README implies that the latter is derived from the former, and it >>> probably shouldn't be.. >>> >> Correct. We should toss MSDEVTOOLS_PATH in my opinion. >> And not assume the SDK is in the compiler area, like it was with >> Visual Studio 2003 Professional Edition. >> >> -kto >> >>> >>> Ted Neward | Principal Consultant, ThoughtWorks >>> >>> Java, .NET, XML Services >>> >>> Consulting, Teaching, Speaking, Writing >>> >>> http://www.thoughtworks.com | >>> http://www.tedneward.com >>> >>> >>> >>> >>> > From ted at tedneward.com Sat Mar 28 02:38:41 2009 From: ted at tedneward.com (Ted Neward) Date: Fri, 27 Mar 2009 19:38:41 -0700 Subject: RC.exe location change? In-Reply-To: <49CD5E92.8060901@sun.com> References: <02f301c9aed7$04e15e10$0ea41a30$@com> <49CD0816.8090701@sun.com> <042b01c9af29$ca8e67a0$5fab36e0$@com> <49CD5E92.8060901@sun.com> Message-ID: <04aa01c9af4e$55d06380$01712a80$@com> I'm happy to test the VS2008 (and VS2005) build fixes, and possibly even contribute a few, but I'd need to know where to start folding in the new macrology to make it all work throughout the system. For example, assuming I want to introduce a new macro, "SDKTOOLS_PATH" and its overridable equivalent, "ALT_SDKTOOLS_PATH", in which file is the "right" place to start working those through the build? I'm guessing Compiler-msvc.gmk and Defs-windows.gmk are the two places to start looking, but are there others I'm not aware of? Thinking about it, what I'd like to suggest is: (ALT_)MSDEVTOOLS_PATH -> location of Visual Studio installation (C:/Prg/MSVS9.0) (ALT_)MSSDKTOOLS_PATH -> location of Microsoft SDK installation (C:/Prg/MicrosoftSDKs/Windows/v6.1/Bin) (ALT_)COMPILER_PATH -> location of cl.exe (C:/Prg/MSVS9.0/VC/bin or C:/Prg/MicrosoftSDKs/Windows/v6.1/Bin) Where COMPILER_PATH could be either the VS cl or the MSSDK cl depending on which one you feel like using. (This could also make it easier to adopt the Express editions.) Being not very Mercurial-savvy, can I simply post my changes to this list? Ted Neward | Principal Consultant, ThoughtWorks Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.thoughtworks.com | http://www.tedneward.com > -----Original Message----- > From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > Sent: Friday, March 27, 2009 4:18 PM > To: Ted Neward > Cc: 'build-dev' > Subject: Re: RC.exe location change? > > > > Ted Neward wrote: > > This was the b52 source drop on the openjdk website, not a Mercurial > pull. > > (Trying to get back to basics here.) > > > > Which compiler are you using for the Windows JDK builds? VS2005? > > Currently we are still using VS2003, but we are trying to transition to > VS2008 for official builds but also allow for VS2005 for developers. > It may take more time for us to completely get off VS2003. > > > > > > > Rather than toss MSDEVTOOLS, I would propose two variables: > > > > ALT_MSDEVTOOLS_PATH - for the root of the Visual Studio installation > > ALT_MSSDKTOOLS_PATH - for the root of the Microsoft SDK installation > > > > Such that > > > > COMPILER_PATH = $ALT_MSDEVTOOLS_PATH/VC/bin > > > > and > > > > RC = $ALT_MSSDKTOOLS_PATH/bin/rc.exe > > > > Where on my box, I would set > > > > ALT_MSDEVTOOLS_PATH=C:/Prg/MSVS9.0 > > ALT_MSSDKTOOLS_PATH=C:/Prg/MicrosoftSDKs/Windows/v6.1 > > > > This would also work for previous installations of VS, since they > install > > the SDK at C:/Prg/MSVS/SDK/v1.1 or something similar. > > > > Tim? Does this sound workable? > > Seems ok to me. > > Of course, as always with Windows, proof is in the pudding, so to > speak. ;^) > > -kto > > > > > Ted Neward | Principal Consultant, ThoughtWorks > > Java, .NET, XML Services > > Consulting, Teaching, Speaking, Writing > > http://www.thoughtworks.com | http://www.tedneward.com > > > >> -----Original Message----- > >> From: Kelly.Ohair at Sun.COM [mailto:Kelly.Ohair at Sun.COM] > >> Sent: Friday, March 27, 2009 10:09 AM > >> To: Ted Neward > >> Cc: 'build-dev' > >> Subject: Re: RC.exe location change? > >> > >> What forest are you pulling your changes from? > >> > >> We have been working on the VS2008 transition on 32bit, and also > >> on 64bit for the v6.1 SDK, so it's pretty fresh stuff. > >> I've been wrestling with the 64bit Windows v6.1 SDK changes, and > >> Tim Bell has been working on the 32bit VS2008 compiler changes. > >> But we haven't yet got to the 32bit v6.1 SDK changes. > >> Tim Bell may have more to say on this. > >> > >> a few more comments below... > >> > >> > >> Ted Neward wrote: > >>> While building the OpenJDK (finally got past the FreeType issues, > >> though > >>> I'm not entirely sure how or why, which bugs me), I've run across > an > >>> error where the make files seem to assume that rc.exe lives in the > >>> compiler directory. and it doesn't-it's been moved to the Platform > >> SDK. > >>> > >>> > >>> For example, the problem first shows up in > >>> corba/make/common/shared/Compiler-msvc.gmk: > >> Yes, an unfortunate copy of the jdk file. :^( > >> > >>> > >>> > >>> # > >>> > >>> # MSVC Compiler settings > >>> > >>> # > >>> > >>> > >>> > >>> ifeq ($(PLATFORM), windows) > >>> > >>> CC = $(COMPILER_PATH)cl > >>> > >>> CPP = $(COMPILER_PATH)cl > >>> > >>> CXX = $(COMPILER_PATH)cl > >>> > >>> CCC = $(COMPILER_PATH)cl > >>> > >>> LIBEXE = $(COMPILER_PATH)lib > >>> > >>> LINK = $(COMPILER_PATH)link > >>> > >>> # > >>> > >>> # Begin TKN mod > >>> > >>> # > >>> > >>> # RC = $(MSDEVTOOLS_PATH)rc > >>> > >>> RC = > >> $(MSDEVTOOLS_PATH)/../MicrosoftSDKs/Windows/v6.1/Bin/rc > >>> # > >>> > >>> # End TKN mod > >>> > >>> # > >>> > >>> LINK32 = $(LINK) > >>> > >>> RSC = $(RC) > >>> > >>> > >>> > >>> Now I'm not sure if MSDEVTOOLS_PATH is supposed to point to the > >>> PlatformSDK bin, or the MSVS9.0/VC/bin (which is what other parts > of > >> the > >>> build system seem to assume), or what, but rc.exe pretty > definitively > >>> isn't in the VC directory of VS 2008, from what I can tell. (I > >> checked > >>> on another machine that had a "go ahead install everything" install > >>> experience, and it's not there, either.) > >> Yes, it appears to move around with each compile release. > >> And also between the free Express edition and the paid for products > I > >> think. > >> > >> The MSDEVTOOLS_PATH variable may need to be trashed. > >> We should be referring to the SDK area, in the many places that > might > >> be. :^( > >> > >>> > >>> > >>> Dunno if this is a bug, or what, but the Compiler-msvc file should > >>> probably be patched to read something like: > >>> > >>> > >>> > >>> ifeq ($(CC_MAJORVER), 15) > >>> > >>> # This should be: CC_VER=15.00.21022.08 > LINK_VER=9.00.21022.08 > >>> > >>> REQUIRED_CC_VER = 15.00.21022.08 > >>> > >>> REQUIRED_LINK_VER = 9.00.21022.08 > >>> > >>> COMPILER_NAME=Visual Studio 9 > >>> > >>> COMPILER_VERSION=VS2008 > >>> > >>> #rebase and midl moved out of Visual Studio into the SDK: > >>> > >>> REBASE = $(MSDEVTOOLS_PATH)/rebase > >>> > >>> MTL = $(MSDEVTOOLS_PATH)/midl.exe > >>> > >>> RC = $(MSDEVTOOLS_PATH)/rc.exe > >>> > >>> RCS = $(RC) > >>> > >>> ifndef COMPILER_PATH > >>> > >>> COMPILER_PATH := $(error COMPILER_PATH cannot be > >> empty here) > >>> endif > >>> > >>> endif > >>> > >>> > >>> > >>> . assuming MSDEVTOOLS_PATH is supposed to point to the PlatformSDK > >> bin > >>> (and not MSVS9.0/VC/bin). > >> Yes, I think that is right. > >> > >>> > >>> > >>> Is that the breakdown between COMPILER_PATH and MSDEVTOOLS_PATH? > The > >>> README implies that the latter is derived from the former, and it > >>> probably shouldn't be.. > >>> > >> Correct. We should toss MSDEVTOOLS_PATH in my opinion. > >> And not assume the SDK is in the compiler area, like it was with > >> Visual Studio 2003 Professional Edition. > >> > >> -kto > >> > >>> > >>> Ted Neward | Principal Consultant, ThoughtWorks > >>> > >>> Java, .NET, XML Services > >>> > >>> Consulting, Teaching, Speaking, Writing > >>> > >>> http://www.thoughtworks.com | > >>> http://www.tedneward.com > >>> > >>> > >>> > >>> > >>> > > From ted at tedneward.com Sat Mar 28 02:57:29 2009 From: ted at tedneward.com (Ted Neward) Date: Fri, 27 Mar 2009 19:57:29 -0700 Subject: Where do COMPILER_VERSION and its ilk get set? Message-ID: <04c601c9af50$f3e27980$dba76c80$@com> Getting *** WARNING *** unrecognized cl.exe version 1500 (). Use FORCE_MSC_VER to overri de automatic detection. *** WARNING *** unrecognized link.exe version 900 (). Use FORCE_LINK_VER to over ride automatic detection. Warnings from Hotspot make.. Where would I look to fix those? Ted Neward | Principal Consultant, ThoughtWorks Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.thoughtworks.com | http://www.tedneward.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From ted at tedneward.com Sat Mar 28 07:02:40 2009 From: ted at tedneward.com (Ted Neward) Date: Sat, 28 Mar 2009 00:02:40 -0700 Subject: Arrgh... more path issues? Message-ID: <04ef01c9af73$34277230$9c765690$@com> Let me guess: this is because the jar utility doesn't like Cygwin paths.? (cd C:/Prg/jdk1.7.0/build-fastdebug/classes && C:/Prg/jdk1.6.0/bin/jar xf /cygd rive/c/Prg/OpenJDK/openjdk-binary-plugs/jre/lib/rt-closed.jar @C:/Prg/jdk1.7.0/b uild-fastdebug/tmp/java/plugs/jmf.clist -J-client -J-Xmx383m -J-Xms128m -J-XX:Pe rmSize=32m -J-XX:MaxPermSize=160m ) java.io.FileNotFoundException: \cygdrive\c\Prg\OpenJDK\openjdk-binary-plugs\jre\ lib\rt-closed.jar (The system cannot find the path specified) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.(FileInputStream.java:106) at java.io.FileInputStream.(FileInputStream.java:66) at sun.tools.jar.Main.run(Main.java:205) at sun.tools.jar.Main.main(Main.java:1022) make[5]: *** [import-binary-plug-jmf-classes] Error 1 make[5]: Leaving directory `/cygdrive/c/Prg/OpenJDK/openjdk/jdk/make/java/redist ' make[4]: *** [all] Error 1 I would suggest, as an RFE or bug, that the various macros used on Windows have some kind of naming convention to them to indicate where a Cygwin path is needed, where an MS-style path is needed, and where it makes no difference. (But I have no offhand suggestions as to what that naming convention would look like, or how it might interact with the build macros for other platforms.) There's just GOT to be some kind of way to tell these apart, though. :-/ Ted Neward | Principal Consultant, ThoughtWorks Java, .NET, XML Services Consulting, Teaching, Speaking, Writing http://www.thoughtworks.com | http://www.tedneward.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From aph at redhat.com Mon Mar 30 16:00:01 2009 From: aph at redhat.com (Andrew Haley) Date: Mon, 30 Mar 2009 17:00:01 +0100 Subject: Bug 100028 - Debug information is incomplete or missing In-Reply-To: <49CD17C0.9010106@sun.com> References: <49BFB13B.2000602@redhat.com> <49C019BF.6010804@sun.com> <49C0D1E7.6030707@redhat.com> <49CBB205.8040109@redhat.com> <49CD17C0.9010106@sun.com> Message-ID: <49D0EC81.20106@redhat.com> Kelly O'Hair wrote: > > Seems ok to me, just a few observations: > > Do we need this: > > ifeq ($(DEBUG_CLASSFILES), true) > ANT_OPTIONS += -Djavac.debug=true > ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars > endif > > to be > > ifeq ($(DEBUG_CLASSFILES), true) > ANT_OPTIONS += -Djavac.debug=true > ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars > else > ANT_OPTIONS += -Djavac.debug=false > ANT_OPTIONS += -Djavac.debuglevel= > endif I think we probably do, yes. I was trying to follow the principle of touching as little as possible with my first patch, but it seems to me that $(DEBUG_CLASSFILES) is the appropriate make variable to control this. > Not sure what happens in ant if a property is not set but used???. > > On this: > > # DEBUG_BINARIES overrides everything > ifeq ($(DEBUG_BINARIES), true) > CFLAGS_REQUIRED += -g > DEBUG_FLAG = -g > endif > > I think the idea with isolating the -g to a variable was to allow for > needing to globally set it to -gstabs or -g1 or some custom debug form for > everyone. e.g. being able to do a top level 'make DEBUG_BINARIES=true > DEBUG_FLAG=-g1'. Thanks, I hadn't considered this possibility. > So how about: > > # DEBUG_BINARIES overrides everything, use full -g debug information > ifeq ($(DEBUG_BINARIES), true) > DEBUG_FLAG = -g > CFLAGS_REQUIRED += $(DEBUG_FLAG) > endif OK. > Otherwise it seems fine. > > If you have patch files for each repository (hg diff > patch) I can > run them through our test build system JPRT for you, and send you > the results. Right, will do. Thanks, Andrew. From aph at redhat.com Tue Mar 31 09:50:57 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 Mar 2009 10:50:57 +0100 Subject: OpenJDK 7: mysterious build problem with binary plugs Message-ID: <49D1E781.3030002@redhat.com> This is with jdk-7-ea-plug-b52-linux-x64-26_mar_2009.jar: /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java -Xmx896m -Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/local/openjdk7/jdk7/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar" -jar /local/openjdk7/jdk7/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar -source 1.5 -target 5 -encoding ascii "-Xbootclasspath:/local/openjdk7/jdk7/build/linux-amd64/classes" -XDprocess.packages -proc:only \ -processor com.sun.tools.javac.sym.CreateSymbols \ -Acom.sun.tools.javac.sym.Jar=/local/openjdk7/jdk7/build/linux-amd64/tmp/rt-orig.jar \ -Acom.sun.tools.javac.sym.Dest=/local/openjdk7/jdk7/build/linux-amd64/symbols/META-INF/sym/rt.jar \ java.applet java.awt java.awt.color java.awt.datatransfer java.awt.dnd java.awt.event java.awt.font java.awt.geom java.awt.im java.awt.im.spi java.awt.image java.awt.image.renderable java.awt.print ... warning: package com.sun.java.swing.plaf does not exist Using boot class path = [/local/openjdk7/jdk7/build/linux-amd64/tmp/rt-orig.jar, ... error: com.sun.jmx.snmp.SnmpValue: class file for com.sun.jmx.snmp.SnmpValue not found error: class file for com.sun.jmx.snmp.SnmpValue not found 1 error make[2]: *** [initial-image-jdk] Error 1 make[2]: Leaving directory `/local/openjdk7/jdk7/jdk/make' make[1]: *** [jdk-build] Error 2 make[1]: Leaving directory `/local/openjdk7/jdk7' And indeed, com.sun.jmx.snmp.SnmpValue is not present in openjdk-binary-plugs/jre/lib/rt-closed.jar. Am I the only one to have seen this? Andrew. From Jonathan.Gibbons at Sun.COM Tue Mar 31 12:43:59 2009 From: Jonathan.Gibbons at Sun.COM (Jonathan Gibbons) Date: Tue, 31 Mar 2009 05:43:59 -0700 Subject: OpenJDK 7: mysterious build problem with binary plugs In-Reply-To: <49D1E781.3030002@redhat.com> References: <49D1E781.3030002@redhat.com> Message-ID: <2552D296-CD7D-4F12-A144-2BBC24095F05@sun.com> Andrew, See this response sent by Tim on March 26. -- Jon > Hi Neale: >> I?m trying to build the JDK for the first time. I grabbed the >> sources from the mercurial repository and followed the FAQ to >> perform the build. It builds a heap of stuff before it dies with >> the following: >> error: com.sun.jmx.snmp.SnmpValue: class file for >> com.sun.jmx.snmp.SnmpValue not found >> error: class file for com.sun.jmx.snmp.SnmpValue not found >> The source code for the above class is there but it doesn?t appear >> to be being compiled. Is this a known problem or a newbie mistake >> easily fixed? > > This is bug-id 6819847 "build is broken for OpenJDK with plugs" > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6819847 > > the work around is to define > IMPORT_BINARY_PLUGS=true > > This was an unintended consequence of the fix for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6661448 > > Hope this helps- > > Tim Bell On Mar 31, 2009, at 2:50 AM, Andrew Haley wrote: > This is with jdk-7-ea-plug-b52-linux-x64-26_mar_2009.jar: > > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java -Xmx896m - > Xms128m -XX:PermSize=32m -XX:MaxPermSize=160m "-Xbootclasspath/p:/ > local/openjdk7/jdk7/build/linux-amd64/langtools/dist/bootstrap/lib/ > javac.jar" -jar /local/openjdk7/jdk7/build/linux-amd64/langtools/ > dist/bootstrap/lib/javac.jar -source 1.5 -target 5 -encoding ascii > "-Xbootclasspath:/local/openjdk7/jdk7/build/linux-amd64/classes" - > XDprocess.packages -proc:only \ > -processor com.sun.tools.javac.sym.CreateSymbols \ > -Acom.sun.tools.javac.sym.Jar=/local/openjdk7/jdk7/build/ > linux-amd64/tmp/rt-orig.jar \ > -Acom.sun.tools.javac.sym.Dest=/local/openjdk7/jdk7/build/ > linux-amd64/symbols/META-INF/sym/rt.jar \ > java.applet java.awt java.awt.color java.awt.datatransfer > java.awt.dnd java.awt.event java.awt.font java.awt.geom java.awt.im > java.awt.im.spi java.awt.image java.awt.image.renderable > java.awt.print ... > warning: package com.sun.java.swing.plaf does not exist > Using boot class path = [/local/openjdk7/jdk7/build/linux-amd64/tmp/ > rt-orig.jar, ... > error: com.sun.jmx.snmp.SnmpValue: class file for > com.sun.jmx.snmp.SnmpValue not found > error: class file for com.sun.jmx.snmp.SnmpValue not found > 1 error > make[2]: *** [initial-image-jdk] Error 1 > make[2]: Leaving directory `/local/openjdk7/jdk7/jdk/make' > make[1]: *** [jdk-build] Error 2 > make[1]: Leaving directory `/local/openjdk7/jdk7' > > And indeed, com.sun.jmx.snmp.SnmpValue is not present in > openjdk-binary-plugs/jre/lib/rt-closed.jar. > > Am I the only one to have seen this? > > Andrew. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gnu_andrew at member.fsf.org Tue Mar 31 13:12:30 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 31 Mar 2009 13:12:30 +0000 Subject: OpenJDK 7: mysterious build problem with binary plugs In-Reply-To: <2552D296-CD7D-4F12-A144-2BBC24095F05@sun.com> References: <49D1E781.3030002@redhat.com> <2552D296-CD7D-4F12-A144-2BBC24095F05@sun.com> Message-ID: <17c6771e0903310612p456dd093u5f23583b4c48c315@mail.gmail.com> 2009/3/31 Jonathan Gibbons : > Andrew, > See this response sent by Tim on March 26. > -- Jon > > Hi Neale: > > I?m trying to build the JDK for the first time. I grabbed the sources from > the mercurial repository and followed the FAQ to perform the build. It > builds a heap of stuff before it dies with the following: > > error: com.sun.jmx.snmp.SnmpValue: class file for com.sun.jmx.snmp.SnmpValue > not found > > error: class file for com.sun.jmx.snmp.SnmpValue not found > > The source code for the above class is there but it doesn?t appear to be > being compiled. Is this a known problem or a newbie mistake easily fixed? > > This is bug-id 6819847 "build is broken for OpenJDK with plugs" > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6819847 > > the work around is to define > ?IMPORT_BINARY_PLUGS=true > > This was an unintended consequence of the fix for > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6661448 > > Hope this helps- > > Tim Bell > > > On Mar 31, 2009, at 2:50 AM, Andrew Haley wrote: > > This is with jdk-7-ea-plug-b52-linux-x64-26_mar_2009.jar: > > /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/bin/java ?-Xmx896m -Xms128m > -XX:PermSize=32m -XX:MaxPermSize=160m > "-Xbootclasspath/p:/local/openjdk7/jdk7/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar" > -jar > /local/openjdk7/jdk7/build/linux-amd64/langtools/dist/bootstrap/lib/javac.jar > ?-source 1.5 -target 5 -encoding ascii > "-Xbootclasspath:/local/openjdk7/jdk7/build/linux-amd64/classes" > ?-XDprocess.packages -proc:only \ > ???????????-processor com.sun.tools.javac.sym.CreateSymbols \ > ???????????-Acom.sun.tools.javac.sym.Jar=/local/openjdk7/jdk7/build/linux-amd64/tmp/rt-orig.jar > \ > ???????????-Acom.sun.tools.javac.sym.Dest=/local/openjdk7/jdk7/build/linux-amd64/symbols/META-INF/sym/rt.jar > \ > ???????????java.applet java.awt java.awt.color java.awt.datatransfer > java.awt.dnd java.awt.event java.awt.font java.awt.geom java.awt.im > java.awt.im.spi java.awt.image java.awt.image.renderable java.awt.print ... > warning: package com.sun.java.swing.plaf does not exist > Using boot class path = > [/local/openjdk7/jdk7/build/linux-amd64/tmp/rt-orig.jar, ... > error: com.sun.jmx.snmp.SnmpValue: class file for com.sun.jmx.snmp.SnmpValue > not found > error: class file for com.sun.jmx.snmp.SnmpValue not found > 1 error > make[2]: *** [initial-image-jdk] Error 1 > make[2]: Leaving directory `/local/openjdk7/jdk7/jdk/make' > make[1]: *** [jdk-build] Error 2 > make[1]: Leaving directory `/local/openjdk7/jdk7' > > And indeed, com.sun.jmx.snmp.SnmpValue is not present in > openjdk-binary-plugs/jre/lib/rt-closed.jar. > > Am I the only one to have seen this? > > Andrew. > > > So I take it IMPORT_BINARY_PLUGS is now available in 7? Great! Though that patch was apparently delivered in b53, whereas the last build drop is b51... -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From aph at redhat.com Tue Mar 31 14:13:59 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 Mar 2009 15:13:59 +0100 Subject: Bug 100028 - Debug information is incomplete or missing In-Reply-To: <49CD17C0.9010106@sun.com> References: <49BFB13B.2000602@redhat.com> <49C019BF.6010804@sun.com> <49C0D1E7.6030707@redhat.com> <49CBB205.8040109@redhat.com> <49CD17C0.9010106@sun.com> Message-ID: <49D22527.5010104@redhat.com> Kelly O'Hair wrote: > > Seems ok to me, just a few observations: > > Do we need this: > > ifeq ($(DEBUG_CLASSFILES), true) > ANT_OPTIONS += -Djavac.debug=true > ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars > endif > > to be > > ifeq ($(DEBUG_CLASSFILES), true) > ANT_OPTIONS += -Djavac.debug=true > ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars > else > ANT_OPTIONS += -Djavac.debug=false > ANT_OPTIONS += -Djavac.debuglevel= > endif > > Not sure what happens in ant if a property is not set but used???. Actually, I don't think we do. This would lead to ifeq ($(VARIANT), DBG) ANT_OPTIONS += -Djavac.debug=true else ifeq ($(VARIANT), OPT) ANT_OPTIONS += -Djavac.debug=false endif endif ifeq ($(DEBUG_CLASSFILES), true) ANT_OPTIONS += -Djavac.debug=true ANT_OPTIONS += -Djavac.debuglevel=source,lines,vars else ANT_OPTIONS += -Djavac.debug=false ANT_OPTIONS += -Djavac.debuglevel= endif which would cause javac.debug=false if $(VARIANT) == DBG, wouldn't it? Unless, I supoose, we can guarantee that if $(VARIANT) == DBG then DEBUG_CLASSFILES == true. And the build is such a maze of twisty passages I'm not confident I could swear to that! Andrew. From Tim.Bell at Sun.COM Tue Mar 31 14:15:31 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Tue, 31 Mar 2009 07:15:31 -0700 Subject: [Fwd: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]]] Message-ID: <49D22583.8080804@sun.com> Clearly this review is of interest to a wider audience. This fixes the build problem Jon found and reported as 6819847 Until the fix is approved and pushed, the workaround is to add: IMPORT_BINARY_PLUGS=true to your build environment. Tim -------- Original Message -------- Subject: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]] Date: Tue, 31 Mar 2009 07:08:41 -0700 From: Tim Bell Kelly O'Hair wrote: > I didn't think openjdk7 could build without binary plugs. > But I've been a bit disconnected from the jdk work lately. [... snip ...] > I think I had on my list of things to do: > * Change binary plugs default for openjdk6 to 'not use them' > * Make sure openjdk7 builds without binary plugs > IMPORT_BINARY_PLUGS=false Please take a look at this fix: http://cr.openjdk.java.net/~tbell/6819847/ This implements Kelly's wish "Change binary plugs default for openjdk6 to 'not use them'". Well - for OpenJDK7, it does. I'll have to check, but I think OpenJDK6 is already doing this. This builds OK with OPENJDK=true and: 1) No setting for IMPORT_BINARY_PLUGS at all. This works, and it did NOT import anything. I expect the Linux distros build this way. 2009-03-31-003747.tbell.6819847 2) IMPORT_BINARY_PLUGS=false [Same as 1) above] 2009-03-31-002722.tbell.6819847 3) IMPORT_BINARY_PLUGS=true [PLUG IMPORT successful] 2009-03-31-020718.tbell.6819847 4) Nothing set [nothing imported] 2009-03-31-045710.tbell.6819847 JPRT job-IDs are included here so I could keep track and make sure I looked at the log files. One question - if the user goes to the trouble to set any of ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH (See the comments in jdk/make/common/Defs.gmk starting at line 127), should we assume they must really, really want the binary plugs and force IMPORT_BINARY_PLUGS=true? Or have them set it as well? I am thinking we shouldn't do this automatically. I notice in the logs that JPRT is setting these even when IMPORT_BINARY_PLUGS=false. Otherwise, I think we are covered. Tim From gnu_andrew at member.fsf.org Tue Mar 31 14:32:04 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 31 Mar 2009 14:32:04 +0000 Subject: [Fwd: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]]] In-Reply-To: <49D22583.8080804@sun.com> References: <49D22583.8080804@sun.com> Message-ID: <17c6771e0903310732y2177487fo2f84d64b14be5783@mail.gmail.com> 2009/3/31 Tim Bell : > Clearly this review is of interest to a wider audience. > > This fixes the build problem Jon found and reported as 6819847 > > Until the fix is approved and pushed, the workaround is to add: > > ? IMPORT_BINARY_PLUGS=true > > to your build environment. > Tim > > -------- Original Message -------- > Subject: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx > for OpenJDK.]] > Date: Tue, 31 Mar 2009 07:08:41 -0700 > From: Tim Bell > > Kelly O'Hair wrote: >> >> I didn't think openjdk7 could build without binary plugs. >> But I've been a bit disconnected from the jdk work lately. > I didn't either. The last build I tried using the hotspot-comp tree (to test a patch for twisti) needed pointing at some binary plugs (I use the fake IcedTea ones). And I haven't seen it in any of the recent change lists for 7 (http://download.java.net/jdk7/changes/jdk7-b50.html, http://download.java.net/jdk7/changes/jdk7-b51.html) > [... snip ...] > >> I think I had on my list of things to do: >> ?* Change binary plugs default for openjdk6 to 'not use them' >> ?* Make sure openjdk7 builds without binary plugs >> IMPORT_BINARY_PLUGS=false > > Please take a look at this fix: > > ? http://cr.openjdk.java.net/~tbell/6819847/ > > This implements Kelly's wish "Change binary plugs default for openjdk6 > to 'not use them'". ?Well - for OpenJDK7, it does. ?I'll have to check, > but I think OpenJDK6 is already doing this. > I think Dalibor committed this change to 6. It's a lot less controversial there, as the option has been available a long time, just not the default. > This builds OK with OPENJDK=true and: > Is this the default? I assume OPENJDK=false is only useful inside Sun. > 1) No setting for IMPORT_BINARY_PLUGS at all. ?This works, and it > did NOT import anything. ?I expect the Linux distros build this way. > ? 2009-03-31-003747.tbell.6819847 > Well the distros don't build 7 as far as I know, and I believe the last OpenJDK6 build drop still used by IcedTea6 (the one before the switch to hg) still uses fake plugs. Whether it needs to or not is another matter; I think it does because the default for b14 is to import them (IMPORT_BINARY_PLUGS=true) and we don't set IMPORT_BINARY_PLUGS. I never understood why IMPORT_BINARY_PLUGS was defaulted to true for 6, as the audience building 'raw' OpenJDK6 (i.e. not via IcedTea6) who want SNMP must be negligible enough to warrant not being the default. > 2) IMPORT_BINARY_PLUGS=false ?[Same as 1) above] > ? 2009-03-31-002722.tbell.6819847 > > 3) IMPORT_BINARY_PLUGS=true ? [PLUG IMPORT successful] > ? 2009-03-31-020718.tbell.6819847 > > 4) Nothing set ?[nothing imported] > ? 2009-03-31-045710.tbell.6819847 > I'm guessing all these are too recent to be in a build drop yet. > > JPRT job-IDs are included here so I could keep track and make sure I > looked at the log files. > > One question - if the user goes to the trouble to set any of > ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, > ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH > (See the comments in jdk/make/common/Defs.gmk starting at line 127), > should we assume they must really, really want the binary plugs and > force IMPORT_BINARY_PLUGS=true? ?Or have them set it as well? > I think that's a fair assumption, as long as you can be sure they did set it and it didn't default to something. > I am thinking we shouldn't do this automatically. ?I notice in the logs > that JPRT is setting these even when IMPORT_BINARY_PLUGS=false. > > Otherwise, I think we are covered. > > Tim > > Really good to see this going in, Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Tim.Bell at Sun.COM Tue Mar 31 15:06:31 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Tue, 31 Mar 2009 08:06:31 -0700 Subject: [Fwd: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]]] In-Reply-To: <17c6771e0903310732y2177487fo2f84d64b14be5783@mail.gmail.com> References: <49D22583.8080804@sun.com> <17c6771e0903310732y2177487fo2f84d64b14be5783@mail.gmail.com> Message-ID: <49D23177.5060805@sun.com> >> Kelly O'Hair wrote: >>> I didn't think openjdk7 could build without binary plugs. >>> But I've been a bit disconnected from the jdk work lately. Andrew John Hughes wrote: > I didn't either. The last build I tried using the hotspot-comp tree > (to test a patch for twisti) needed pointing at some binary plugs (I > use the fake IcedTea ones). And I haven't seen it in any of the > recent change lists for 7 > (http://download.java.net/jdk7/changes/jdk7-b50.html, > http://download.java.net/jdk7/changes/jdk7-b51.html) Correct, it wouldn't be in there yet. >> [... snip ...] >> >>> I think I had on my list of things to do: >>> * Change binary plugs default for openjdk6 to 'not use them' >>> * Make sure openjdk7 builds without binary plugs >>> IMPORT_BINARY_PLUGS=false >> Please take a look at this fix: >> >> http://cr.openjdk.java.net/~tbell/6819847/ >> >> This implements Kelly's wish "Change binary plugs default for openjdk6 >> to 'not use them'". Well - for OpenJDK7, it does. I'll have to check, >> but I think OpenJDK6 is already doing this. >> > > I think Dalibor committed this change to 6. It's a lot less > controversial there, as the option has been available a long time, > just not the default. > >> This builds OK with OPENJDK=true and: >> > > Is this the default? I assume OPENJDK=false is only useful inside Sun. Yes, that is correct. Since the settings are possible I went ahead and tested to make sure they work. If the build discovers only the open part of the forest then it will effectively be an OPENJDK=TRUE build. >> 1) No setting for IMPORT_BINARY_PLUGS at all. This works, and it >> did NOT import anything. I expect the Linux distros build this way. >> 2009-03-31-003747.tbell.6819847 >> > > Well the distros don't build 7 as far as I know, and I believe the > last OpenJDK6 build drop still used by IcedTea6 (the one before the > switch to hg) still uses fake plugs. Whether it needs to or not is > another matter; I think it does because the default for b14 is to > import them (IMPORT_BINARY_PLUGS=true) and we don't set > IMPORT_BINARY_PLUGS. I never understood why IMPORT_BINARY_PLUGS was > defaulted to true for 6, as the audience building 'raw' OpenJDK6 (i.e. > not via IcedTea6) who want SNMP must be negligible enough to warrant > not being the default. This default setting could go back to earlier days when there was a lot more in the binary plugs. >> 2) IMPORT_BINARY_PLUGS=false [Same as 1) above] >> 2009-03-31-002722.tbell.6819847 >> >> 3) IMPORT_BINARY_PLUGS=true [PLUG IMPORT successful] >> 2009-03-31-020718.tbell.6819847 >> >> 4) Nothing set [nothing imported] >> 2009-03-31-045710.tbell.6819847 >> > > I'm guessing all these are too recent to be in a build drop yet. Yes. This work is from yesterday/last night. >> JPRT job-IDs are included here so I could keep track and make sure I >> looked at the log files. >> >> One question - if the user goes to the trouble to set any of >> ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, >> ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH >> (See the comments in jdk/make/common/Defs.gmk starting at line 127), >> should we assume they must really, really want the binary plugs and >> force IMPORT_BINARY_PLUGS=true? Or have them set it as well? >> > > I think that's a fair assumption, as long as you can be sure they did > set it and it didn't default to something. OK, thanks. I already have other feedback that we should do this to preserve the current build behavior. >> I am thinking we shouldn't do this automatically. I notice in the logs >> that JPRT is setting these even when IMPORT_BINARY_PLUGS=false. Then we may need to change this in JPRT. I am still checking on that. Thanks for the feedback. Tim From gnu_andrew at member.fsf.org Tue Mar 31 15:19:32 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 31 Mar 2009 15:19:32 +0000 Subject: [Fwd: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]]] In-Reply-To: <49D23177.5060805@sun.com> References: <49D22583.8080804@sun.com> <17c6771e0903310732y2177487fo2f84d64b14be5783@mail.gmail.com> <49D23177.5060805@sun.com> Message-ID: <17c6771e0903310819m34a8379cya6e408b200f4127a@mail.gmail.com> 2009/3/31 Tim Bell : > > >>> Kelly O'Hair wrote: >>>> >>>> I didn't think openjdk7 could build without binary plugs. >>>> But I've been a bit disconnected from the jdk work lately. > > Andrew John Hughes wrote: > >> I didn't either. ?The last build I tried using the hotspot-comp tree >> (to test a patch for twisti) needed pointing at some binary plugs (I >> use the fake IcedTea ones). ?And I haven't seen it in any of the >> recent change lists for 7 >> (http://download.java.net/jdk7/changes/jdk7-b50.html, >> http://download.java.net/jdk7/changes/jdk7-b51.html) > > Correct, it wouldn't be in there yet. > True: ERROR: Can't locate pre-built libraries. Please check your access to /NOT-SET/re/jdk/1.7.0/promoted/latest/openjdk/binaryplugs/linux-amd64 and/or check your value of ALT_BINARY_PLUGS_PATH. Good to know it is in the queue though, as I was going to start porting it over myself. I was confused because this was suggested as a solution to an issue with the binary plugs not working, but it doesn't seem to really be 'in the wild' yet. >>> [... snip ...] >>> >>>> I think I had on my list of things to do: >>>> ?* Change binary plugs default for openjdk6 to 'not use them' >>>> ?* Make sure openjdk7 builds without binary plugs >>>> IMPORT_BINARY_PLUGS=false >>> >>> Please take a look at this fix: >>> >>> ?http://cr.openjdk.java.net/~tbell/6819847/ >>> >>> This implements Kelly's wish "Change binary plugs default for openjdk6 >>> to 'not use them'". ?Well - for OpenJDK7, it does. ?I'll have to check, >>> but I think OpenJDK6 is already doing this. >>> >> >> I think Dalibor committed this change to 6. ?It's a lot less >> controversial there, as the option has been available a long time, >> just not the default. >> >>> This builds OK with OPENJDK=true and: >>> >> >> Is this the default? I assume OPENJDK=false is only useful inside Sun. > > Yes, that is correct. ?Since the settings are possible I went ahead and > tested to make sure they work. ?If the build discovers only the open part of > the forest then it will effectively be an OPENJDK=TRUE build. > Confirmed. I get OPENJDK=true without specifying it explicitly. >>> 1) No setting for IMPORT_BINARY_PLUGS at all. ?This works, and it >>> did NOT import anything. ?I expect the Linux distros build this way. >>> ?2009-03-31-003747.tbell.6819847 >>> >> >> Well the distros don't build 7 as far as I know, and I believe the >> last OpenJDK6 build drop still used by IcedTea6 (the one before the >> switch to hg) still uses fake plugs. ?Whether it needs to or not is >> another matter; I think it does because the default for b14 is to >> import them (IMPORT_BINARY_PLUGS=true) and we don't set >> IMPORT_BINARY_PLUGS. I never understood why IMPORT_BINARY_PLUGS was >> defaulted to true for 6, as the audience building 'raw' OpenJDK6 (i.e. >> not via IcedTea6) who want SNMP must be negligible enough to warrant >> not being the default. > > This default setting could go back to earlier days when there was a lot more > in the binary plugs. That's true for 7, but I believe it was only introduced when we were already down to just SNMP. But I may have misremembered. > >>> 2) IMPORT_BINARY_PLUGS=false ?[Same as 1) above] >>> ?2009-03-31-002722.tbell.6819847 >>> >>> 3) IMPORT_BINARY_PLUGS=true ? [PLUG IMPORT successful] >>> ?2009-03-31-020718.tbell.6819847 >>> >>> 4) Nothing set ?[nothing imported] >>> ?2009-03-31-045710.tbell.6819847 >>> >> >> I'm guessing all these are too recent to be in a build drop yet. > > Yes. ?This work is from yesterday/last night. > >>> JPRT job-IDs are included here so I could keep track and make sure I >>> looked at the log files. >>> >>> One question - if the user goes to the trouble to set any of >>> ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, >>> ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH >>> (See the comments in jdk/make/common/Defs.gmk starting at line 127), >>> should we assume they must really, really want the binary plugs and >>> force IMPORT_BINARY_PLUGS=true? ?Or have them set it as well? >>> >> >> I think that's a fair assumption, as long as you can be sure they did >> set it and it didn't default to something. > > OK, thanks. ?I already have other feedback that we should do this to > preserve the current build behavior. > >>> I am thinking we shouldn't do this automatically. ?I notice in the logs >>> that JPRT is setting these even when IMPORT_BINARY_PLUGS=false. > > Then we may need to change this in JPRT. ?I am still checking on that. > > Thanks for the feedback. > > Tim > Thanks, -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From neale at sinenomine.net Tue Mar 31 15:19:55 2009 From: neale at sinenomine.net (Neale Ferguson) Date: Tue, 31 Mar 2009 11:19:55 -0400 Subject: Problems building on System z Message-ID: I?m building the OpenJDK6 & 7 by way of the zeroJDK mechanism and am running into problems. Using gij with icedtea6 I get: + CLASSPATH=/home/neale/ecj-3.4.1.jar + /usr/bin/gij org.eclipse.jdt.internal.compiler.batch.Main -1.5 -nowarn -g -d lib/hotspot-tools -source 1.5 -sourcepath hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes: openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/c orba/src/share/classes:openjdk/jaxws/src/share/classes:/home/neale/icedtea6- 1.4.1/generated:/home/neale/icedtea6-1.4.1/rt -bootclasspath ''\'''\''' @hotspot-tools-source-files.txt incorrect classpath: '' ---------- 1. ERROR in /home/neale/icedtea6-1.4.1/openjdk/jdk/src/share/classes/java/lang/Double.ja va (at line 0) /* ^ Internal compiler error java.lang.NullPointerException at java.lang.Double.parseDouble(libgcj.so.7) at java.lang.Double.valueOf(libgcj.so.7) Using gij with icedtea9 I get: /usr/bin/gcj -g -O2 -Wl,-Bsymbolic -findirect-dispatch -o native-ecj \ --main=org.eclipse.jdt.internal.compiler.batch.Main /home/neale/ecj-3.4.1.jar org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java: In class 'org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorMana ger': org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java: In method 'org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorMana ger.discoverNextProcessor()': org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java:110: error: verification failed at PC=251: String, int, or float constant expected org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java:110: error: verification failed at PC=260: incompatible type on stack org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag er.java:152: confused by earlier errors, bailing out This is with gcc 4.1.2 should I be using a later version? When I use the IBM 1.6 JDK with icedtea6 I get: [mkdir] Created dir: /home/neale/icedtea6-1.4.1/openjdk-ecj/control/build/linux-s390x/langtools/b uild/toolclasses [javac] Compiling 2 source files to /home/neale/icedtea6-1.4.1/openjdk-ecj/control/build/linux-s390x/langtools/b uild/toolclasses [javac] ---------- [javac] 1. ERROR in /home/neale/icedtea6-1.4.1/openjdk-ecj/langtools/make/tools/CompilePropertie s/CompileProperties.java (at line 1) [javac] /* [javac] ^ [javac] The type java.lang.Object cannot be resolved. It is indirectly referenced from required .class files [javac] ---------- [javac] 2. ERROR in /home/neale/icedtea6-1.4.1/openjdk-ecj/langtools/make/tools/CompilePropertie s/CompileProperties.java (at line 1) [javac] /* [javac] ^ [javac] The type java.lang.String cannot be resolved. It is indirectly referenced from required .class files [javac] ---------- : : For a total of 100 errors. For icedtea9 I got exactly the same results. Does any of this look familiar to anyone? Also, when using the JDK I have build problems with both 6 & 9: make[2]: Entering directory `/home/neale/icedtea6-1.4.1/openjdk-ecj/jdk/make' common/Release.gmk:662: Extraneous text after `else' directive common/Release.gmk:664: *** only one `else' per conditional. Stop. And after fixing that I get with 6... common/Release.gmk:731: Extraneous text after `else' directive common/Release.gmk:735: *** only one `else' per conditional. Stop. Which is also easily fixed. Neale -------------- next part -------------- An HTML attachment was scrubbed... URL: From Tim.Bell at Sun.COM Tue Mar 31 15:44:05 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Tue, 31 Mar 2009 08:44:05 -0700 Subject: [Fwd: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]]] In-Reply-To: <17c6771e0903310819m34a8379cya6e408b200f4127a@mail.gmail.com> References: <49D22583.8080804@sun.com> <17c6771e0903310732y2177487fo2f84d64b14be5783@mail.gmail.com> <49D23177.5060805@sun.com> <17c6771e0903310819m34a8379cya6e408b200f4127a@mail.gmail.com> Message-ID: <49D23A45.2040307@sun.com> Andrew John Hughes wrote: > ERROR: Can't locate pre-built libraries. > Please check your access to > /NOT-SET/re/jdk/1.7.0/promoted/latest/openjdk/binaryplugs/linux-amd64 > and/or check your value of ALT_BINARY_PLUGS_PATH. > > Good to know it is in the queue though, as I was going to start > porting it over myself. > > I was confused because this was suggested as a solution to an issue > with the binary plugs not working, but it doesn't seem to really be > 'in the wild' yet. Looks like you set IMPORT_BINARY_PLUGS=true as stated in the workaround, so the build tried to reach for the plugs in the default location. You also need to set ALT_BINARY_PLUGS_PATH to point to the plugs you want to use. Sorry about that - I will update the Workaround on the bug report. Tim From gnu_andrew at member.fsf.org Tue Mar 31 16:49:01 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 31 Mar 2009 16:49:01 +0000 Subject: [Fwd: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]]] In-Reply-To: <49D23A45.2040307@sun.com> References: <49D22583.8080804@sun.com> <17c6771e0903310732y2177487fo2f84d64b14be5783@mail.gmail.com> <49D23177.5060805@sun.com> <17c6771e0903310819m34a8379cya6e408b200f4127a@mail.gmail.com> <49D23A45.2040307@sun.com> Message-ID: <17c6771e0903310949n359d785aj6ab6c0ae26762784@mail.gmail.com> 2009/3/31 Tim Bell : > Andrew John Hughes wrote: > >> ERROR: Can't locate pre-built libraries. >> ? ? ? Please check your access to >> >> /NOT-SET/re/jdk/1.7.0/promoted/latest/openjdk/binaryplugs/linux-amd64 >> ? ? ? and/or check your value of ALT_BINARY_PLUGS_PATH. >> >> Good to know it is in the queue though, as I was going to start >> porting it over myself. >> >> I was confused because this was suggested as a solution to an issue >> with the binary plugs not working, but it doesn't seem to really be >> 'in the wild' yet. > > Looks like you set ?IMPORT_BINARY_PLUGS=true as stated in the workaround, so > the build tried to reach for the plugs in the default location. > > You also need to set ALT_BINARY_PLUGS_PATH to point to the plugs you want to > use. > > Sorry about that - I will update the Workaround on the bug report. > > Tim > In the IcedTea7 build, we simply delete the SNMP hooks with a few rm invocations and a Makefile patch. Once b53 appears with IMPORT_BINARY_PLUGS=false, we'll switch to that. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From aph at redhat.com Tue Mar 31 17:48:18 2009 From: aph at redhat.com (Andrew Haley) Date: Tue, 31 Mar 2009 18:48:18 +0100 Subject: Problems building on System z In-Reply-To: References: Message-ID: <49D25762.5060703@redhat.com> Neale Ferguson wrote: > I?m building the OpenJDK6 & 7 by way of the zeroJDK mechanism and am running > into problems. > > Using gij with icedtea6 I get: > > + CLASSPATH=/home/neale/ecj-3.4.1.jar > + /usr/bin/gij org.eclipse.jdt.internal.compiler.batch.Main -1.5 -nowarn -g > -d lib/hotspot-tools -source 1.5 -sourcepath > hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes: > openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/c > orba/src/share/classes:openjdk/jaxws/src/share/classes:/home/neale/icedtea6- > 1.4.1/generated:/home/neale/icedtea6-1.4.1/rt -bootclasspath ''\'''\''' > @hotspot-tools-source-files.txt > incorrect classpath: '' > ---------- > 1. ERROR in > /home/neale/icedtea6-1.4.1/openjdk/jdk/src/share/classes/java/lang/Double.ja > va (at line 0) > /* > ^ > Internal compiler error > java.lang.NullPointerException > at java.lang.Double.parseDouble(libgcj.so.7) > at java.lang.Double.valueOf(libgcj.so.7) OK, looks like your gcj is broken. Strange: people have successfully built OpenJDK using gcj on such systems. > Using gij with icedtea9 I get: icedtea7, right? > /usr/bin/gcj -g -O2 -Wl,-Bsymbolic -findirect-dispatch -o native-ecj \ > --main=org.eclipse.jdt.internal.compiler.batch.Main > /home/neale/ecj-3.4.1.jar > org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag > er.java: In class > 'org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorMana > ger': > org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag > er.java: In method > 'org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorMana > ger.discoverNextProcessor()': > org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag > er.java:110: error: verification failed at PC=251: String, int, or float > constant expected > org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag > er.java:110: error: verification failed at PC=260: incompatible type on > stack > org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag > er.java:152: confused by earlier errors, bailing out > > This is with gcc 4.1.2 should I be using a later version? I would. It looks to me like the gcj you have installed doesn't work at all. I'm trying to find out who actually did the System z port of OpenJDK to Fedora. Andrew. From gnu_andrew at member.fsf.org Tue Mar 31 18:01:26 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 31 Mar 2009 18:01:26 +0000 Subject: Problems building on System z In-Reply-To: <49D25762.5060703@redhat.com> References: <49D25762.5060703@redhat.com> Message-ID: <17c6771e0903311101g1338119eo533a4d2b9fddc042@mail.gmail.com> 2009/3/31 Andrew Haley : > Neale Ferguson wrote: >> I?m building the OpenJDK6 & 7 by way of the zeroJDK mechanism and am running >> into problems. >> >> Using gij with icedtea6 I get: >> >> + CLASSPATH=/home/neale/ecj-3.4.1.jar >> + /usr/bin/gij org.eclipse.jdt.internal.compiler.batch.Main -1.5 -nowarn -g >> -d lib/hotspot-tools -source 1.5 -sourcepath >> hotspot-tools:openjdk/jdk/src/share/classes:openjdk/jdk/src/solaris/classes: >> openjdk/langtools/src/share/classes:openjdk/jaxp/src/share/classes:openjdk/c >> orba/src/share/classes:openjdk/jaxws/src/share/classes:/home/neale/icedtea6- >> 1.4.1/generated:/home/neale/icedtea6-1.4.1/rt -bootclasspath ''\'''\''' >> @hotspot-tools-source-files.txt >> incorrect classpath: '' >> ---------- >> 1. ERROR in >> /home/neale/icedtea6-1.4.1/openjdk/jdk/src/share/classes/java/lang/Double.ja >> va (at line 0) >> ? ? /* >> ? ? ^ >> Internal compiler error >> java.lang.NullPointerException >> ? ?at java.lang.Double.parseDouble(libgcj.so.7) >> ? ?at java.lang.Double.valueOf(libgcj.so.7) > > OK, looks like your gcj is broken. ?Strange: people have successfully built > OpenJDK using gcj on such systems. > >> Using gij with icedtea9 I get: > > icedtea7, right? > >> /usr/bin/gcj -g -O2 -Wl,-Bsymbolic -findirect-dispatch -o native-ecj \ >> ? ? --main=org.eclipse.jdt.internal.compiler.batch.Main >> /home/neale/ecj-3.4.1.jar >> org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag >> er.java: In class >> 'org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorMana >> ger': >> org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag >> er.java: In method >> 'org.eclipse.jdt.internal.compiler.apt.dispatch.BatchAnnotationProcessorMana >> ger.discoverNextProcessor()': >> org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag >> er.java:110: error: verification failed at PC=251: String, int, or float >> constant expected >> org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag >> er.java:110: error: verification failed at PC=260: incompatible type on >> stack >> org/eclipse/jdt/internal/compiler/apt/dispatch/BatchAnnotationProcessorManag >> er.java:152: confused by earlier errors, bailing out >> >> This is with gcc 4.1.2 should I be using a later version? > > I would. ?It looks to me like the gcj you have installed doesn't work at all. > > I'm trying to find out who actually did the System z port of OpenJDK to Fedora. > > Andrew. > > > The gcj from 4.1.2 is going to be very old; you need at least 4.3.x really. That's true even for the more mainstream platforms. Which version of IcedTea7 are you using? The creation of a native ecj hasn't been the default for a while, it's controlled by the --with/without-gcj option. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Tim.Bell at Sun.COM Tue Mar 31 20:26:50 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Tue, 31 Mar 2009 13:26:50 -0700 Subject: Round two Re: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]] In-Reply-To: <49D223E9.1050609@sun.com> References: <49C2AE84.3080709@sun.com> <49C2B8B5.9020305@sun.com> <49C2BDD6.2020602@sun.com> <49C36D66.9050203@sun.com> <49C3D5F1.30206@sun.com> <49D223E9.1050609@sun.com> Message-ID: <49D27C8A.7050304@sun.com> I wrote: > One question - if the user goes to the trouble to set any of > ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, > ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH > (See the comments in jdk/make/common/Defs.gmk starting at line 127), > should we assume they must really, really want the binary plugs and > force IMPORT_BINARY_PLUGS=true? Or have them set it as well? > I am thinking we shouldn't do this automatically. I notice in the logs > that JPRT is setting these even when IMPORT_BINARY_PLUGS=false. Review feedback convinced me to reverse that last statement. Here is round two - please take a look: http://cr.openjdk.java.net/~tbell/6819847/webrev.01/ With these changes the default behavior is as if IMPORT_BINARY_PLUGS=false Unless the user explicitly sets any of the PLUGS variables: ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH Setting these will force IMPORT_BINARY_PLUGS=true The other case is if a user outside the Sun network sets IMPORT_BINARY_PLUGS=true. Here they will need to set one of the ALT_..._BINARY_PLUGS variables to point to the plugs anyway. Thanks in advance for feedback- Tim Bell From gnu_andrew at member.fsf.org Tue Mar 31 20:29:10 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 31 Mar 2009 20:29:10 +0000 Subject: Round two Re: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]] In-Reply-To: <49D27C8A.7050304@sun.com> References: <49C2AE84.3080709@sun.com> <49C2B8B5.9020305@sun.com> <49C2BDD6.2020602@sun.com> <49C36D66.9050203@sun.com> <49C3D5F1.30206@sun.com> <49D223E9.1050609@sun.com> <49D27C8A.7050304@sun.com> Message-ID: <17c6771e0903311329j7e910aabu339598fb76a9d26b@mail.gmail.com> 2009/3/31 Tim Bell : > I wrote: > >> One question - if the user goes to the trouble to set any of >> ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, >> ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH >> (See the comments in jdk/make/common/Defs.gmk starting at line 127), >> should we assume they must really, really want the binary plugs and force >> IMPORT_BINARY_PLUGS=true? ?Or have them set it as well? > > >> I am thinking we shouldn't do this automatically. ?I notice in the logs >> that JPRT is setting these even when IMPORT_BINARY_PLUGS=false. > > Review feedback convinced me to reverse that last statement. > > Here is round two - please take a look: > > ?http://cr.openjdk.java.net/~tbell/6819847/webrev.01/ > > With these changes the default behavior is as if IMPORT_BINARY_PLUGS=false > > Unless the user explicitly sets any of the PLUGS variables: > ?ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, > ?ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH > > Setting these will force IMPORT_BINARY_PLUGS=true > > The other case is if a user outside the Sun network sets > IMPORT_BINARY_PLUGS=true. ?Here they will need to set one of the > ALT_..._BINARY_PLUGS variables to point to the plugs anyway. > That suggests to me that outside Sun, there is no need for IMPORT_BINARY_PLUGS at all (i.e. its value is implied by the presence of one of the path variables). However, I assume it is needed inside Sun, for whatever reason. > Thanks in advance for feedback- > > Tim Bell > -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From Dalibor.Topic at Sun.COM Tue Mar 31 20:30:21 2009 From: Dalibor.Topic at Sun.COM (Dalibor Topic) Date: Tue, 31 Mar 2009 22:30:21 +0200 Subject: Round two Re: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]] In-Reply-To: <49D27C8A.7050304@sun.com> References: <49C2AE84.3080709@sun.com> <49C2B8B5.9020305@sun.com> <49C2BDD6.2020602@sun.com> <49C36D66.9050203@sun.com> <49C3D5F1.30206@sun.com> <49D223E9.1050609@sun.com> <49D27C8A.7050304@sun.com> Message-ID: <49D27D5D.6060400@sun.com> Tim Bell wrote: > Review feedback convinced me to reverse that last statement. > > Here is round two - please take a look: > > http://cr.openjdk.java.net/~tbell/6819847/webrev.01/ > > With these changes the default behavior is as if IMPORT_BINARY_PLUGS=false Thanks Tim, the change looks good to me. > Unless the user explicitly sets any of the PLUGS variables: > ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, > ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH > > Setting these will force IMPORT_BINARY_PLUGS=true Nice catch. I like the bit making the binary plugs check optional, too. cheers, dalibor topic -- ******************************************************************* Dalibor Topic Tel: (+49 40) 23 646 738 Java F/OSS Ambassador AIM: robiladonaim Sun Microsystems GmbH Mobile: (+49 177) 2664 192 Nagelsweg 55 http://openjdk.java.net D-20097 Hamburg mailto:Dalibor.Topic at sun.com Sitz der Gesellschaft: Sonnenallee 1, D-85551 Kirchheim-Heimstetten Amtsgericht M?nchen: HRB 161028 Gesch?ftsf?hrer: Thomas Schr?der, Wolfgang Engels, Dr. Roland B?mer Vorsitzender des Aufsichtsrates: Martin H?ring From Tim.Bell at Sun.COM Tue Mar 31 20:42:51 2009 From: Tim.Bell at Sun.COM (Tim Bell) Date: Tue, 31 Mar 2009 13:42:51 -0700 Subject: Round two Re: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]] In-Reply-To: <17c6771e0903311329j7e910aabu339598fb76a9d26b@mail.gmail.com> References: <49C2AE84.3080709@sun.com> <49C2B8B5.9020305@sun.com> <49C2BDD6.2020602@sun.com> <49C36D66.9050203@sun.com> <49C3D5F1.30206@sun.com> <49D223E9.1050609@sun.com> <49D27C8A.7050304@sun.com> <17c6771e0903311329j7e910aabu339598fb76a9d26b@mail.gmail.com> Message-ID: <49D2804B.2080700@sun.com> I wrote: >> The other case is if a user outside the Sun network sets >> IMPORT_BINARY_PLUGS=true. Here they will need to set one of the >> ALT_..._BINARY_PLUGS variables to point to the plugs anyway. Andrew John Hughes wrote: > That suggests to me that outside Sun, there is no need for > IMPORT_BINARY_PLUGS at all (i.e. its value is implied by the presence > of one of the path variables). However, I assume it is needed inside > Sun, for whatever reason. That is correct. Hopefully we can remove all of this someday. Tim From Joe.Darcy at Sun.COM Tue Mar 31 20:56:20 2009 From: Joe.Darcy at Sun.COM (Joe Darcy) Date: Tue, 31 Mar 2009 13:56:20 -0700 Subject: Round two Re: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]] In-Reply-To: <17c6771e0903311329j7e910aabu339598fb76a9d26b@mail.gmail.com> References: <49C2AE84.3080709@sun.com> <49C2B8B5.9020305@sun.com> <49C2BDD6.2020602@sun.com> <49C36D66.9050203@sun.com> <49C3D5F1.30206@sun.com> <49D223E9.1050609@sun.com> <49D27C8A.7050304@sun.com> <17c6771e0903311329j7e910aabu339598fb76a9d26b@mail.gmail.com> Message-ID: <49D28374.1030007@sun.com> Andrew John Hughes wrote: > 2009/3/31 Tim Bell : >> I wrote: >> >>> One question - if the user goes to the trouble to set any of >>> ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, >>> ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH >>> (See the comments in jdk/make/common/Defs.gmk starting at line 127), >>> should we assume they must really, really want the binary plugs and force >>> IMPORT_BINARY_PLUGS=true? Or have them set it as well? >> >>> I am thinking we shouldn't do this automatically. I notice in the logs >>> that JPRT is setting these even when IMPORT_BINARY_PLUGS=false. >> Review feedback convinced me to reverse that last statement. >> >> Here is round two - please take a look: >> >> http://cr.openjdk.java.net/~tbell/6819847/webrev.01/ >> >> With these changes the default behavior is as if IMPORT_BINARY_PLUGS=false >> >> Unless the user explicitly sets any of the PLUGS variables: >> ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, >> ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH >> >> Setting these will force IMPORT_BINARY_PLUGS=true >> >> The other case is if a user outside the Sun network sets >> IMPORT_BINARY_PLUGS=true. Here they will need to set one of the >> ALT_..._BINARY_PLUGS variables to point to the plugs anyway. >> > > That suggests to me that outside Sun, there is no need for > IMPORT_BINARY_PLUGS at all (i.e. its value is implied by the presence > of one of the path variables). However, I assume it is needed inside > Sun, for whatever reason. The only remaining need for the plugs in either OpenJDK 6 or 7 is for SNMP functionality. If there was an open source replacement of that code, the plugs could go away altogether. -Joe From gnu_andrew at member.fsf.org Tue Mar 31 21:27:51 2009 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 31 Mar 2009 21:27:51 +0000 Subject: Round two Re: Please review fix for 6819847 [Re: [Fwd: Problems with building jmx for OpenJDK.]] In-Reply-To: <49D28374.1030007@sun.com> References: <49C2AE84.3080709@sun.com> <49C2B8B5.9020305@sun.com> <49C2BDD6.2020602@sun.com> <49C36D66.9050203@sun.com> <49C3D5F1.30206@sun.com> <49D223E9.1050609@sun.com> <49D27C8A.7050304@sun.com> <17c6771e0903311329j7e910aabu339598fb76a9d26b@mail.gmail.com> <49D28374.1030007@sun.com> Message-ID: <17c6771e0903311427r56228266nac953a4ead6e6ad9@mail.gmail.com> 2009/3/31 Joe Darcy : > Andrew John Hughes wrote: >> >> 2009/3/31 Tim Bell : >>> >>> I wrote: >>> >>>> One question - if the user goes to the trouble to set any of >>>> ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, >>>> ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH >>>> (See the comments in jdk/make/common/Defs.gmk starting at line 127), >>>> should we assume they must really, really want the binary plugs and >>>> force >>>> IMPORT_BINARY_PLUGS=true? ?Or have them set it as well? >>> >>>> I am thinking we shouldn't do this automatically. ?I notice in the logs >>>> that JPRT is setting these even when IMPORT_BINARY_PLUGS=false. >>> >>> Review feedback convinced me to reverse that last statement. >>> >>> Here is round two - please take a look: >>> >>> ?http://cr.openjdk.java.net/~tbell/6819847/webrev.01/ >>> >>> With these changes the default behavior is as if >>> IMPORT_BINARY_PLUGS=false >>> >>> Unless the user explicitly sets any of the PLUGS variables: >>> ?ALT_BINARY_PLUGS_JARFILE, ALT_BINARY_PLUGS_PATH, >>> ?ALT_BUILD_BINARY_PLUGS_PATH, ALT_CLOSED_JDK_IMPORT_PATH >>> >>> Setting these will force IMPORT_BINARY_PLUGS=true >>> >>> The other case is if a user outside the Sun network sets >>> IMPORT_BINARY_PLUGS=true. ?Here they will need to set one of the >>> ALT_..._BINARY_PLUGS variables to point to the plugs anyway. >>> >> >> That suggests to me that outside Sun, there is no need for >> IMPORT_BINARY_PLUGS at all (i.e. its value is implied by the presence >> of one of the path variables). ?However, I assume it is needed inside >> Sun, for whatever reason. > > The only remaining need for the plugs in either OpenJDK 6 or 7 is for SNMP > functionality. ?If there was an open source replacement of that code, the > plugs could go away altogether. > > -Joe > Are there some applications that use this? Are there test cases? At present, all we have to go on for writing a replacement are the API calls made by the code in OpenJDK. -- Andrew :-) Free Java Software Engineer Red Hat, Inc. (http://www.redhat.com) Support Free Java! Contribute to GNU Classpath and the OpenJDK http://www.gnu.org/software/classpath http://openjdk.java.net PGP Key: 94EFD9D8 (http://subkeys.pgp.net) Fingerprint: F8EF F1EA 401E 2E60 15FA 7927 142C 2591 94EF D9D8 From tim.bell at sun.com Tue Mar 31 22:32:21 2009 From: tim.bell at sun.com (tim.bell at sun.com) Date: Tue, 31 Mar 2009 22:32:21 +0000 Subject: hg: jdk7/build/jdk: 6819847: build is broken for OpenJDK with plugs Message-ID: <20090331223249.E053BEDED@hg.openjdk.java.net> Changeset: 964cc8eb3232 Author: tbell Date: 2009-03-31 15:27 -0700 URL: http://hg.openjdk.java.net/jdk7/build/jdk/rev/964cc8eb3232 6819847: build is broken for OpenJDK with plugs Reviewed-by: jjg, robilad, ohair ! make/Makefile ! make/common/Defs.gmk ! make/common/shared/Sanity-Settings.gmk ! make/java/redist/Makefile