From gnu_andrew at member.fsf.org Tue Jul 1 06:17:53 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 1 Jul 2008 14:17:53 +0100 Subject: FYI: Another distcheck fix Message-ID: <20080701131753.GA24688@rivendell.middle-earth.co.uk> This fixes the path to jtreg.jar. Hopefully the tests will now run... ChangeLog: 2008-07-01 Andrew John Hughes * Makefile.am: Move new aliases to end with others, and fix path of jtreg.jar. * Makefile.in: Regenerated. -- Andrew :) 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 -------------- next part -------------- diff -r 4cad9bad13c5 Makefile.am --- a/Makefile.am Tue Jul 01 14:31:40 2008 +0200 +++ b/Makefile.am Tue Jul 01 14:15:35 2008 +0100 @@ -714,7 +714,6 @@ endif # If you change anything here in the icedtea target, please make sure # you change it in the icedtea-debug target as well. -icedtea: stamps/icedtea.stamp stamps/icedtea.stamp: stamps/bootstrap-directory-symlink.stamp \ stamps/hotspot-tools.stamp stamps/plugs.stamp \ stamps/ports.stamp stamps/patch.stamp stamps/overlay.stamp \ @@ -740,7 +739,6 @@ stamps/icedtea.stamp: stamps/bootstrap-d mkdir -p stamps touch stamps/icedtea.stamp -icedtea-debug: stamps/icedtea-debug.stamp stamps/icedtea-debug.stamp: stamps/bootstrap-directory-symlink.stamp \ stamps/hotspot-tools.stamp stamps/plugs.stamp \ stamps/ports.stamp stamps/patch.stamp stamps/overlay.stamp \ @@ -1087,7 +1085,7 @@ stamps/jtreg.stamp: stamps/icedtea.stamp $(ICEDTEA_BOOT_DIR)/bin/javac -g -d test/jtreg/classes -source 1.5 \ -encoding iso-8859-1 `find $(srcdir)/test/jtreg/com -name '*.java'` (cd $(srcdir)/test/jtreg; \ - $(ICEDTEA_BOOT_DIR)/bin/jar cfm $(abs_top_builddir)/jtreg.jar \ + $(ICEDTEA_BOOT_DIR)/bin/jar cfm $(abs_top_builddir)/test/jtreg.jar \ META-INF/MANIFEST.MF \ legal README JavaTest.cmdMgrs.lst JavaTest.toolMgrs.lst \ `find com -type f -a -not -name '*.java'` \ @@ -1156,7 +1154,11 @@ extract: stamps/extract.stamp extract-ecj: stamps/extract-ecj.stamp +icedtea: stamps/icedtea.stamp + icedtea-against-ecj: stamps/icedtea-against-ecj.stamp + +icedtea-debug: stamps/icedtea-debug.stamp icedtea-ecj: stamps/icedtea-ecj.stamp diff -r 4cad9bad13c5 Makefile.in --- a/Makefile.in Tue Jul 01 14:31:40 2008 +0200 +++ b/Makefile.in Tue Jul 01 14:15:35 2008 +0100 @@ -1157,7 +1157,6 @@ clean-bootstrap-directory-symlink-ecj: # If you change anything here in the icedtea target, please make sure # you change it in the icedtea-debug target as well. -icedtea: stamps/icedtea.stamp stamps/icedtea.stamp: stamps/bootstrap-directory-symlink.stamp \ stamps/hotspot-tools.stamp stamps/plugs.stamp \ stamps/ports.stamp stamps/patch.stamp stamps/overlay.stamp \ @@ -1183,7 +1182,6 @@ stamps/icedtea.stamp: stamps/bootstrap-d mkdir -p stamps touch stamps/icedtea.stamp -icedtea-debug: stamps/icedtea-debug.stamp stamps/icedtea-debug.stamp: stamps/bootstrap-directory-symlink.stamp \ stamps/hotspot-tools.stamp stamps/plugs.stamp \ stamps/ports.stamp stamps/patch.stamp stamps/overlay.stamp \ @@ -1503,7 +1501,7 @@ stamps/jtreg.stamp: stamps/icedtea.stamp $(ICEDTEA_BOOT_DIR)/bin/javac -g -d test/jtreg/classes -source 1.5 \ -encoding iso-8859-1 `find $(srcdir)/test/jtreg/com -name '*.java'` (cd $(srcdir)/test/jtreg; \ - $(ICEDTEA_BOOT_DIR)/bin/jar cfm $(abs_top_builddir)/jtreg.jar \ + $(ICEDTEA_BOOT_DIR)/bin/jar cfm $(abs_top_builddir)/test/jtreg.jar \ META-INF/MANIFEST.MF \ legal README JavaTest.cmdMgrs.lst JavaTest.toolMgrs.lst \ `find com -type f -a -not -name '*.java'` \ @@ -1571,7 +1569,11 @@ extract: stamps/extract.stamp extract-ecj: stamps/extract-ecj.stamp +icedtea: stamps/icedtea.stamp + icedtea-against-ecj: stamps/icedtea-against-ecj.stamp + +icedtea-debug: stamps/icedtea-debug.stamp icedtea-ecj: stamps/icedtea-ecj.stamp From doko at ubuntu.com Tue Jul 1 15:33:10 2008 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 02 Jul 2008 00:33:10 +0200 Subject: very slow icedtea6 builds Message-ID: <486AB0A6.2060801@ubuntu.com> current icedtea6 builds take a loon time (for me, 14h instead of 4h, including running the jtreg harness). My last build from 2008-06-05 still takes 4h. Andrew reported a similiar problem on irc. The current repository is fixed, in that it doesn't build a debug jdk for the stage2 build, but I still see the much increased build times (e.g. building the rt.jar during the image install takes more than cpu 120min) on an Athlon64 4400+. Any suggestions what could be the cause for this? This seems to be consistent across used GCC versions and architectures. Matthias From Kelly.Ohair at Sun.COM Tue Jul 1 15:39:08 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 01 Jul 2008 15:39:08 -0700 Subject: very slow icedtea6 builds In-Reply-To: <486AB0A6.2060801@ubuntu.com> References: <486AB0A6.2060801@ubuntu.com> Message-ID: <486AB20C.4010809@sun.com> Local disk or network disk? -kto Matthias Klose wrote: > current icedtea6 builds take a loon time (for me, 14h instead of 4h, including > running the jtreg harness). My last build from 2008-06-05 still takes 4h. Andrew > reported a similiar problem on irc. The current repository is fixed, in that it > doesn't build a debug jdk for the stage2 build, but I still see the much > increased build times (e.g. building the rt.jar during the image install takes > more than cpu 120min) on an Athlon64 4400+. Any suggestions what could be the > cause for this? This seems to be consistent across used GCC versions and > architectures. > > Matthias From doko at ubuntu.com Tue Jul 1 16:00:02 2008 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 02 Jul 2008 01:00:02 +0200 Subject: very slow icedtea6 builds In-Reply-To: <486AB20C.4010809@sun.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> Message-ID: <486AB6F2.6040007@ubuntu.com> all builds done on local disk (and both based on b10). Matthias Kelly O'Hair schrieb: > Local disk or network disk? > > -kto > > Matthias Klose wrote: >> current icedtea6 builds take a loon time (for me, 14h instead of 4h, >> including >> running the jtreg harness). My last build from 2008-06-05 still takes >> 4h. Andrew >> reported a similiar problem on irc. The current repository is fixed, >> in that it >> doesn't build a debug jdk for the stage2 build, but I still see the much >> increased build times (e.g. building the rt.jar during the image >> install takes >> more than cpu 120min) on an Athlon64 4400+. Any suggestions what could >> be the >> cause for this? This seems to be consistent across used GCC versions and >> architectures. >> >> Matthias From Kelly.Ohair at Sun.COM Tue Jul 1 16:32:24 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 01 Jul 2008 16:32:24 -0700 Subject: very slow icedtea6 builds In-Reply-To: <486AB6F2.6040007@ubuntu.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> Message-ID: <486ABE88.9050302@sun.com> The construction of the rt.jar (or maybe rt-orig.jar in the Makefiles) can be very slow, lots of disk activity in creating it. The hotspot build will likely be the CPU intensive one (parallel make, high opt), but the rest of the jdk (images in particular) is much more disk intensive. The faster the disk drive and the faster the local disk, the better. The number of bytes just moving from one place on the disk to another is pretty intense. -kto Matthias Klose wrote: > all builds done on local disk (and both based on b10). > > Matthias > > Kelly O'Hair schrieb: >> Local disk or network disk? >> >> -kto >> >> Matthias Klose wrote: >>> current icedtea6 builds take a loon time (for me, 14h instead of 4h, >>> including >>> running the jtreg harness). My last build from 2008-06-05 still takes >>> 4h. Andrew >>> reported a similiar problem on irc. The current repository is fixed, >>> in that it >>> doesn't build a debug jdk for the stage2 build, but I still see the much >>> increased build times (e.g. building the rt.jar during the image >>> install takes >>> more than cpu 120min) on an Athlon64 4400+. Any suggestions what could >>> be the >>> cause for this? This seems to be consistent across used GCC versions and >>> architectures. >>> >>> Matthias > From doko at ubuntu.com Tue Jul 1 16:40:29 2008 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 02 Jul 2008 01:40:29 +0200 Subject: very slow icedtea6 builds In-Reply-To: <486ABE88.9050302@sun.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> <486ABE88.9050302@sun.com> Message-ID: <486AC06D.6040608@ubuntu.com> Kelly O'Hair schrieb: > The construction of the rt.jar (or maybe rt-orig.jar in the Makefiles) > can be very slow, lots of disk activity in creating it. > > The hotspot build will likely be the CPU intensive one (parallel make, > high opt), > but the rest of the jdk (images in particular) is much more disk intensive. > The faster the disk drive and the faster the local disk, the better. > > The number of bytes just moving from one place on the disk to another > is pretty intense. the build is done on a striped two disk array (WD Raptor 10k disks), so I don't think the build is limited by IO (plus I didn't change the config during the last six months). Somebody had the suspicion that the build doesn't use the jit, but I didn't find out yet if this is true. Matthias From Kelly.Ohair at Sun.COM Tue Jul 1 16:43:19 2008 From: Kelly.Ohair at Sun.COM (Kelly O'Hair) Date: Tue, 01 Jul 2008 16:43:19 -0700 Subject: very slow icedtea6 builds In-Reply-To: <486AC06D.6040608@ubuntu.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> <486ABE88.9050302@sun.com> <486AC06D.6040608@ubuntu.com> Message-ID: <486AC117.1030802@sun.com> Could it be using a different jar utility than before? And you might look at the log file and see what -Xmx setting is being passed into the jar utility (at end of jar command I think). If the -Xmx is too low or left as the default that could be a problem. -kto Matthias Klose wrote: > Kelly O'Hair schrieb: >> The construction of the rt.jar (or maybe rt-orig.jar in the Makefiles) >> can be very slow, lots of disk activity in creating it. >> >> The hotspot build will likely be the CPU intensive one (parallel make, >> high opt), >> but the rest of the jdk (images in particular) is much more disk intensive. >> The faster the disk drive and the faster the local disk, the better. >> >> The number of bytes just moving from one place on the disk to another >> is pretty intense. > > the build is done on a striped two disk array (WD Raptor 10k disks), so I don't > think the build is limited by IO (plus I didn't change the config during the > last six months). Somebody had the suspicion that the build doesn't use the > jit, but I didn't find out yet if this is true. > > Matthias > From aph at redhat.com Wed Jul 2 01:35:52 2008 From: aph at redhat.com (Andrew Haley) Date: Wed, 02 Jul 2008 09:35:52 +0100 Subject: very slow icedtea6 builds In-Reply-To: <486AC06D.6040608@ubuntu.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> <486ABE88.9050302@sun.com> <486AC06D.6040608@ubuntu.com> Message-ID: <486B3DE8.8060608@redhat.com> Matthias Klose wrote: > Kelly O'Hair schrieb: >> The construction of the rt.jar (or maybe rt-orig.jar in the Makefiles) >> can be very slow, lots of disk activity in creating it. >> >> The hotspot build will likely be the CPU intensive one (parallel make, >> high opt), >> but the rest of the jdk (images in particular) is much more disk intensive. >> The faster the disk drive and the faster the local disk, the better. >> >> The number of bytes just moving from one place on the disk to another >> is pretty intense. > > the build is done on a striped two disk array (WD Raptor 10k disks), so I don't > think the build is limited by IO (plus I didn't change the config during the > last six months). Somebody had the suspicion that the build doesn't use the > jit, but I didn't find out yet if this is true. What do you mean by "the building of the jar"? The building of the components of the jar, or only the jar command itself? This isn't clear. Andrew. From gnu_andrew at member.fsf.org Wed Jul 2 01:55:20 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Jul 2008 09:55:20 +0100 Subject: very slow icedtea6 builds In-Reply-To: <486B3DE8.8060608@redhat.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> <486ABE88.9050302@sun.com> <486AC06D.6040608@ubuntu.com> <486B3DE8.8060608@redhat.com> Message-ID: <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> 2008/7/2 Andrew Haley : > Matthias Klose wrote: >> Kelly O'Hair schrieb: >>> The construction of the rt.jar (or maybe rt-orig.jar in the Makefiles) >>> can be very slow, lots of disk activity in creating it. >>> >>> The hotspot build will likely be the CPU intensive one (parallel make, >>> high opt), >>> but the rest of the jdk (images in particular) is much more disk intensive. >>> The faster the disk drive and the faster the local disk, the better. >>> >>> The number of bytes just moving from one place on the disk to another >>> is pretty intense. >> >> the build is done on a striped two disk array (WD Raptor 10k disks), so I don't >> think the build is limited by IO (plus I didn't change the config during the >> last six months). Somebody had the suspicion that the build doesn't use the >> jit, but I didn't find out yet if this is true. > > What do you mean by "the building of the jar"? The building of the components > of the jar, or only the jar command itself? This isn't clear. > > Andrew. > Specifically it's the creation of rt.jar. Something is clearly wrong, because my java -version output is now: OpenJDK 64-Bit Core VM (build 1.6.0_0-b10, mixed mode on x86_64 -- it's usually: OpenJDK 64-Bit Server VM (build 1.6.0-b08, mixed mode) (from my installed system version). My builds have increased about ten-fold. I have a feeling this is related to Gary's recent commit to be honest but I can't see why just yet. I also also now get a 'fastdebug' version but that may be a side-effect of make distcheck. -- Andrew :-) 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 gbenson at redhat.com Wed Jul 2 03:55:34 2008 From: gbenson at redhat.com (Gary Benson) Date: Wed, 2 Jul 2008 11:55:34 +0100 Subject: very slow icedtea6 builds In-Reply-To: <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> <486ABE88.9050302@sun.com> <486AC06D.6040608@ubuntu.com> <486B3DE8.8060608@redhat.com> <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> Message-ID: <20080702105534.GA3750@redhat.com> Andrew John Hughes wrote: > Something is clearly wrong, because my java -version output is now: > > OpenJDK 64-Bit Core VM (build 1.6.0_0-b10, mixed mode That's a core build. You don't have a JIT in there. > (from my installed system version). My builds have increased about > ten-fold. I have a feeling this is related to Gary's recent commit > to be honest but I can't see why just yet. It probably is, sorry. I tested it all in advance but apparently not enough :/ Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Wed Jul 2 03:59:34 2008 From: gbenson at redhat.com (Gary Benson) Date: Wed, 2 Jul 2008 11:59:34 +0100 Subject: very slow icedtea6 builds In-Reply-To: <20080702105534.GA3750@redhat.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> <486ABE88.9050302@sun.com> <486AC06D.6040608@ubuntu.com> <486B3DE8.8060608@redhat.com> <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> <20080702105534.GA3750@redhat.com> Message-ID: <20080702105934.GB3750@redhat.com> Gary Benson wrote: > Andrew John Hughes wrote: > > Something is clearly wrong, because my java -version output is now: > > > > OpenJDK 64-Bit Core VM (build 1.6.0_0-b10, mixed mode > > That's a core build. You don't have a JIT in there. PS What does "grep '^ICEDTEA_.*_BUILD =' Makefile" say? Cheers, Gary -- http://gbenson.net/ From gnu_andrew at member.fsf.org Wed Jul 2 05:04:51 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Jul 2008 13:04:51 +0100 Subject: very slow icedtea6 builds In-Reply-To: <20080702105934.GB3750@redhat.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> <486ABE88.9050302@sun.com> <486AC06D.6040608@ubuntu.com> <486B3DE8.8060608@redhat.com> <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> <20080702105534.GA3750@redhat.com> <20080702105934.GB3750@redhat.com> Message-ID: <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> 2008/7/2 Gary Benson : > Gary Benson wrote: >> Andrew John Hughes wrote: >> > Something is clearly wrong, because my java -version output is now: >> > >> > OpenJDK 64-Bit Core VM (build 1.6.0_0-b10, mixed mode >> >> That's a core build. You don't have a JIT in there. > > PS What does "grep '^ICEDTEA_.*_BUILD =' Makefile" say? > > Cheers, > Gary > > -- > http://gbenson.net/ > Thanks Gary, I thought it might be this because I remember that building rt.jar was the process that took a long time when building on ppc64. For clarification, building rt.jar for the main stage involves running the jar program that was built as part of the openjdk-ecj stage and which uses the version of HotSpot built by that stage. grep '^ICEDTEA_.*_BUILD =' /home/andrew/builder/icedtea6/icedtea6-1.3/_build/Makefile ICEDTEA_CORE_BUILD = yes ICEDTEA_ZERO_BUILD = ICEDTEA_SHARK_BUILD = -- Andrew :-) 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 gbenson at redhat.com Wed Jul 2 05:27:24 2008 From: gbenson at redhat.com (Gary Benson) Date: Wed, 2 Jul 2008 13:27:24 +0100 Subject: very slow icedtea6 builds In-Reply-To: <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> References: <486AB0A6.2060801@ubuntu.com> <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> <486ABE88.9050302@sun.com> <486AC06D.6040608@ubuntu.com> <486B3DE8.8060608@redhat.com> <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> <20080702105534.GA3750@redhat.com> <20080702105934.GB3750@redhat.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> Message-ID: <20080702122724.GC3750@redhat.com> Andrew John Hughes wrote: > 2008/7/2 Gary Benson : > > Gary Benson wrote: > > > Andrew John Hughes wrote: > > > > Something is clearly wrong, because my java -version output is now: > > > > > > > > OpenJDK 64-Bit Core VM (build 1.6.0_0-b10, mixed mode > > > > > > That's a core build. You don't have a JIT in there. > > > > PS What does "grep '^ICEDTEA_.*_BUILD =' Makefile" say? > > Thanks Gary, I thought it might be this because I remember that > building rt.jar was the process that took a long time when building > on ppc64. For clarification, building rt.jar for the main stage > involves running the jar program that was built as part of the > openjdk-ecj stage and which uses the version of HotSpot built by > that stage. > > grep '^ICEDTEA_.*_BUILD =' > /home/andrew/builder/icedtea6/icedtea6-1.3/_build/Makefile > ICEDTEA_CORE_BUILD = yes > ICEDTEA_ZERO_BUILD = > ICEDTEA_SHARK_BUILD = Can you try with the attached patch? Cheers, Gary -- http://gbenson.net/ From gbenson at redhat.com Wed Jul 2 05:27:46 2008 From: gbenson at redhat.com (Gary Benson) Date: Wed, 2 Jul 2008 13:27:46 +0100 Subject: very slow icedtea6 builds In-Reply-To: <20080702122724.GC3750@redhat.com> References: <486AB20C.4010809@sun.com> <486AB6F2.6040007@ubuntu.com> <486ABE88.9050302@sun.com> <486AC06D.6040608@ubuntu.com> <486B3DE8.8060608@redhat.com> <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> <20080702105534.GA3750@redhat.com> <20080702105934.GB3750@redhat.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> <20080702122724.GC3750@redhat.com> Message-ID: <20080702122746.GD3750@redhat.com> Gary Benson wrote: > Can you try with the attached patch? Yeah... -------------- next part -------------- diff -r e0b9e60483f8 acinclude.m4 --- a/acinclude.m4 Tue Jul 01 14:16:32 2008 +0100 +++ b/acinclude.m4 Wed Jul 02 13:24:47 2008 +0100 @@ -670,28 +670,33 @@ AC_DEFUN([SET_CORE_OR_SHARK_BUILD], AC_DEFUN([SET_CORE_OR_SHARK_BUILD], [ AC_MSG_CHECKING(whether to use the Shark JIT) - use_shark=no + shark_selected=no AC_ARG_ENABLE([shark], [AS_HELP_STRING(--enable-shark, use Shark JIT)], [ case "${enableval}" in no) ;; *) - if test "x${ZERO_BUILD_TRUE}" = x; then - use_shark=yes - fi + shark_selected=yes ;; esac ]) + + use_core=no + use_shark=no + if test "x${CACAO}" != "xno"; then + use_core=yes + elif test "x${ZERO_BUILD_TRUE}" = "x"; then + if test "x${shark_selected}" = "xyes"; then + use_shark=yes + else + use_core=yes + fi + fi AC_MSG_RESULT($use_shark) - if test "x${CACAO}" != "xno"; then - AM_CONDITIONAL(CORE_BUILD, true) - AM_CONDITIONAL(SHARK_BUILD, false) - else - AM_CONDITIONAL(CORE_BUILD, test "x${use_shark}" != xyes) - AM_CONDITIONAL(SHARK_BUILD, test "x${use_shark}" = xyes) - fi + AM_CONDITIONAL(CORE_BUILD, test "x${use_core}" = xyes) + AM_CONDITIONAL(SHARK_BUILD, test "x${use_shark}" = xyes) ]) AC_DEFUN([AC_CHECK_WITH_CACAO], From langel at redhat.com Wed Jul 2 05:29:23 2008 From: langel at redhat.com (Lillian Angel) Date: Wed, 02 Jul 2008 08:29:23 -0400 Subject: very slow icedtea6 builds In-Reply-To: <486AB0A6.2060801@ubuntu.com> References: <486AB0A6.2060801@ubuntu.com> Message-ID: <486B74A3.8060404@redhat.com> Matthias Klose wrote: > current icedtea6 builds take a loon time (for me, 14h instead of 4h, including > running the jtreg harness). I have noticed this as well with the nightly tests that are running. > My last build from 2008-06-05 still takes 4h. Andrew > reported a similiar problem on irc. The current repository is fixed, in that it > doesn't build a debug jdk for the stage2 build, but I still see the much > increased build times (e.g. building the rt.jar during the image install takes > more than cpu 120min) on an Athlon64 4400+. Any suggestions what could be the > cause for this? This seems to be consistent across used GCC versions and > architectures. Lillian From gnu_andrew at member.fsf.org Wed Jul 2 07:38:44 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Jul 2008 15:38:44 +0100 Subject: very slow icedtea6 builds In-Reply-To: <20080702122746.GD3750@redhat.com> References: <486AB20C.4010809@sun.com> <486ABE88.9050302@sun.com> <486AC06D.6040608@ubuntu.com> <486B3DE8.8060608@redhat.com> <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> <20080702105534.GA3750@redhat.com> <20080702105934.GB3750@redhat.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> <20080702122724.GC3750@redhat.com> <20080702122746.GD3750@redhat.com> Message-ID: <17c6771e0807020738g38f4de49ub43be62b48694a1c@mail.gmail.com> 2008/7/2 Gary Benson : > Gary Benson wrote: >> Can you try with the attached patch? > > Yeah... I've just set it going and I'll let you know what comes out the other end. >From the patch though, it looks like the right fix. The original implies that core is enabled whenever shark isn't whereas it should only be enabled if the build is also not x86/x86_64/sparc. -- Andrew :-) 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 gnu_andrew at member.fsf.org Wed Jul 2 10:17:33 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Jul 2008 18:17:33 +0100 Subject: very slow icedtea6 builds In-Reply-To: <17c6771e0807020738g38f4de49ub43be62b48694a1c@mail.gmail.com> References: <486AB20C.4010809@sun.com> <486AC06D.6040608@ubuntu.com> <486B3DE8.8060608@redhat.com> <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> <20080702105534.GA3750@redhat.com> <20080702105934.GB3750@redhat.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> <20080702122724.GC3750@redhat.com> <20080702122746.GD3750@redhat.com> <17c6771e0807020738g38f4de49ub43be62b48694a1c@mail.gmail.com> Message-ID: <17c6771e0807021017u2c5024f5h3fc96f43d25c3f9b@mail.gmail.com> On 02/07/2008, Andrew John Hughes wrote: > 2008/7/2 Gary Benson : > > > Gary Benson wrote: > >> Can you try with the attached patch? > > > > Yeah... > > > I've just set it going and I'll let you know what comes out the other end. > From the patch though, it looks like the right fix. The original implies > that core is enabled whenever shark isn't whereas it should only be > enabled if the build is also not x86/x86_64/sparc. > > -- > Andrew :-) > > 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 > Sorry doesn't seem to solve the issue here or for doko... I'll try and look into it myself later. -- Andrew :-) 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 gnu_andrew at member.fsf.org Wed Jul 2 11:35:18 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Jul 2008 19:35:18 +0100 Subject: very slow icedtea6 builds In-Reply-To: <17c6771e0807021017u2c5024f5h3fc96f43d25c3f9b@mail.gmail.com> References: <486AB20C.4010809@sun.com> <486B3DE8.8060608@redhat.com> <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> <20080702105534.GA3750@redhat.com> <20080702105934.GB3750@redhat.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> <20080702122724.GC3750@redhat.com> <20080702122746.GD3750@redhat.com> <17c6771e0807020738g38f4de49ub43be62b48694a1c@mail.gmail.com> <17c6771e0807021017u2c5024f5h3fc96f43d25c3f9b@mail.gmail.com> Message-ID: <17c6771e0807021135r4d942aapd93e905e596b4002@mail.gmail.com> On 02/07/2008, Andrew John Hughes wrote: > On 02/07/2008, Andrew John Hughes wrote: > > 2008/7/2 Gary Benson : > > > > > Gary Benson wrote: > > >> Can you try with the attached patch? > > > > > > Yeah... > > > > > > I've just set it going and I'll let you know what comes out the other end. > > From the patch though, it looks like the right fix. The original implies > > that core is enabled whenever shark isn't whereas it should only be > > enabled if the build is also not x86/x86_64/sparc. > > > > -- > > Andrew :-) > > > > 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 > > > > > Sorry doesn't seem to solve the issue here or for doko... I'll try and > look into it myself later. > > -- > Andrew :-) > > 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 > I think I spotted the issue, will retry. Just one alteration to your patch: + elif test "x${use_zero}" = "xyes"; then instead of using test "x${ZERO_BUILD_TRUE}" = "x" -- Andrew :-) 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 gnu_andrew at member.fsf.org Wed Jul 2 11:50:49 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Jul 2008 19:50:49 +0100 Subject: very slow icedtea6 builds In-Reply-To: <17c6771e0807021135r4d942aapd93e905e596b4002@mail.gmail.com> References: <486AB20C.4010809@sun.com> <17c6771e0807020155m6d1ff3c3v5cb2befc35a2d333@mail.gmail.com> <20080702105534.GA3750@redhat.com> <20080702105934.GB3750@redhat.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> <20080702122724.GC3750@redhat.com> <20080702122746.GD3750@redhat.com> <17c6771e0807020738g38f4de49ub43be62b48694a1c@mail.gmail.com> <17c6771e0807021017u2c5024f5h3fc96f43d25c3f9b@mail.gmail.com> <17c6771e0807021135r4d942aapd93e905e596b4002@mail.gmail.com> Message-ID: <17c6771e0807021150s7c9bb949o62141cbf22ee0881@mail.gmail.com> On 02/07/2008, Andrew John Hughes wrote: > On 02/07/2008, Andrew John Hughes wrote: > > On 02/07/2008, Andrew John Hughes wrote: > > > 2008/7/2 Gary Benson : > > > > > > > Gary Benson wrote: > > > >> Can you try with the attached patch? > > > > > > > > Yeah... > > > > > > > > > I've just set it going and I'll let you know what comes out the other end. > > > From the patch though, it looks like the right fix. The original implies > > > that core is enabled whenever shark isn't whereas it should only be > > > enabled if the build is also not x86/x86_64/sparc. > > > > > > -- > > > Andrew :-) > > > > > > 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 > > > > > > > > > Sorry doesn't seem to solve the issue here or for doko... I'll try and > > look into it myself later. > > > > -- > > Andrew :-) > > > > 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 > > > > > I think I spotted the issue, will retry. > Just one alteration to your patch: > > + elif test "x${use_zero}" = "xyes"; then > > instead of using test "x${ZERO_BUILD_TRUE}" = "x" > > > -- > > Andrew :-) > > 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 > Ok that didn't work, but I think it may be a case of twisti's cacao changes taking place while you were working on Shark... Your checks probe ${CACAO} but I can only see ${WITH_CACAO} being defined... -- Andrew :-) 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 gnu_andrew at member.fsf.org Wed Jul 2 11:58:35 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Jul 2008 19:58:35 +0100 Subject: very slow icedtea6 builds In-Reply-To: <17c6771e0807021150s7c9bb949o62141cbf22ee0881@mail.gmail.com> References: <486AB20C.4010809@sun.com> <20080702105534.GA3750@redhat.com> <20080702105934.GB3750@redhat.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> <20080702122724.GC3750@redhat.com> <20080702122746.GD3750@redhat.com> <17c6771e0807020738g38f4de49ub43be62b48694a1c@mail.gmail.com> <17c6771e0807021017u2c5024f5h3fc96f43d25c3f9b@mail.gmail.com> <17c6771e0807021135r4d942aapd93e905e596b4002@mail.gmail.com> <17c6771e0807021150s7c9bb949o62141cbf22ee0881@mail.gmail.com> Message-ID: <17c6771e0807021158u195a538atf8b6d9be3071b081@mail.gmail.com> On 02/07/2008, Andrew John Hughes wrote: > On 02/07/2008, Andrew John Hughes wrote: > > On 02/07/2008, Andrew John Hughes wrote: > > > On 02/07/2008, Andrew John Hughes wrote: > > > > 2008/7/2 Gary Benson : > > > > > > > > > Gary Benson wrote: > > > > >> Can you try with the attached patch? > > > > > > > > > > Yeah... > > > > > > > > > > > > I've just set it going and I'll let you know what comes out the other end. > > > > From the patch though, it looks like the right fix. The original implies > > > > that core is enabled whenever shark isn't whereas it should only be > > > > enabled if the build is also not x86/x86_64/sparc. > > > > > > > > -- > > > > Andrew :-) > > > > > > > > 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 > > > > > > > > > > > > > Sorry doesn't seem to solve the issue here or for doko... I'll try and > > > look into it myself later. > > > > > > -- > > > Andrew :-) > > > > > > 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 > > > > > > > > > I think I spotted the issue, will retry. > > Just one alteration to your patch: > > > > + elif test "x${use_zero}" = "xyes"; then > > > > instead of using test "x${ZERO_BUILD_TRUE}" = "x" > > > > > > -- > > > > Andrew :-) > > > > 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 > > > > > Ok that didn't work, but I think it may be a case of twisti's cacao > changes taking place while you were working on Shark... > > Your checks probe ${CACAO} but I can only see ${WITH_CACAO} being defined... > > -- > > Andrew :-) > > 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 > That appears to have worked based on the resulting Makefile, so I checked in the attached fix: 2008-07-02 Andrew John Hughes * acinclude.m4: Switch ${CACAO} for ${WITH_CACAO} in Shark/core/zero rules and use ${use_zero} instead of ${ZERO_BUILD_TRUE}. * aclocal.m4, * configure: Regenerated. 2008-07-02 Gary Benson * acinclude.m4: Fix detection of Shark/core build. * aclocal.m4, * configure: Regenerated. Please check I didn't break cacao or zero though! -- Andrew :-) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: core_build_fix.diff Type: text/x-patch Size: 53685 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080702/0af3464d/attachment-0001.bin From langel at redhat.com Wed Jul 2 12:01:34 2008 From: langel at redhat.com (Lillian Angel) Date: Wed, 02 Jul 2008 15:01:34 -0400 Subject: very slow icedtea6 builds In-Reply-To: <17c6771e0807021158u195a538atf8b6d9be3071b081@mail.gmail.com> References: <486AB20C.4010809@sun.com> <20080702105534.GA3750@redhat.com> <20080702105934.GB3750@redhat.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> <20080702122724.GC3750@redhat.com> <20080702122746.GD3750@redhat.com> <17c6771e0807020738g38f4de49ub43be62b48694a1c@mail.gmail.com> <17c6771e0807021017u2c5024f5h3fc96f43d25c3f9b@mail.gmail.com> <17c6771e0807021135r4d942aapd93e905e596b4002@mail.gmail.com> <17c6771e0807021150s7c9bb949o62141cbf22ee0881@mail.gmail.com> <17c6771e0807021158u195a538atf8b6d9be3071b081@mail.gmail.com> Message-ID: <486BD08E.40602@redhat.com> Andrew John Hughes wrote: > On 02/07/2008, Andrew John Hughes wrote: >> On 02/07/2008, Andrew John Hughes wrote: >> > On 02/07/2008, Andrew John Hughes wrote: >> > > On 02/07/2008, Andrew John Hughes wrote: >> > > > 2008/7/2 Gary Benson : >> > > > >> > > > > Gary Benson wrote: >> > > > >> Can you try with the attached patch? >> > > > > >> > > > > Yeah... >> > > > >> > > > >> > > > I've just set it going and I'll let you know what comes out the other end. >> > > > From the patch though, it looks like the right fix. The original implies >> > > > that core is enabled whenever shark isn't whereas it should only be >> > > > enabled if the build is also not x86/x86_64/sparc. >> > > > >> > > > -- >> > > > Andrew :-) >> > > > >> > > > 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 >> > > > >> > > >> > > >> > > Sorry doesn't seem to solve the issue here or for doko... I'll try and >> > > look into it myself later. >> > > >> > > -- >> > > Andrew :-) >> > > >> > > 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 >> > > >> > >> > >> > I think I spotted the issue, will retry. >> > Just one alteration to your patch: >> > >> > + elif test "x${use_zero}" = "xyes"; then >> > >> > instead of using test "x${ZERO_BUILD_TRUE}" = "x" >> > >> > >> > -- >> > >> > Andrew :-) >> > >> > 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 >> > >> >> >> Ok that didn't work, but I think it may be a case of twisti's cacao >> changes taking place while you were working on Shark... >> >> Your checks probe ${CACAO} but I can only see ${WITH_CACAO} being defined... >> >> -- >> >> Andrew :-) >> >> 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 >> > > That appears to have worked based on the resulting Makefile, so I > checked in the attached fix: > > 2008-07-02 Andrew John Hughes > > * acinclude.m4: > Switch ${CACAO} for ${WITH_CACAO} in > Shark/core/zero rules and use ${use_zero} > instead of ${ZERO_BUILD_TRUE}. > * aclocal.m4, > * configure: > Regenerated. > > 2008-07-02 Gary Benson > > * acinclude.m4: > Fix detection of Shark/core build. > * aclocal.m4, > * configure: > Regenerated. > > > Please check I didn't break cacao or zero though! Thanks so much for fixing this. Lillian From gnu_andrew at member.fsf.org Wed Jul 2 12:08:07 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Jul 2008 20:08:07 +0100 Subject: very slow icedtea6 builds In-Reply-To: <486BD08E.40602@redhat.com> References: <486AB20C.4010809@sun.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> <20080702122724.GC3750@redhat.com> <20080702122746.GD3750@redhat.com> <17c6771e0807020738g38f4de49ub43be62b48694a1c@mail.gmail.com> <17c6771e0807021017u2c5024f5h3fc96f43d25c3f9b@mail.gmail.com> <17c6771e0807021135r4d942aapd93e905e596b4002@mail.gmail.com> <17c6771e0807021150s7c9bb949o62141cbf22ee0881@mail.gmail.com> <17c6771e0807021158u195a538atf8b6d9be3071b081@mail.gmail.com> <486BD08E.40602@redhat.com> Message-ID: <17c6771e0807021208q61fd67e8k76fa2369a281b184@mail.gmail.com> On 02/07/2008, Lillian Angel wrote: > > > Andrew John Hughes wrote: > > > On 02/07/2008, Andrew John Hughes wrote: > > > > > On 02/07/2008, Andrew John Hughes wrote: > > > > On 02/07/2008, Andrew John Hughes wrote: > > > > > On 02/07/2008, Andrew John Hughes > wrote: > > > > > > 2008/7/2 Gary Benson : > > > > > > > > > > > > > Gary Benson wrote: > > > > > > >> Can you try with the attached patch? > > > > > > > > > > > > > > Yeah... > > > > > > > > > > > > > > > > > > I've just set it going and I'll let you know what comes out the > other end. > > > > > > From the patch though, it looks like the right fix. The > original implies > > > > > > that core is enabled whenever shark isn't whereas it should > only be > > > > > > enabled if the build is also not x86/x86_64/sparc. > > > > > > > > > > > > -- > > > > > > Andrew :-) > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > Sorry doesn't seem to solve the issue here or for doko... I'll try > and > > > > > look into it myself later. > > > > > > > > > > -- > > > > > Andrew :-) > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > I think I spotted the issue, will retry. > > > > Just one alteration to your patch: > > > > > > > > + elif test "x${use_zero}" = "xyes"; then > > > > > > > > instead of using test "x${ZERO_BUILD_TRUE}" = "x" > > > > > > > > > > > > -- > > > > > > > > Andrew :-) > > > > > > > > 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 > > > > > > > > > > > > > Ok that didn't work, but I think it may be a case of twisti's cacao > > > changes taking place while you were working on Shark... > > > > > > Your checks probe ${CACAO} but I can only see ${WITH_CACAO} being > defined... > > > > > > -- > > > > > > Andrew :-) > > > > > > 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 > > > > > > > > > > That appears to have worked based on the resulting Makefile, so I > > checked in the attached fix: > > > > 2008-07-02 Andrew John Hughes > > > > * acinclude.m4: > > Switch ${CACAO} for ${WITH_CACAO} in > > Shark/core/zero rules and use ${use_zero} > > instead of ${ZERO_BUILD_TRUE}. > > * aclocal.m4, > > * configure: > > Regenerated. > > > > 2008-07-02 Gary Benson > > > > * acinclude.m4: > > Fix detection of Shark/core build. > > * aclocal.m4, > > * configure: > > Regenerated. > > > > > > Please check I didn't break cacao or zero though! > > > > > Thanks so much for fixing this. > > > Lillian > No problem, I was kind of annoyed myself when my build went from 10 minutes to over 2 hours the other night... :) Hey, at least Gary's work got a lot of much deserved testing over the last week... -- Andrew :-) 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 doko at ubuntu.com Wed Jul 2 14:37:12 2008 From: doko at ubuntu.com (Matthias Klose) Date: Wed, 02 Jul 2008 23:37:12 +0200 Subject: very slow icedtea6 builds In-Reply-To: <17c6771e0807021208q61fd67e8k76fa2369a281b184@mail.gmail.com> References: <486AB20C.4010809@sun.com> <17c6771e0807020504k5179fbeeo4fba5f07af9ebdeb@mail.gmail.com> <20080702122724.GC3750@redhat.com> <20080702122746.GD3750@redhat.com> <17c6771e0807020738g38f4de49ub43be62b48694a1c@mail.gmail.com> <17c6771e0807021017u2c5024f5h3fc96f43d25c3f9b@mail.gmail.com> <17c6771e0807021135r4d942aapd93e905e596b4002@mail.gmail.com> <17c6771e0807021150s7c9bb949o62141cbf22ee0881@mail.gmail.com> <17c6771e0807021158u195a538atf8b6d9be3071b081@mail.gmail.com> <486BD08E.40602@redhat.com> <17c6771e0807021208q61fd67e8k76fa2369a281b184@mail.gmail.com> Message-ID: <486BF508.3060807@ubuntu.com> Andrew John Hughes schrieb: > On 02/07/2008, Lillian Angel wrote: >> >> Andrew John Hughes wrote: >> >>> On 02/07/2008, Andrew John Hughes wrote: >>> >>>> On 02/07/2008, Andrew John Hughes wrote: >>>> > On 02/07/2008, Andrew John Hughes wrote: >>>> > > On 02/07/2008, Andrew John Hughes >> wrote: >>>> > > > 2008/7/2 Gary Benson : >>>> > > > >>>> > > > > Gary Benson wrote: >>>> > > > >> Can you try with the attached patch? >>>> > > > > >>>> > > > > Yeah... >>>> > > > >>>> > > > >>>> > > > I've just set it going and I'll let you know what comes out the >> other end. >>>> > > > From the patch though, it looks like the right fix. The >> original implies >>>> > > > that core is enabled whenever shark isn't whereas it should >> only be >>>> > > > enabled if the build is also not x86/x86_64/sparc. >>>> > > > >>>> > > > -- >>>> > > > Andrew :-) >>>> > > > >>>> > > > 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 >>>> > > > >>>> > > >>>> > > >>>> > > Sorry doesn't seem to solve the issue here or for doko... I'll try >> and >>>> > > look into it myself later. >>>> > > >>>> > > -- >>>> > > Andrew :-) >>>> > > >>>> > > 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 >>>> > > >>>> > >>>> > >>>> > I think I spotted the issue, will retry. >>>> > Just one alteration to your patch: >>>> > >>>> > + elif test "x${use_zero}" = "xyes"; then >>>> > >>>> > instead of using test "x${ZERO_BUILD_TRUE}" = "x" >>>> > >>>> > >>>> > -- >>>> > >>>> > Andrew :-) >>>> > >>>> > 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 >>>> > >>>> >>>> >>>> Ok that didn't work, but I think it may be a case of twisti's cacao >>>> changes taking place while you were working on Shark... >>>> >>>> Your checks probe ${CACAO} but I can only see ${WITH_CACAO} being >> defined... >>>> -- >>>> >>>> Andrew :-) >>>> >>>> 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 >>>> >>>> >>> That appears to have worked based on the resulting Makefile, so I >>> checked in the attached fix: >>> >>> 2008-07-02 Andrew John Hughes >>> >>> * acinclude.m4: >>> Switch ${CACAO} for ${WITH_CACAO} in >>> Shark/core/zero rules and use ${use_zero} >>> instead of ${ZERO_BUILD_TRUE}. >>> * aclocal.m4, >>> * configure: >>> Regenerated. >>> >>> 2008-07-02 Gary Benson >>> >>> * acinclude.m4: >>> Fix detection of Shark/core build. >>> * aclocal.m4, >>> * configure: >>> Regenerated. >>> >>> >>> Please check I didn't break cacao or zero though! >>> >> >> Thanks so much for fixing this. >> >> >> Lillian >> > > No problem, I was kind of annoyed myself when my build went from 10 > minutes to over 2 hours the other night... :) > > Hey, at least Gary's work got a lot of much deserved testing over the > last week... heh, a shark choking on cacao. thanks for finding that. Matthias From gnu_andrew at member.fsf.org Wed Jul 2 15:43:56 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Wed, 2 Jul 2008 23:43:56 +0100 Subject: FYI: More FSG work Message-ID: <20080702224356.GA22730@rivendell.middle-earth.co.uk> This adds a new script, based on the one doko uses to create the Debian/Ubuntu builds. We apply it in OpenJDK extraction, so the results get poured into the fsg tarball when created. ChangeLog: 2008-07-02 Andrew John Hughes * HACKING: Update with FSG list and further bug numbers. * Makefile.am: Remove jscheme removal and add in new fsg script. * Makefile.in: Regenerated. * fsg.sh: Script to sanitise OpenJDK before building and for the fsg tarball. -- Andrew :) 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 -------------- next part -------------- diff -r 36d1d3a135f5 HACKING --- a/HACKING Wed Jul 02 15:00:43 2008 -0400 +++ b/HACKING Wed Jul 02 23:37:01 2008 +0100 @@ -4,7 +4,17 @@ PRx denotes bug x in the IcedTea bug dat PRx denotes bug x in the IcedTea bug database (http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=x) Sx denotes bug x in the Sun bug database (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=x) -The following patches are currently applied to OpenJDK or OpenJDK6 by IcedTea: +The following patches are applied early in the build to meet the Free Software guidelines and are also +included in the tarball resulting from the dist-openjdk-fsg target: + +* icedtea-idl.patch: Fix IDL licenses (PR141/S6695776). +* icedtea-jscheme.patch: Replace use of jscheme.jar with Java alternative (PR140/S6695776). +* icedtea-license-headers.patch: Generate GPL header from automulti tool (PR148,S6713083). + +The fsg.sh script is also run to delete certain files with dubious licensing and/or only occuring +in binary format. + +The following patches are currently applied before the building of OpenJDK or OpenJDK6 by IcedTea: * icedtea-ant.patch: Remove use of $(ANT_HOME). * icedtea-arm-uname.patch: Handle output of uname on arm. @@ -25,15 +35,12 @@ The following patches are currently appl * icedtea-gervill.patch: Add support for Gervill from the overlay. * icedtea-graphics.patch: Fix word wrap in JTextArea (PR57/S6593649) * icedtea-ia64-fdlibm.patch: Fix name of ia64 architecture from _M_IA64 to ia64. -* icedtea-idl.patch: Fix IDL licenses (PR141). * icedtea-javafiles.patch: Add missing Java files to list. * icedtea-jpegclasses.patch: Add com.sun.image.codec.jpeg support. -* icedtea-jscheme.patch: Replace use of jscheme.jar with Java alternative (PR140). * icedtea-lcms-leak.patch: Fix LCMS memory leak. * icedtea-LCMS-setTagData.patch: Add support for setTagData to LCMS peer. * icedtea-lib64.patch: Add support for building on platforms with /usr/lib64. * icedtea-libraries.patch: Use system JPEG and zlib libraries. -* icedtea-license-headers.patch: Generate GPL header from automulti tool. * icedtea-linker-options.patch: Add -Xlinker option when linking. * icedtea-memory-limits.patch: Increase default memory limits. * icedtea-no-bcopy.patch: Don't define local copies of bcopy, bzero and bcmp from BSD. diff -r 36d1d3a135f5 Makefile.am --- a/Makefile.am Wed Jul 02 15:00:43 2008 -0400 +++ b/Makefile.am Wed Jul 02 23:37:01 2008 +0100 @@ -4,8 +4,6 @@ OPENJDK_VERSION = b10 CACAO_VERSION = 0.99.1 CACAO_MD5SUM = 2337754d0c165af556e97395e9a5e5af - -JSCHEME_DIR = openjdk/corba/src/share/classes/com/sun/tools/corba/se/logutil if ENABLE_LIVECONNECT ICEDTEAPLUGIN_CLEAN = clean-IcedTeaPlugin @@ -430,8 +428,7 @@ stamps/extract.stamp: stamps/download.st mkdir openjdk ; \ $(TAR) xzf $(OPENJDK_SRC_ZIP) -C openjdk; \ chmod -R ug+w openjdk ; \ - rm -rf $(JSCHEME_DIR)/lib; \ - rm -rf $(JSCHEME_DIR)/scripts; \ + sh $(srcdir)/fsg.sh ; \ fi if WITH_CACAO if !USE_SYSTEM_CACAO diff -r 36d1d3a135f5 Makefile.in --- a/Makefile.in Wed Jul 02 15:00:43 2008 -0400 +++ b/Makefile.in Wed Jul 02 23:37:01 2008 +0100 @@ -267,7 +267,6 @@ OPENJDK_VERSION = b10 OPENJDK_VERSION = b10 CACAO_VERSION = 0.99.1 CACAO_MD5SUM = 2337754d0c165af556e97395e9a5e5af -JSCHEME_DIR = openjdk/corba/src/share/classes/com/sun/tools/corba/se/logutil @ENABLE_LIVECONNECT_FALSE at ICEDTEAPLUGIN_CLEAN = @ENABLE_LIVECONNECT_TRUE at ICEDTEAPLUGIN_CLEAN = clean-IcedTeaPlugin @ENABLE_LIVECONNECT_FALSE at ICEDTEAPLUGIN_TARGET = @@ -906,8 +905,7 @@ stamps/extract.stamp: stamps/download.st mkdir openjdk ; \ $(TAR) xzf $(OPENJDK_SRC_ZIP) -C openjdk; \ chmod -R ug+w openjdk ; \ - rm -rf $(JSCHEME_DIR)/lib; \ - rm -rf $(JSCHEME_DIR)/scripts; \ + sh $(srcdir)/fsg.sh ; \ fi @USE_SYSTEM_CACAO_FALSE@@WITH_CACAO_TRUE@ if ! test -d cacao ; \ @USE_SYSTEM_CACAO_FALSE@@WITH_CACAO_TRUE@ then \ diff -r 36d1d3a135f5 fsg.sh --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/fsg.sh Wed Jul 02 23:37:01 2008 +0100 @@ -0,0 +1,109 @@ +#!/bin/sh + +echo "Further liberating OpenJDK..." + +# PRx denotes bug x in the IcedTea bug database (http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=x) +# Sx denotes bug x in the Sun bug database (http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=x) + +# PR146/S6713083 +# Remove binaries +rm -f \ + openjdk/jdk/test/sun/management/windows/revokeall.exe \ + openjdk/jdk/test/sun/management/jmxremote/bootstrap/linux-i586/launcher \ + openjdk/jdk/test/sun/management/jmxremote/bootstrap/solaris-sparc/launcher \ + openjdk/jdk/test/sun/management/jmxremote/bootstrap/solaris-i586/launcher + +rm -f \ + openjdk/jdk/test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/linux-i586/libLauncher.so \ + openjdk/jdk/test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-i586/libLauncher.so \ + openjdk/jdk/test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparc/libLauncher.so \ + openjdk/jdk/test/java/nio/channels/spi/SelectorProvider/inheritedChannel/lib/solaris-sparcv9/libLauncher.so \ + openjdk/jdk/test/tools/launcher/lib/i386/lib32/lib32/liblibrary.so \ + openjdk/jdk/test/tools/launcher/lib/i386/lib32/liblibrary.so \ + openjdk/jdk/test/tools/launcher/lib/sparc/lib32/lib32/liblibrary.so \ + openjdk/jdk/test/tools/launcher/lib/sparc/lib32/liblibrary.so \ + openjdk/jdk/test/tools/launcher/lib/sparc/lib64/lib64/liblibrary.so \ + openjdk/jdk/test/tools/launcher/lib/sparc/lib64/liblibrary.so + +rm -f \ + openjdk/jdk/make/tools/winver/bin/winver.exe \ + openjdk/jdk/test/java/util/Locale/data/deflocale.exe \ + openjdk/jdk/test/java/util/Locale/data/deflocale.jds3 \ + openjdk/jdk/test/java/util/Locale/data/deflocale.rhel4 \ + openjdk/jdk/test/java/util/Locale/data/deflocale.sh \ + openjdk/jdk/test/java/util/Locale/data/deflocale.sol10 \ + openjdk/jdk/test/java/util/Locale/data/deflocale.winvista \ + openjdk/jdk/test/java/util/Locale/data/deflocale.winxp \ + +# Remove test sources with questionable license headers. +rm -f \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en_IE.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4165815Test.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4177489_Resource_jf.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en_CA.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Getter.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4177489Test.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource2.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en_US.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4083270Test.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource3_en.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4177489_Resource.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Test.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Resource2_en_US.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4168625Class.java \ + openjdk/jdk/test/java/util/Locale/Bug4175998Test.java \ + openjdk/jdk/test/java/util/ResourceBundle/RBTestFmwk.java \ + openjdk/jdk/test/java/util/ResourceBundle/TestResource_fr.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4179766Resource.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4179766Getter.java \ + openjdk/jdk/test/java/util/ResourceBundle/Bug4179766Class.java \ + openjdk/jdk/test/java/util/ResourceBundle/TestResource.java \ + openjdk/jdk/test/java/util/ResourceBundle/FakeTestResource.java \ + openjdk/jdk/test/java/util/ResourceBundle/TestResource_de.java \ + openjdk/jdk/test/java/util/ResourceBundle/TestBug4179766.java \ + openjdk/jdk/test/java/util/ResourceBundle/TestResource_fr_CH.java \ + openjdk/jdk/test/java/util/ResourceBundle/ResourceBundleTest.java \ + openjdk/jdk/test/java/util/ResourceBundle/TestResource_it.java \ + openjdk/jdk/test/java/util/Locale/PrintDefaultLocale.java \ + openjdk/jdk/test/java/util/Locale/LocaleTest.java \ + openjdk/jdk/test/java/util/Locale/LocaleTestFmwk.java \ + openjdk/jdk/test/java/util/Locale/Bug4184873Test.java \ + openjdk/jdk/test/sun/text/resources/LocaleDataTest.java + +# Remove J2DBench sources, some of which have questionable license +# headers. +rm -rf \ + openjdk/jdk/src/share/demo/java2d/J2DBench + +# BEGIN Debian/Ubuntu additions + +# binary files +rm -f \ + openjdk/jdk/test/sun/net/idn/nfscis.spp + +# has w3c copyright. license to be checked / needs checking after decoding +rm -f \ + openjdk/jdk/test/javax/xml/crypto/dsig/data/xml-stylesheet \ + openjdk/jdk/test/javax/xml/crypto/dsig/data/xml-stylesheet.b64 + +# TODO +#$ find openjdk -name '*.jar' -o -name '*.class'|grep -v test + +# PR140, S6695776 +# Also see patches/icedtea-jscheme.patch +rm -rf openjdk/corba/src/share/classes/com/sun/tools/corba/se/logutil/lib +rm -rf openjdk/corba/src/share/classes/com/sun/tools/corba/se/logutil/scripts + +# PR139, S6710791 +rm -f \ + openjdk/hotspot/agent/kk/src/share/lib/maf-1_0.jar \ + openjdk/hotspot/agent/kk/src/share/lib/jlfgr-1_0.jar \ + +# PR157, S6713083 +rm -f \ + openjdk/jdk/src/share/classes/java/lang/instrument/package.html + +# END Debian/Ubuntu additions + From A.Hughes at dcs.shef.ac.uk Thu Jul 3 08:21:05 2008 From: A.Hughes at dcs.shef.ac.uk (Andrew Hughes) Date: Thu, 3 Jul 2008 16:21:05 +0100 Subject: FYI: Fix build paths Message-ID: <20080703152105.GA380@omega.dcs.shef.ac.uk> It seems I'm the only one who uses an out-of-srcdir build... because more things keep creeping in. ChangeLog: 2008-07-03 Andrew John Hughes * Makefile.am: Fix use of abs_top_srcdir for CACAO and lack of path for HACKING. * Makefile.in: Regenerated. * acinclude.m4: Fix CACAO path as above. * configure: Regenerated. -- A. :) Room 122, Department of Computer Science http://www.dcs.shef.ac.uk/~andrew PGP Key: 0D118B89 (http://subkeys.pgp.net) Fingerprint: 711E 2AC8 72FE F5CE BB0C 0637 9678 5E51 0D11 8B89 -------------- next part -------------- diff -r 98c884841679 Makefile.am --- a/Makefile.am Thu Jul 03 01:37:42 2008 +0200 +++ b/Makefile.am Thu Jul 03 16:02:26 2008 +0100 @@ -462,7 +462,7 @@ stamps/patch.stamp: stamps/patch-fsg.sta then \ echo Applying $$p ; \ $(PATCH) -l -p0 < $(abs_top_srcdir)/$$p ; \ - if ! grep "^\* $$(basename $$p)" HACKING >> stamps/patch.stamp.tmp ; \ + if ! grep "^\* $$(basename $$p)" $(abs_top_srcdir)/HACKING >> stamps/patch.stamp.tmp ; \ then \ echo "* $$(basename $$p): UNDOCUMENTED" >> stamps/patch.stamp.tmp ; \ fi ; \ @@ -508,7 +508,7 @@ stamps/patch-fsg.stamp: stamps/extract.s then \ echo Applying $$p ; \ $(PATCH) -l -p0 < $(abs_top_srcdir)/$$p ; \ - if ! grep "^\* $$(basename $$p)" HACKING >> stamps/patch-fsg.stamp.tmp ; \ + if ! grep "^\* $$(basename $$p)" $(abs_top_srcdir)/HACKING >> stamps/patch-fsg.stamp.tmp ; \ then \ echo "* $$(basename $$p): UNDOCUMENTED" >> stamps/patch-fsg.stamp.tmp ; \ fi ; \ @@ -1095,10 +1095,10 @@ if !USE_SYSTEM_CACAO if !USE_SYSTEM_CACAO cd cacao/cacao-$(CACAO_VERSION) ; \ ./configure \ - --prefix=$(abs_top_srcdir)/cacao/install \ + --prefix=$(abs_top_builddir)/cacao/install \ --with-java-runtime-library=openjdk \ - --with-java-runtime-library-prefix=$(abs_top_srcdir)/openjdk \ - --with-java-runtime-library-classes=$(abs_top_srcdir)/lib/rt \ + --with-java-runtime-library-prefix=$(abs_top_builddir)/openjdk \ + --with-java-runtime-library-classes=$(abs_top_builddir)/lib/rt \ --enable-jre-layout ; \ make install endif diff -r 98c884841679 Makefile.in --- a/Makefile.in Thu Jul 03 01:37:42 2008 +0200 +++ b/Makefile.in Thu Jul 03 16:02:26 2008 +0100 @@ -1492,10 +1492,10 @@ stamps/cacao.stamp: stamps/extract.stamp stamps/cacao.stamp: stamps/extract.stamp stamps/rt-class-files.stamp @USE_SYSTEM_CACAO_FALSE@ cd cacao/cacao-$(CACAO_VERSION) ; \ @USE_SYSTEM_CACAO_FALSE@ ./configure \ - at USE_SYSTEM_CACAO_FALSE@ --prefix=$(abs_top_srcdir)/cacao/install \ + at USE_SYSTEM_CACAO_FALSE@ --prefix=$(abs_top_builddir)/cacao/install \ @USE_SYSTEM_CACAO_FALSE@ --with-java-runtime-library=openjdk \ - at USE_SYSTEM_CACAO_FALSE@ --with-java-runtime-library-prefix=$(abs_top_srcdir)/openjdk \ - at USE_SYSTEM_CACAO_FALSE@ --with-java-runtime-library-classes=$(abs_top_srcdir)/lib/rt \ + at USE_SYSTEM_CACAO_FALSE@ --with-java-runtime-library-prefix=$(abs_top_builddir)/openjdk \ + at USE_SYSTEM_CACAO_FALSE@ --with-java-runtime-library-classes=$(abs_top_builddir)/lib/rt \ @USE_SYSTEM_CACAO_FALSE@ --enable-jre-layout ; \ @USE_SYSTEM_CACAO_FALSE@ make install mkdir -p stamps diff -r 98c884841679 acinclude.m4 --- a/acinclude.m4 Thu Jul 03 01:37:42 2008 +0200 +++ b/acinclude.m4 Thu Jul 03 16:02:26 2008 +0100 @@ -734,7 +734,7 @@ AC_DEFUN([AC_CHECK_WITH_CACAO_HOME], AM_CONDITIONAL(USE_SYSTEM_CACAO, true) ], [ - CACAO_IMPORT_PATH="\$(abs_top_srcdir)/cacao/install" + CACAO_IMPORT_PATH="\$(abs_top_builddir)/cacao/install" AM_CONDITIONAL(USE_SYSTEM_CACAO, false) ]) AC_MSG_RESULT(${CACAO_IMPORT_PATH}) diff -r 98c884841679 configure --- a/configure Thu Jul 03 01:37:42 2008 +0200 +++ b/configure Thu Jul 03 16:02:26 2008 +0100 @@ -8105,7 +8105,7 @@ fi else - CACAO_IMPORT_PATH="\$(abs_top_srcdir)/cacao/install" + CACAO_IMPORT_PATH="\$(abs_top_builddir)/cacao/install" if false; then USE_SYSTEM_CACAO_TRUE= USE_SYSTEM_CACAO_FALSE='#' From twisti at complang.tuwien.ac.at Thu Jul 3 08:43:28 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Thu, 03 Jul 2008 17:43:28 +0200 Subject: FYI: Fix build paths In-Reply-To: <20080703152105.GA380@omega.dcs.shef.ac.uk> References: <20080703152105.GA380@omega.dcs.shef.ac.uk> Message-ID: <1215099808.22045.4.camel@cthalinger> On Thu, 2008-07-03 at 16:21 +0100, Andrew Hughes wrote: > It seems I'm the only one who uses an out-of-srcdir build... > because more things keep creeping in. I will change that. Thanks for fixing it. - twisti From fitzsim at redhat.com Thu Jul 3 16:17:11 2008 From: fitzsim at redhat.com (Thomas Fitzsimmons) Date: Thu, 03 Jul 2008 19:17:11 -0400 Subject: LiveConnect and IcedTea 6 Message-ID: Hi, I've merged LiveConnect support from the IcedTea 7 branch to icedtea6 and fixed a few things. Now people will be able to build and experiment with IcedTeaPlugin.so much more easily. Here are instructions for Fedora 9 users: 1) yum install xulrunner-devel-unstable 2) ./configure --with-openjdk --enable-liveconnect 3) make 4) ln -sf `pwd`/openjdk/control/build/linux-i586/j2sdk-image/jre/lib/i386/IcedTeaPlugin.so ~/.mozilla/plugins 5) Browse to about:plugins and confirm that IcedTeaPlugin is listed The plugin is still unstable and should NOT be enabled in distribution packages. Tom From gk at spreadshirt.net Thu Jul 3 22:50:32 2008 From: gk at spreadshirt.net (=?ISO-8859-1?Q?Guido_K=E4mper?=) Date: Fri, 4 Jul 2008 07:50:32 +0200 Subject: IcedTea6 1.2 Released! In-Reply-To: <4857D87A.7070406@redhat.com> References: <483F0563.2080103@redhat.com> <17c6771e0805291317r512c6cc6xdd610f26013cb41c@mail.gmail.com> <1213705038.3156.11.camel@dijkstra.wildebeest.org> <4857D87A.7070406@redhat.com> Message-ID: <776D35B0-C8A7-4A02-9521-9730C622E25A@spreadshirt.net> Hi Anthony, I currently saw the message "IcedTea is served" on my screen, after a few installation problems. :-) Now I am looking forward to creating nice sound applications. Did you have some luck integrating the DSSI classes? If yes, did you implement it in a special branch and is it possible to access this implementation? thank you, Guido Am 17.06.2008 um 17:30 schrieb Anthony Green: > Mark Wielaard wrote: >> Hi Guido, >> >> On Tue, 2008-06-17 at 13:21 +0200, Guido K?mper wrote: >> >>> congratulations to the new version! >>> >> >> Thanks! >> >> >>> One question: The gnu classpath has a support for using DSSI >>> instruments in the sound libraries. Are there plans to include >>> this into the IcedTea platform - or is it already included? That >>> would be really cool:) >>> >> >> No it hasn't been integrated yet. All midi handling is currently >> being >> done through Gervill, a software synthesizer. This has as advantage >> (or >> disadvantage, depending on your view), that no direct integration >> with >> the native platform soft synths needs to be done. >> >> I have CCed Anthony Green, who originally wrote the DSSI backend >> for GNU >> Classpath, to see if he might be interested in porting it to IcedTea. >> Hi Anthony! :) >> > Hi Mark. The DSSI providers were written using JNI, so they should > be easy to port over to IcedTea. I'm happy to try. It will give me > something to do on my flight today. > > AG > sprd.net AG Karl-Heine-Stra?e 97 04229 Leipzig Germany Vorstand/Executive Board: Jana Eggers (Vorsitzende/CEO), Matthias Spie?, Andreas Schr?teler Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Lukasz Gadowski Handelsregister/Trade Register: Amtsgericht Leipzig, HRB 22478 Umsatzsteuer-IdentNummer/VAT-ID: DE 8138 7149 4 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080704/fcd7fb45/attachment.html From gk at spreadshirt.net Thu Jul 3 23:04:08 2008 From: gk at spreadshirt.net (=?ISO-8859-1?Q?Guido_K=E4mper?=) Date: Fri, 4 Jul 2008 08:04:08 +0200 Subject: IcedTea6 compilation problems In-Reply-To: <1214379855.5507.7.camel@dijkstra.wildebeest.org> References: <50163.91.65.81.227.1214374375.squirrel@mail.spreadomat.net> <1214379855.5507.7.camel@dijkstra.wildebeest.org> Message-ID: <42DDD69E-B464-496D-8927-4333413AC70C@spreadshirt.net> Thanks for all the hints, the solution was to not write the whole arguments list with a /bin/cat after the compile statement, but use the -@ option of jar. David Walluck had the idea, thanks! eg. less rt_jar_list | jar c0mf ......manifest.tmp ......rt-orig.jar -..further options -@ or jar c0mf .....manifest.tmp ......rt-orig.jar @rt_jar_list -..further options for details see man pages of jar command. Maybe the @File command should be included in the make files. cu, Guido Am 25.06.2008 um 09:44 schrieb Mark Wielaard: > Hi Guido, > > On Wed, 2008-06-25 at 08:12 +0200, Guido K??mper wrote: >> I tried to compile icedtea6 and ran into the following problem. Can >> someone give me a hint, how I can avoid the "Argument list too long" >> error? The best would be without recompiling the kernel :-) I am >> trying to >> compile it on an Ubuntu OS, installation of gcc 4.3.0 before was very >> smooth. > > Use a real shell like bash. Ubuntu seems to install some shell by > default (dash?) that has some limitations like the above. > > That said, we should have a configure script to detect what jar > utility > is installed and/or what the command line argument length is and do > the > right thing of course. > > Cheers, > > Mark > sprd.net AG Karl-Heine-Stra?e 97 04229 Leipzig Germany Vorstand/Executive Board: Jana Eggers (Vorsitzende/CEO), Matthias Spie?, Andreas Schr?teler Aufsichtsratsvorsitzender/Chairman of the Supervisory Board: Lukasz Gadowski Handelsregister/Trade Register: Amtsgericht Leipzig, HRB 22478 Umsatzsteuer-IdentNummer/VAT-ID: DE 8138 7149 4 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080704/cfed4982/attachment.html From doko at ubuntu.com Fri Jul 4 00:59:52 2008 From: doko at ubuntu.com (Matthias Klose) Date: Fri, 04 Jul 2008 09:59:52 +0200 Subject: IcedTea6 compilation problems In-Reply-To: <1214379855.5507.7.camel@dijkstra.wildebeest.org> References: <50163.91.65.81.227.1214374375.squirrel@mail.spreadomat.net> <1214379855.5507.7.camel@dijkstra.wildebeest.org> Message-ID: <486DD878.6040708@ubuntu.com> Mark Wielaard schrieb: > Hi Guido, > > On Wed, 2008-06-25 at 08:12 +0200, Guido K??mper wrote: >> I tried to compile icedtea6 and ran into the following problem. Can >> someone give me a hint, how I can avoid the "Argument list too long" >> error? The best would be without recompiling the kernel :-) I am trying to >> compile it on an Ubuntu OS, installation of gcc 4.3.0 before was very >> smooth. > > Use a real shell like bash. Ubuntu seems to install some shell by > default (dash?) that has some limitations like the above. it's a POSIX shell. On the other hand Ubuntu's gjar has the @ option available. Maybe we could just conditionalize applying this patch? Matthias From gnu_andrew at member.fsf.org Mon Jul 7 03:34:58 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Jul 2008 11:34:58 +0100 Subject: A Cry For Sanity In-Reply-To: <17c6771e0806260356t798ceaa7jdc7df61e57f2ad84@mail.gmail.com> References: <17c6771e0806251529pf786b16o13a7c931ef952c1e@mail.gmail.com> <486362CB.9020009@redhat.com> <17c6771e0806260242v6eb22102vfe1a72c1fdade842@mail.gmail.com> <486367E1.6070902@redhat.com> <17c6771e0806260308n659e3435o5b1b1cdb1fddf000@mail.gmail.com> <486373B2.8000401@redhat.com> <17c6771e0806260356t798ceaa7jdc7df61e57f2ad84@mail.gmail.com> Message-ID: <17c6771e0807070334habc6ce2o6148466311a871d2@mail.gmail.com> 2008/6/26 Andrew John Hughes : > 2008/6/26 Andrew Haley : >> Andrew John Hughes wrote: >>> 2008/6/26 Andrew Haley : >>>> Andrew John Hughes wrote: >>>>> 2008/6/26 Andrew Haley : >>>>>> Andrew John Hughes wrote: >>>>>>> Is there a particular reason we keep generated files (configure, >>>>>>> aclocal.m4, Makefile.in) in the repository? I ideally like to remove >>>>>>> them for the following reasons: >>>>>> It's much easier for a person who just wants to download and build >>>>>> not to have to regenerate the auto* scripts. autotools are notoriously >>>>>> sensitive to having the exact versions installed. If we check in the >>>>>> generated scripts they do not have to run auto* locally. It's about >>>>>> lowering the barrier to entry: if we don't check in the generated >>>>>> scripts it'll be much harder for people to get started. >>>>>> >>>>> It's this sensitivity that also swings it the other way from me; I've >>>>> had to be selective >>>>> on which systems I alter IcedTea to avoid drastically changing the autogenerated >>>>> files due to version changes in the autotools. >>>> So what? As long as the files still work that doesn't matter. No-one >>>> needs to look at the diffs between autogenerated files. >>> >>> But they became a problem when the real diffs are obscured and we don't have >>> any other form of patch announcement than Mercurial commit messages. >> >> That's a fair point. We are not handling patch mailings well. >> >>>>> As for people getting started, hacking on IcedTea pretty much >>>>> requires having the autotools as most of the changes are to >>>>> Makefile.am and configure.ac. If you're just talking about >>>>> building, then that's why we have releases. >> >>>> That's a bad attitude problem: the source tree is for us developers, >>>> and mere mortals get to use the releases we've handed down from >>>> Mount Olympus. >> >>> I'm not going to anything like that extreme. I'm merely pointing >>> out that someone choosing to go to the extra length of downloading >>> the code using a version-control tool and who is prepared to work >>> with the 'bleeding-edge' would probably expect a little more trouble >>> in doing so. In the process, they would learn the skills needed to >>> contribute to the project itself. In contrast, we spend a lot of >>> time perfecting a release as much as possible to ensure that there >>> is as little trouble as possible. >> >> Maybe. That does sound to me like the "it's hard for us to develop, >> so it doesn't matter if it's hard for people to build too." >> > > The intention was to make the common case the easiest, and the other cases > easy enough :) > >>> This isn't about segregating users, but about making things easier >>> for the majority using a particular method of source code >>> distribution. For a release, I believe this is end users and >>> distros who want to build the code with as little trouble as >>> possible. With the code in the VCS, this is the developers and >>> prospective developers. >> >> OK, I'll give you this: if the *majority* of people who use Mercurial >> are those who have to regenerate and check in the results, then the >> generated scripts should go. >> > > I believe that the majority by far are people actively hammering those > two files in the IcedTea repository rather than the 'common builder' who > just wants to download and try the latest and greatest. We have very > little overhead in producing a release, so producing these regularly > and keeping the tree free of generated autotools files seems the best > option. > > IcedTea is a fairly unique project. Not many projects effectively result > in two files getting changed by just about each and every patch. I think > this is also the cause of some VCS issues we have, but not all. > >> Andrew. >> >> > > > > -- > Andrew :-) > > 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 > [Trying again as the removed generated files are so big the patch is too big for the mailing list] So shall I commit this? 2008-07-07 Andrew John Hughes * ChangeLog: Fix typos. * Makefile.in, * configure, * aclocal.m4: Removed. -- Andrew :-) 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 doko at ubuntu.com Mon Jul 7 03:41:40 2008 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 07 Jul 2008 12:41:40 +0200 Subject: building the zero port on anything else than powerpc? Message-ID: <4871F2E4.4060505@ubuntu.com> Trying to build icedtea6 on arm-linuxeabi and ia64-linux using gcj-4.3 as the stage1 compiler, I'm getting errors in the stage2 build (using the existing fedora packages as stage1 leads to the same error). With an up to date icedtea checkout I see the error shown in zero-log1.txt, applying the float and double diffs found in patches/icedtea-ecj.patch to the openjdk directory as well (see float-double.diff), the build continues further until I see the very same exception in a call to javah (zero-log2.txt). Maybe this is a platform error (as zero seems to build at least on ia64 on Fedora). Do others see these failures as well, or where does the zero port succeed to build? Matthias -------------- next part -------------- A non-text attachment was scrubbed... Name: float-double.diff Type: text/x-diff Size: 2391 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080707/e91245f2/attachment.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: zero-log1.txt Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080707/e91245f2/attachment.txt -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: zero-log2.txt Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080707/e91245f2/attachment-0001.txt From twisti at complang.tuwien.ac.at Mon Jul 7 04:06:22 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Mon, 07 Jul 2008 13:06:22 +0200 Subject: building the zero port on anything else than powerpc? In-Reply-To: <4871F2E4.4060505@ubuntu.com> References: <4871F2E4.4060505@ubuntu.com> Message-ID: <1215428782.10371.36.camel@cthalinger> On Mon, 2008-07-07 at 12:41 +0200, Matthias Klose wrote: > An exception has occurred in the compiler (1.6.0-internal). Please > file a bug at the Java Developer Connection > (http://java.sun.com/webapps/bugreport) after checking the Bug Parade > for duplicates. Include your program and the following diagnostic in > your report. Thank you. > java.lang.IllegalArgumentException: disparate values I know that one very well from different architectures, e.g. Alpha. Patching the MIN/MAX values does not fix this bug, ?because the represented floating point values keep the same, but just helps ECJ to actually being able to compile the source files. Getting this exception normally means there is somewhere a bug in the floating point code, as these values are corner cases. But sometimes, as in my Alpha situation, the bug is not in the VM but in the Linux kernel and I can't fix it :-( - twisti From gnu_andrew at member.fsf.org Mon Jul 7 03:21:26 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Mon, 7 Jul 2008 11:21:26 +0100 Subject: A Cry For Sanity In-Reply-To: <17c6771e0806260356t798ceaa7jdc7df61e57f2ad84@mail.gmail.com> References: <17c6771e0806251529pf786b16o13a7c931ef952c1e@mail.gmail.com> <486362CB.9020009@redhat.com> <17c6771e0806260242v6eb22102vfe1a72c1fdade842@mail.gmail.com> <486367E1.6070902@redhat.com> <17c6771e0806260308n659e3435o5b1b1cdb1fddf000@mail.gmail.com> <486373B2.8000401@redhat.com> <17c6771e0806260356t798ceaa7jdc7df61e57f2ad84@mail.gmail.com> Message-ID: <17c6771e0807070321r5edb115et5d91ec5906e758ad@mail.gmail.com> 2008/6/26 Andrew John Hughes : > 2008/6/26 Andrew Haley : >> Andrew John Hughes wrote: >>> 2008/6/26 Andrew Haley : >>>> Andrew John Hughes wrote: >>>>> 2008/6/26 Andrew Haley : >>>>>> Andrew John Hughes wrote: >>>>>>> Is there a particular reason we keep generated files (configure, >>>>>>> aclocal.m4, Makefile.in) in the repository? I ideally like to remove >>>>>>> them for the following reasons: >>>>>> It's much easier for a person who just wants to download and build >>>>>> not to have to regenerate the auto* scripts. autotools are notoriously >>>>>> sensitive to having the exact versions installed. If we check in the >>>>>> generated scripts they do not have to run auto* locally. It's about >>>>>> lowering the barrier to entry: if we don't check in the generated >>>>>> scripts it'll be much harder for people to get started. >>>>>> >>>>> It's this sensitivity that also swings it the other way from me; I've >>>>> had to be selective >>>>> on which systems I alter IcedTea to avoid drastically changing the autogenerated >>>>> files due to version changes in the autotools. >>>> So what? As long as the files still work that doesn't matter. No-one >>>> needs to look at the diffs between autogenerated files. >>> >>> But they became a problem when the real diffs are obscured and we don't have >>> any other form of patch announcement than Mercurial commit messages. >> >> That's a fair point. We are not handling patch mailings well. >> >>>>> As for people getting started, hacking on IcedTea pretty much >>>>> requires having the autotools as most of the changes are to >>>>> Makefile.am and configure.ac. If you're just talking about >>>>> building, then that's why we have releases. >> >>>> That's a bad attitude problem: the source tree is for us developers, >>>> and mere mortals get to use the releases we've handed down from >>>> Mount Olympus. >> >>> I'm not going to anything like that extreme. I'm merely pointing >>> out that someone choosing to go to the extra length of downloading >>> the code using a version-control tool and who is prepared to work >>> with the 'bleeding-edge' would probably expect a little more trouble >>> in doing so. In the process, they would learn the skills needed to >>> contribute to the project itself. In contrast, we spend a lot of >>> time perfecting a release as much as possible to ensure that there >>> is as little trouble as possible. >> >> Maybe. That does sound to me like the "it's hard for us to develop, >> so it doesn't matter if it's hard for people to build too." >> > > The intention was to make the common case the easiest, and the other cases > easy enough :) > >>> This isn't about segregating users, but about making things easier >>> for the majority using a particular method of source code >>> distribution. For a release, I believe this is end users and >>> distros who want to build the code with as little trouble as >>> possible. With the code in the VCS, this is the developers and >>> prospective developers. >> >> OK, I'll give you this: if the *majority* of people who use Mercurial >> are those who have to regenerate and check in the results, then the >> generated scripts should go. >> > > I believe that the majority by far are people actively hammering those > two files in the IcedTea repository rather than the 'common builder' who > just wants to download and try the latest and greatest. We have very > little overhead in producing a release, so producing these regularly > and keeping the tree free of generated autotools files seems the best > option. > > IcedTea is a fairly unique project. Not many projects effectively result > in two files getting changed by just about each and every patch. I think > this is also the cause of some VCS issues we have, but not all. > >> Andrew. >> >> > > > > -- > Andrew :-) > > 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 > So shall I commit this? 2008-07-07 Andrew John Hughes * ChangeLog: Fix typos. * Makefile.in, * configure, * aclocal.m4: Removed. -- Andrew :-) 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 -------------- next part -------------- A non-text attachment was scrubbed... Name: sanity_fix.diff Type: text/x-patch Size: 514188 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080707/531a77b9/attachment-0001.bin From doko at ubuntu.com Mon Jul 7 06:32:12 2008 From: doko at ubuntu.com (Matthias Klose) Date: Mon, 07 Jul 2008 15:32:12 +0200 Subject: icedtea-6 builds based on cacao on armel and powerpc Message-ID: <48721ADC.3090202@ubuntu.com> Trying to build current icedtea6 with --enable-cacao; at least on arm-linuxeabi as setup by Debian, I had to configure with --enable-softfloat; the powerpc build succeeds. hangs in the mauve testsuite, the jtreg results can be found at http://people.ubuntu.com/~doko/tmp/jtreg-cacao-powerpc.txt the armel build fails: http://people.ubuntu.com/~doko/tmp/cacao-armel-build.log Matthias From twisti at complang.tuwien.ac.at Mon Jul 7 06:52:53 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Mon, 07 Jul 2008 15:52:53 +0200 Subject: icedtea-6 builds based on cacao on armel and powerpc In-Reply-To: <48721ADC.3090202@ubuntu.com> References: <48721ADC.3090202@ubuntu.com> Message-ID: <1215438773.10371.59.camel@cthalinger> On Mon, 2008-07-07 at 15:32 +0200, Matthias Klose wrote: > Trying to build current icedtea6 with --enable-cacao; at least on arm-linuxeabi > as setup by Debian, I had to configure with --enable-softfloat; the powerpc > build succeeds. hangs in the mauve testsuite, the jtreg results can be found at > http://people.ubuntu.com/~doko/tmp/jtreg-cacao-powerpc.txt That hangs may be fixed with the next release, which I'm currently preparing. I will try that myself. > the armel build fails: http://people.ubuntu.com/~doko/tmp/cacao-armel-build.log That may be a real CACAO bug (JIT bug) or a cache issue (I have seen too much of these recently on ARM). We should try to debug this. - twisti From twisti at complang.tuwien.ac.at Tue Jul 8 06:52:20 2008 From: twisti at complang.tuwien.ac.at (Christian Thalinger) Date: Tue, 08 Jul 2008 15:52:20 +0200 Subject: CACAO 0.99.2 released. Message-ID: <1215525140.4030.18.camel@cthalinger> CACAO 0.99.2 released. This is a bug-fix release. Here is a short list of the most important changes: * Rewrite of atomic instructions code. This fixes problems with AWT/Swing programs with OpenJDK. * Fixed PR83, PR89. CACAO uses GNU Classpath as default Java runtime library and supports upstream releases or CVS snapshots. This release requires GNU Classpath 0.96 or higher to build and was tested against GNU Classpath 0.97.2 on a number of various platforms. CACAO's ./configure has some options for Java runtime configuration, namely: --with-java-runtime-library= --with-java-runtime-library-prefix= --with-java-runtime-library-classes= --with-java-runtime-library-libdir= For detailed information, use ./configure --help. Currently supported JIT compiler architectures are: * alpha * arm * i386 * m68k (broken) * mips * powerpc * powerpc64 * s390 * sparc64 * x86_64 Information about working applications and some screenshots can be found on http://www.cacaovm.org/. The CACAO wiki can be found here: http://c1.complang.tuwien.ac.at/cacaowiki/ The CACAO mailing lists can be found here: http://c1.complang.tuwien.ac.at/mailman/listinfo/ Nightly test runs with CACAO Mercurial tip, GNU Classpath CVS head and Mauve CVS head can be found on http://www.complang.tuwien.ac.at/cacaojvm/jvmtester/. CACAO 0.99.2 can be downloaded from http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-0.99.2/ File : cacao-0.99.2.tar.gz md5sum : a2865f47535f6dc3def268c0055ff20a sha1sum: 2985f77415038d26a8e56bf0046ab8dae79a88da File : cacao-0.99.2.tar.bz2 md5sum : 912e353a26c88ba5f5f59ebb9f688e2f sha1sum: 9b1f25bff55c95d3c6ffef576a2d35a799c2d521 Enjoy! CACAOVM - Verein zur Foerderung der freien virtuellen Maschine CACAO cacao at cacaovm.org From gbenson at redhat.com Tue Jul 8 11:52:41 2008 From: gbenson at redhat.com (Gary Benson) Date: Tue, 8 Jul 2008 14:52:41 -0400 Subject: building the zero port on anything else than powerpc? In-Reply-To: <4871F2E4.4060505@ubuntu.com> References: <4871F2E4.4060505@ubuntu.com> Message-ID: <20080708185241.GD10748@devserv.devel.redhat.com> Can you give me access to a machine that's showing this? I'd like to have a little look... Cheers, Gary Matthias Klose wrote: > Trying to build icedtea6 on arm-linuxeabi and ia64-linux using > gcj-4.3 as the stage1 compiler, I'm getting errors in the stage2 > build (using the existing fedora packages as stage1 leads to the > same error). > > With an up to date icedtea checkout I see the error shown in > zero-log1.txt, applying the float and double diffs found in > patches/icedtea-ecj.patch to the openjdk directory as well (see > float-double.diff), the build continues further until I see the very > same exception in a call to javah (zero-log2.txt). > > Maybe this is a platform error (as zero seems to build at least on > ia64 on Fedora). Do others see these failures as well, or where does > the zero port succeed to build? > > Matthias -- http://gbenson.net/ From aph at redhat.com Tue Jul 8 13:30:25 2008 From: aph at redhat.com (Andrew Haley) Date: Tue, 08 Jul 2008 21:30:25 +0100 Subject: building the zero port on anything else than powerpc? In-Reply-To: <1215428782.10371.36.camel@cthalinger> References: <4871F2E4.4060505@ubuntu.com> <1215428782.10371.36.camel@cthalinger> Message-ID: <4873CE61.6080907@redhat.com> Christian Thalinger wrote: > On Mon, 2008-07-07 at 12:41 +0200, Matthias Klose wrote: >> An exception has occurred in the compiler (1.6.0-internal). Please >> file a bug at the Java Developer Connection >> (http://java.sun.com/webapps/bugreport) after checking the Bug Parade >> for duplicates. Include your program and the following diagnostic in >> your report. Thank you. >> java.lang.IllegalArgumentException: disparate values > > I know that one very well from different architectures, e.g. Alpha. > Patching the MIN/MAX values does not fix this bug, ?because the > represented floating point values keep the same, but just helps ECJ to > actually being able to compile the source files. Yeah. IMO we shouldn't patch the ARM build in this way, we should fix the underlying bug. Andrew. From gnu_andrew at member.fsf.org Tue Jul 8 14:39:00 2008 From: gnu_andrew at member.fsf.org (Andrew John Hughes) Date: Tue, 8 Jul 2008 22:39:00 +0100 Subject: CACAO 0.99.2 released. In-Reply-To: <1215525140.4030.18.camel@cthalinger> References: <1215525140.4030.18.camel@cthalinger> Message-ID: <17c6771e0807081439m4080278cy5ca41793d2f18801@mail.gmail.com> On 08/07/2008, Christian Thalinger wrote: > CACAO 0.99.2 released. > > This is a bug-fix release. Here is a short list of the most important > changes: > > * Rewrite of atomic instructions code. This fixes problems with > AWT/Swing programs with OpenJDK. > * Fixed PR83, PR89. > > CACAO uses GNU Classpath as default Java runtime library and supports > upstream releases or CVS snapshots. This release requires GNU > Classpath 0.96 or higher to build and was tested against GNU Classpath > 0.97.2 on a number of various platforms. > > CACAO's ./configure has some options for Java runtime configuration, > namely: > > --with-java-runtime-library= > --with-java-runtime-library-prefix= > --with-java-runtime-library-classes= > --with-java-runtime-library-libdir= > > For detailed information, use ./configure --help. > > Currently supported JIT compiler architectures are: > > * alpha > * arm > * i386 > * m68k (broken) > * mips > * powerpc > * powerpc64 > * s390 > * sparc64 > * x86_64 > > Information about working applications and some screenshots can be > found on http://www.cacaovm.org/. > > The CACAO wiki can be found here: > http://c1.complang.tuwien.ac.at/cacaowiki/ > > The CACAO mailing lists can be found here: > http://c1.complang.tuwien.ac.at/mailman/listinfo/ > > Nightly test runs with CACAO Mercurial tip, GNU Classpath CVS head and > Mauve CVS head can be found on > http://www.complang.tuwien.ac.at/cacaojvm/jvmtester/. > > CACAO 0.99.2 can be downloaded from > http://www.complang.tuwien.ac.at/cacaojvm/download/cacao-0.99.2/ > > File : cacao-0.99.2.tar.gz > md5sum : a2865f47535f6dc3def268c0055ff20a > sha1sum: 2985f77415038d26a8e56bf0046ab8dae79a88da > > File : cacao-0.99.2.tar.bz2 > md5sum : 912e353a26c88ba5f5f59ebb9f688e2f > sha1sum: 9b1f25bff55c95d3c6ffef576a2d35a799c2d521 > > Enjoy! > > CACAOVM - Verein zur Foerderung der freien virtuellen Maschine CACAO > cacao at cacaovm.org > > Congratulations on the release! -- Andrew :-) 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 David.Herron at Sun.COM Tue Jul 8 15:18:57 2008 From: David.Herron at Sun.COM (David Herron) Date: Tue, 08 Jul 2008 15:18:57 -0700 Subject: [Fwd: DLJ bundles for 5.0u16 and 6u7 have been posted on jdk-distros.dev.java.net] Message-ID: <4873E7D1.2090802@sun.com> FYI -------------- next part -------------- An embedded message was scrubbed... From: David Herron Subject: DLJ bundles for 5.0u16 and 6u7 have been posted on jdk-distros.dev.java.net Date: Tue, 08 Jul 2008 15:15:07 -0700 Size: 5382 Url: http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080708/e9fd6941/attachment.mht From mark at klomp.org Wed Jul 9 05:42:22 2008 From: mark at klomp.org (Mark Wielaard) Date: Wed, 09 Jul 2008 14:42:22 +0200 Subject: [Fwd: DLJ bundles for 5.0u16 and 6u7 have been posted on jdk-distros.dev.java.net] In-Reply-To: <4873E7D1.2090802@sun.com> References: <4873E7D1.2090802@sun.com> Message-ID: <1215607342.21015.3.camel@dijkstra.wildebeest.org> Hi David, This mentions: 6u7: http://java.sun.com/javase/6/webnotes/ReleaseNotes.html This release contains fixes for one or more security vulnerabilities. For more information, please see Sun Alerts 238687, 238628, 238965, 238966, 238967, 238968, and 238905. So I looked at a couple of these through http://blogs.sun.com/security/ and it seems this could also affect openjdk6, icedtea, gcjwebplugin, netx, etc. Is there any more details available so we can double check and hopefully patch the affected products? Thanks, Mark From langel at redhat.com Wed Jul 9 05:45:49 2008 From: langel at redhat.com (Lillian Angel) Date: Wed, 09 Jul 2008 08:45:49 -0400 Subject: [Fwd: DLJ bundles for 5.0u16 and 6u7 have been posted on jdk-distros.dev.java.net] In-Reply-To: <1215607342.21015.3.camel@dijkstra.wildebeest.org> References: <4873E7D1.2090802@sun.com> <1215607342.21015.3.camel@dijkstra.wildebeest.org> Message-ID: <4874B2FD.9030803@redhat.com> Mark Wielaard wrote: > Hi David, > > This mentions: > 6u7: http://java.sun.com/javase/6/webnotes/ReleaseNotes.html > > This release contains fixes for one or more security vulnerabilities. > For more information, please see Sun Alerts 238687, 238628, 238965, > 238966, 238967, 238968, and 238905. > > So I looked at a couple of these through http://blogs.sun.com/security/ > and it seems this could also affect openjdk6, icedtea, gcjwebplugin, > netx, etc. Is there any more details available so we can double check > and hopefully patch the affected products? All security patches applicable to OpenJDK have been (or are being) applied to IcedTea/IcedTea6, as well as the OpenJDK packages in Fedora. Lillian From langel at redhat.com Wed Jul 9 05:54:27 2008 From: langel at redhat.com (Lillian Angel) Date: Wed, 09 Jul 2008 12:54:27 +0000 Subject: changeset in /hg/icedtea: 2008-07-08 Lillian Angel changeset c7ade552e5cc in /hg/icedtea details: http://icedtea.classpath.org/hg/icedtea?cmd=changeset;node=c7ade552e5cc description: 2008-07-08 Lillian Angel * patches/icedtea-security-updates.patch: New patch containing security updates from Sun. * Makefile.am: Added patch. * Makefile.in: Regenerated. diffstat: 5 files changed, 959 insertions(+), 4 deletions(-) ChangeLog | 7 HACKING | 1 Makefile.am | 3 Makefile.in | 6 patches/icedtea-security-updates.patch | 946 ++++++++++++++++++++++++++++++++ diffs (truncated from 1018 to 500 lines): diff -r 6afbe722b697 -r c7ade552e5cc ChangeLog --- a/ChangeLog Tue Jul 08 22:18:23 2008 +0100 +++ b/ChangeLog Wed Jul 09 08:54:22 2008 -0400 @@ -1,3 +1,10 @@ 2008-07-08 Andrew John Hughes + + * patches/icedtea-security-updates.patch: New patch containing + security updates from Sun. + * Makefile.am: Added patch. + * Makefile.in: Regenerated. + 2008-07-08 Andrew John Hughes * patches/icedtea-zero-build.patch: diff -r 6afbe722b697 -r c7ade552e5cc HACKING --- a/HACKING Tue Jul 08 22:18:23 2008 +0100 +++ b/HACKING Wed Jul 09 08:54:22 2008 -0400 @@ -40,6 +40,7 @@ The following patches are currently appl * icedtea-override-redirect-metacity.patch: Enable override redirect for Metacity window manager. * icedtea-lsb-release.patch: Generate Debian LSB file. * icedtea-rmi_amd64.patch: Build RMI binaries on all platforms not just 32-bit ones. +* icedtea-security-updates.patch: OpenJDK security patches from Sun. * icedtea-sparc.patch: Add support for GNU/Linux on SPARC (version in IcedTea includes only minimal build changes). * icedtea-sparc64-linux.patch: Fixes needed to build the SPARC port on 32-bit SPARC as used by Fedora. * icedtea-sparc-ptracefix.patch: Avoid importing asm-sparc/ptrace.h by including pt_regs directly. diff -r 6afbe722b697 -r c7ade552e5cc Makefile.am --- a/Makefile.am Tue Jul 08 22:18:23 2008 +0100 +++ b/Makefile.am Wed Jul 09 08:54:22 2008 -0400 @@ -211,7 +211,7 @@ dist-openjdk: fi; \ fi hg fclone -r jdk7-$(OPENJDK_VERSION) $(OPENJDK_URL) openjdk-dist/openjdk - find -name \\.hg* | xargs rm -rf + find openjdk-dist/ -name \\.hg* | xargs rm -rf cd openjdk-dist && $(ZIP) -r openjdk-$(OPENJDK_VERSION) openjdk/ mv openjdk-dist/openjdk-$(OPENJDK_VERSION).zip . rm -rf openjdk-dist @@ -348,6 +348,7 @@ ICEDTEA_PATCHES = \ patches/icedtea-jscheme.patch \ $(GCC_PATCH) \ $(DISTRIBUTION_PATCHES) \ + patches/icedtea-security-updates.patch \ patches/icedtea-override.patch if WITH_CACAO diff -r 6afbe722b697 -r c7ade552e5cc Makefile.in --- a/Makefile.in Tue Jul 08 22:18:23 2008 +0100 +++ b/Makefile.in Wed Jul 09 08:54:22 2008 -0400 @@ -427,8 +427,8 @@ ICEDTEA_PATCHES = patches/icedtea-copy-p patches/icedtea-override-redirect-metacity.patch \ $(ZERO_PATCHES_COND) patches/icedtea-no-bcopy.patch \ patches/icedtea-jscheme.patch $(GCC_PATCH) \ - $(DISTRIBUTION_PATCHES) patches/icedtea-override.patch \ - $(am__append_7) + $(DISTRIBUTION_PATCHES) patches/icedtea-security-updates.patch \ + patches/icedtea-override.patch $(am__append_7) # Patch OpenJDK for plug replacements and ecj. ICEDTEA_ECJ_PATCH = $(srcdir)/patches/icedtea-ecj.patch @@ -819,7 +819,7 @@ dist-openjdk: fi; \ fi hg fclone -r jdk7-$(OPENJDK_VERSION) $(OPENJDK_URL) openjdk-dist/openjdk - find -name \\.hg* | xargs rm -rf + find openjdk-dist/ -name \\.hg* | xargs rm -rf cd openjdk-dist && $(ZIP) -r openjdk-$(OPENJDK_VERSION) openjdk/ mv openjdk-dist/openjdk-$(OPENJDK_VERSION).zip . rm -rf openjdk-dist diff -r 6afbe722b697 -r c7ade552e5cc patches/icedtea-security-updates.patch --- /dev/null Thu Jan 01 00:00:00 1970 +0000 +++ b/patches/icedtea-security-updates.patch Wed Jul 09 08:54:22 2008 -0400 @@ -0,0 +1,946 @@ +--- /dev/null Mon Jun 2 08:53:52 2008 ++++ openjdk/jdk/src/share/classes/sun/management/jmxremote/LocalRMIServerSocketFactory.java Mon Jun 2 08:53:51 2008 +@@ -0,0 +1,110 @@ ++/* ++ * Copyright 2007 Sun Microsystems, Inc. All Rights Reserved. ++ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. ++ * ++ * This code is free software; you can redistribute it and/or modify it ++ * under the terms of the GNU General Public License version 2 only, as ++ * published by the Free Software Foundation. Sun designates this ++ * particular file as subject to the "Classpath" exception as provided ++ * by Sun in the LICENSE file that accompanied this code. ++ * ++ * This code is distributed in the hope that it will be useful, but WITHOUT ++ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or ++ * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License ++ * version 2 for more details (a copy is included in the LICENSE file that ++ * accompanied this code). ++ * ++ * You should have received a copy of the GNU General Public License version ++ * 2 along with this work; if not, write to the Free Software Foundation, ++ * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. ++ * ++ * Please contact Sun Microsystems, Inc., 4150 Network Circle, Santa Clara, ++ * CA 95054 USA or visit www.sun.com if you need additional information or ++ * have any questions. ++ */ ++ ++package sun.management.jmxremote; ++ ++import java.io.IOException; ++import java.net.InetAddress; ++import java.net.NetworkInterface; ++import java.net.ServerSocket; ++import java.net.Socket; ++import java.net.SocketException; ++import java.rmi.server.RMIServerSocketFactory; ++import java.util.Enumeration; ++ ++/** ++ * This RMI server socket factory creates server sockets that ++ * will only accept connection requests from clients running ++ * on the host where the RMI remote objects have been exported. ++ */ ++public final class LocalRMIServerSocketFactory implements RMIServerSocketFactory { ++ /** ++ * Creates a server socket that only accepts connection requests from ++ * clients running on the host where the RMI remote objects have been ++ * exported. ++ */ ++ public ServerSocket createServerSocket(int port) throws IOException { ++ return new ServerSocket(port) { ++ @Override ++ public Socket accept() throws IOException { ++ Socket socket = super.accept(); ++ InetAddress remoteAddr = socket.getInetAddress(); ++ final String msg = "The server sockets created using the " + ++ "LocalRMIServerSocketFactory only accept connections " + ++ "from clients running on the host where the RMI " + ++ "remote objects have been exported."; ++ // Retrieve all the network interfaces on this host. ++ Enumeration nis; ++ try { ++ nis = NetworkInterface.getNetworkInterfaces(); ++ } catch (SocketException e) { ++ try { ++ socket.close(); ++ } catch (IOException ioe) { ++ // Ignore... ++ } ++ throw new IOException(msg, e); ++ } ++ // Walk through the network interfaces to see ++ // if any of them matches the client's address. ++ // If true, then the client's address is local. ++ while (nis.hasMoreElements()) { ++ NetworkInterface ni = nis.nextElement(); ++ Enumeration addrs = ni.getInetAddresses(); ++ while (addrs.hasMoreElements()) { ++ InetAddress localAddr = addrs.nextElement(); ++ if (localAddr.equals(remoteAddr)) { ++ return socket; ++ } ++ } ++ } ++ // The client's address is remote so refuse the connection. ++ try { ++ socket.close(); ++ } catch (IOException ioe) { ++ // Ignore... ++ } ++ throw new IOException(msg); ++ } ++ }; ++ } ++ ++ /** ++ * Two LocalRMIServerSocketFactory objects ++ * are equal if they are of the same type. ++ */ ++ @Override ++ public boolean equals(Object obj) { ++ return (obj instanceof LocalRMIServerSocketFactory); ++ } ++ ++ /** ++ * Returns a hash code value for this LocalRMIServerSocketFactory. ++ */ ++ @Override ++ public int hashCode() { ++ return getClass().hashCode(); ++ } ++} +--- old/src/share/lib/management/management.properties Mon Jun 2 08:53:52 2008 ++++ openjdk/jdk/src/share/lib/management/management.properties Mon Jun 2 08:53:52 2008 +@@ -82,7 +82,7 @@ + # + # com.sun.management.snmp.interface= + # Specifies the local interface on which the SNMP agent will bind. +-# This is usefull when running on machines which have several ++# This is useful when running on machines which have several + # interfaces defined. It makes it possible to listen to a specific + # subnet accessible through that interface. + # Default for this property is "localhost". +@@ -144,6 +144,26 @@ + # + + # ++# ########## RMI connector settings for local management ########## ++# ++# com.sun.management.jmxremote.local.only=true|false ++# Default for this property is true. (Case for true/false ignored) ++# If this property is specified as true then the local JMX RMI connector ++# server will only accept connection requests from clients running on ++# the host where the out-of-the-box JMX management agent is running. ++# In order to ensure backwards compatibility this property could be ++# set to false. However, deploying the local management agent in this ++# way is discouraged because the local JMX RMI connector server will ++# accept connection requests from any client either local or remote. ++# For remote management the remote JMX RMI connector server should ++# be used instead with authentication and SSL/TLS encryption enabled. ++# ++ ++# For allowing the local management agent accept local ++# and remote connection requests use the following line ++# com.sun.management.jmxremote.local.only=false ++ ++# + # ###################### RMI SSL ############################# + # + # com.sun.management.jmxremote.ssl=true|false +No differences encountered +--- old/src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java Fri May 30 16:49:25 2008 ++++ openjdk/jaxp/src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentScannerImpl.java Fri May 30 16:49:25 2008 +@@ -185,9 +188,6 @@ + /** Load external DTD. */ + protected boolean fLoadExternalDTD = true; + +- /** Disallow doctype declaration. */ +- protected boolean fDisallowDoctype = false; +- + // state + + /** Seen doctype declaration. */ +@@ -227,8 +227,8 @@ + /** String. */ + private XMLString fString = new XMLString(); + +- public static final char [] DOCTYPE = {'D','O','C','T','Y','P','E'}; +- public static final char [] COMMENTSTRING = {'-','-'}; ++ private static final char [] DOCTYPE = {'D','O','C','T','Y','P','E'}; ++ private static final char [] COMMENTSTRING = {'-','-'}; + + // + // Constructors +@@ -708,6 +708,12 @@ + // + // Private methods + // ++ /** Set the scanner state after scanning DTD */ ++ protected void setEndDTDScanState() { ++ setScannerState(SCANNER_STATE_PROLOG); ++ setDriver(fPrologDriver); ++ fEntityManager.setEntityHandler(XMLDocumentScannerImpl.this); ++ } + + /** Returns the scanner state name. */ + protected String getScannerStateName(int state) { +@@ -930,19 +936,21 @@ + reportFatalError("AlreadySeenDoctype", null); + } + fSeenDoctypeDecl = true; +- if(fDTDDriver == null){ +- fDTDDriver = new DTDDriver(); +- } + + // scanDoctypeDecl() sends XNI doctypeDecl event that + // in SAX is converted to startDTD() event. + if (scanDoctypeDecl(fDisallowDoctype)) { ++ //allow parsing of entity decls to continue in order to stay well-formed + setScannerState(SCANNER_STATE_DTD_INTERNAL_DECLS); + fSeenInternalSubset = true; ++ if(fDTDDriver == null){ ++ fDTDDriver = new DTDDriver(); ++ } + setDriver(fContentDriver); +- int dtdEvent = fDTDDriver.next(); ++ //always return DTD event, the event however, will not contain any entities ++ return fDTDDriver.next(); + // If no DTD support, ignore and continue parsing +- return fDisallowDoctype ? next() : dtdEvent; ++ //return fDisallowDoctype ? next() : dtdEvent; + } + + /** xxx:check this part again +@@ -955,17 +963,18 @@ + } + */ + +- if (fDisallowDoctype) { +- setScannerState(SCANNER_STATE_PROLOG); +- return next(); +- } +- + // handle external subset + if (fDoctypeSystemId != null) { + if (((fValidation || fLoadExternalDTD) + && (fValidationManager == null || !fValidationManager.isCachedDTD()))) { +- setScannerState(SCANNER_STATE_DTD_EXTERNAL); ++ if (!fDisallowDoctype) { ++ setScannerState(SCANNER_STATE_DTD_EXTERNAL); ++ } else { ++ setScannerState(SCANNER_STATE_PROLOG); ++ } + setDriver(fContentDriver); ++ if(fDTDDriver == null) ++ fDTDDriver = new DTDDriver(); + return fDTDDriver.next(); + + } +@@ -976,8 +985,14 @@ + // This handles the case of a DOCTYPE that had neither an internal subset or an external subset. + fDTDScanner.setInputSource(fExternalSubsetSource); + fExternalSubsetSource = null; +- setScannerState(SCANNER_STATE_DTD_EXTERNAL_DECLS); ++ if (!fDisallowDoctype) { ++ setScannerState(SCANNER_STATE_DTD_EXTERNAL_DECLS); ++ } else { ++ setScannerState(SCANNER_STATE_PROLOG); ++ } + setDriver(fContentDriver); ++ if(fDTDDriver == null) ++ fDTDDriver = new DTDDriver(); + return fDTDDriver.next(); + } + } +@@ -1117,19 +1132,21 @@ + } + fMarkupDepth--; + +- // scan external subset next +- if (!XMLDocumentScannerImpl.this.fDisallowDoctype && +- fDoctypeSystemId != null && (fValidation || fLoadExternalDTD)) { +- setScannerState(SCANNER_STATE_DTD_EXTERNAL); ++ if (fDisallowDoctype) { ++ //simply reset the entity store without having to mess around ++ //with the DTD Scanner code ++ fEntityStore = fEntityManager.getEntityStore(); ++ fEntityStore.reset(); ++ } else { ++ // scan external subset next unless we are ignoring DTDs ++ if (fDoctypeSystemId != null && (fValidation || fLoadExternalDTD)) { ++ setScannerState(SCANNER_STATE_DTD_EXTERNAL); ++ break; ++ } + } ++ setEndDTDScanState(); + +- // break out of here +- else { +- setScannerState(SCANNER_STATE_PROLOG); +- setDriver(fPrologDriver); +- fEntityManager.setEntityHandler(XMLDocumentScannerImpl.this); +- return true; +- } ++ return true; + } + break; + } +@@ -1160,13 +1177,16 @@ + boolean completeDTD = true; + boolean moreToScan = fDTDScanner.scanDTDExternalSubset(completeDTD); + if (!moreToScan) { +- setScannerState(SCANNER_STATE_PROLOG); +- setDriver(fPrologDriver); +- fEntityManager.setEntityHandler(XMLDocumentScannerImpl.this); ++ setEndDTDScanState(); + return true; + } + break; + } ++ case SCANNER_STATE_PROLOG : { ++ // skip entity decls ++ setEndDTDScanState(); ++ return true; ++ } + default: { + throw new XNIException("DTDDriver#dispatch: scanner state="+fScannerState+" ("+getScannerStateName(fScannerState)+')'); + } +--- old/src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java Fri May 30 16:49:29 2008 ++++ openjdk/jaxp/src/share/classes/com/sun/org/apache/xerces/internal/impl/XMLDocumentFragmentScannerImpl.java Fri May 30 16:49:29 2008 +@@ -289,6 +289,8 @@ + protected boolean fReportCdataEvent = false ; + protected boolean fIsCoalesce = false ; + protected String fDeclaredEncoding = null; ++ /** Disallow doctype declaration. */ ++ protected boolean fDisallowDoctype = false; + + // drivers + +@@ -1852,6 +1854,11 @@ + } + // start general entity + if (!fEntityStore.isDeclaredEntity(name)) { ++ //SUPPORT_DTD=false && ReplaceEntityReferences should throw exception ++ if (fDisallowDoctype && fReplaceEntityReferences) { ++ reportFatalError("EntityNotDeclared", new Object[]{name}); ++ return; ++ } + //REVISIT: one more case needs to be included: external PE and standalone is no + if ( fHasExternalDTD && !fStandalone) { + if (fValidation) +--- /dev/null Mon Jun 2 16:07:10 2008 ++++ openjdk/jaxws/test/closed/javax/xml/stream/XMLStreamReaderTest/SupportDTD.java Mon Jun 2 16:07:26 2008 +@@ -0,0 +1,296 @@ ++/* ++ * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS HEADER. ++ * ++ * Copyright 1997-2007 Sun Microsystems, Inc. All rights reserved. ++ * ++ * The contents of this file are subject to the terms of either the GNU ++ * General Public License Version 2 only ("GPL") or the Common Development ++ * and Distribution License("CDDL") (collectively, the "License"). You ++ * may not use this file except in compliance with the License. You can obtain ++ * a copy of the License at https://glassfish.dev.java.net/public/CDDL+GPL.html ++ * or glassfish/bootstrap/legal/LICENSE.txt. See the License for the specific ++ * language governing permissions and limitations under the License. ++ * ++ * When distributing the software, include this License Header Notice in each ++ * file and include the License file at glassfish/bootstrap/legal/LICENSE.txt. ++ * Sun designates this particular file as subject to the "Classpath" exception ++ * as provided by Sun in the GPL Version 2 section of the License file that ++ * accompanied this code. If applicable, add the following below the License ++ * Header, with the fields enclosed by brackets [] replaced by your own ++ * identifying information: "Portions Copyrighted [year] ++ * [name of copyright owner]" ++ * ++ * Contributor(s): ++ * ++ * If you wish your version of this file to be governed by only the CDDL or ++ * only the GPL Version 2, indicate your decision by adding "[Contributor] ++ * elects to include this software in this distribution under the [CDDL or GPL ++ * Version 2] license." If you don't indicate a single choice of license, a ++ * recipient has the option to distribute your version of this file under ++ * either the CDDL, the GPL Version 2 or to extend the choice of license to ++ * its licensees as provided above. However, if you add GPL Version 2 code ++ * and therefore, elected the GPL Version 2 license, then the option applies ++ * only if the new code is made subject to such option by the copyright ++ * holder. ++ */ ++ ++/* ++ * @test @(#)SupportDTD.java 1.1 08/03/28 ++ * @bug 6542088 ++ * @key cte_test ++ * @summary JAX-WS server allows XXE attacks ++ * Fixed in JDK6u7 ++ * @run main SupportDTD ++*/ ++ ++import java.io.StringReader; ++import java.io.File; ++import java.io.FileInputStream; ++import java.util.List; ++ ++import javax.xml.stream.XMLEventReader; ++ ++import javax.xml.stream.XMLInputFactory; ++import javax.xml.stream.XMLStreamConstants; ++import javax.xml.stream.XMLStreamReader; ++import javax.xml.stream.events.*; ++import javax.xml.stream.events.Characters; ++ ++/** ++ * ++ * SUPPORT_DTD behavior: ++ * Regardless of supportDTD, always report a DTD event () and throw an ++ * exception if an entity reference is found when supportDTD is false ++ * ++ * The behavior is related to property IS_REPLACING_ENTITY_REFERENCES. ++ * ++ * SUPPORT_DTD Replace Entity DTD ENTITY_REFERENCE ++ * true (default) true (default) yes, has entities no, return Characters ++ * true (default) false yes, has entities yes, can print entity name ++ * false true (default) yes, but no entity Exception: Undeclared general entity ++ * false false yes, but no entity yes, can print entity name ++ * ++ * Two patches related: ++ * sjsxp issue 9: XMLDocumentScannerImpl.java rev 1.6 ++ * If the supportDTD property is set to FALSE, external and internal subsets ++ * are now ignored, rather than an error being reported. In particular, with ++ * this property set to FALSE, no error is reported if an external subset cannot ++ * be found. Note that the internal subset is still parsed (and errors could be ++ * reported here) but no events are returned by the parser. This fixes SJSXP ++ * issue 9 from Java.net. ++ * Note: SAX and DOM report fatal errors: ++ * If either SAX or DOM is used, turning on http://apache.org/xml/features/disallow-doctype-decl [1] effectively disables DTD, ++ * according to the spec: A fatal error is thrown if the incoming document contains a DOCTYPE declaration. ++ * The current jaxp implementation actually throws a nullpointexception. A better error message could be used. ++ * ++ * This change is required by CR 6542088. ++ * @author joe.wang at sun.com ++ */ ++public class SupportDTD { ++ static final boolean DEBUG = false; ++ static final String _file = "./tests/XMLStreamReader/ExternalDTD.xml"; ++ static final String XML = "" ++ +" References: <4873E7D1.2090802@sun.com> <1215607342.21015.3.camel@dijkstra.wildebeest.org> Message-ID: <4874E364.7050400@sun.com> Mark Wielaard wrote: > Hi David, > > This mentions: > 6u7: http://java.sun.com/javase/6/webnotes/ReleaseNotes.html > > This release contains fixes for one or more security vulnerabilities. > For more information, please see Sun Alerts 238687, 238628, 238965, > 238966, 238967, 238968, and 238905. > > So I looked at a couple of these through http://blogs.sun.com/security/ > and it seems this could also affect openjdk6, icedtea, gcjwebplugin, > netx, etc. Is there any more details available so we can double check > and hopefully patch the affected products? Later today, Wednesday July 9, we plan to release the source bundle for OpenJDK 6 b11 which will contain those security fixes, amongst other changes. -Joe From jsumali at redhat.com Wed Jul 9 10:37:48 2008 From: jsumali at redhat.com (Joshua Sumali) Date: Wed, 09 Jul 2008 13:37:48 -0400 Subject: [PATCH] Add umask setting for javaws/pluginappletviewer Message-ID: <4874F76C.90202@redhat.com> Hi, Attached are two patches that add umask functionality for any files created by javaws and pluginappletviewer. umask-1.patch simply hard codes the umask to be 077 for any files created, and is not modifiable once the binary launcher is created. umask-2.patch on the other hand checks for -umask= on the command line and sets the mask to whatever the user enters, but will default to 077 if no -umask= could be found. The first patch is the most simple and should work for most cases, but the second patch provides some flexibility for setting the umask. I'm not too sure if there would be any reason for the umask to be set outside 077 (in terms of plugin/web start apps), but the functionality is there in the second patch 2 if needed. Comments? Josh -------------- next part -------------- A non-text attachment was scrubbed... Name: umask-1.patch Type: text/x-patch Size: 1655 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080709/8136ff78/attachment.bin -------------- next part -------------- A non-text attachment was scrubbed... Name: umask-2.patch Type: text/x-patch Size: 5006 bytes Desc: not available Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20080709/8136ff78/attachment-0001.bin From green at redhat.com Wed Jul 9 19:26:05 2008 From: green at redhat.com (Anthony Green) Date: Wed, 09 Jul 2008 19:26:05 -0700 Subject: IcedTea6 1.2 Released! In-Reply-To: <776D35B0-C8A7-4A02-9521-9730C622E25A@spreadshirt.net> References: <483F0563.2080103@redhat.com> <17c6771e0805291317r512c6cc6xdd610f26013cb41c@mail.gmail.com> <1213705038.3156.11.camel@dijkstra.wildebeest.org> <4857D87A.7070406@redhat.com> <776D35B0-C8A7-4A02-9521-9730C622E25A@spreadshirt.net> Message-ID: <4875733D.2000004@redhat.com> Guido K?mper wrote: > Hi Anthony, > > I currently saw the message "IcedTea is served" on my screen, after a > few installation problems. :-) Now I am looking forward to creating > nice sound applications. Did you have some luck integrating the DSSI > classes? If yes, did you implement it in a special branch and is it > possible to access this implementation? Thanks for reminding me. I got on my flight that day and looked at the IcedTea src tree for the first time, then quickly realized I wasn't going to be able to do this in a vacuum. First question for the IcedTea hackers: where in the tree should my source code live? It looks like there are a few viable spots. Thanks, AG > > thank you, > Guido > > Am 17.06.2008 um 17:30 schrieb Anthony Green: > >> Mark Wielaard wrote: >>> Hi Guido, >>> >>> On Tue, 2008-06-17 at 13:21 +0200, Guido K?mper wrote: >>> >>>> congratulations to the new version! >>>> >>> >>> Thanks! >>> >>> >>>> One question: The gnu classpath has a support for using DSSI >>>> instruments in the sound libraries. Are there plans to include >>>> this into the IcedTea platform - or is it already included? That >>>> would be really cool:) >>>> >>> >>> No it hasn't been integrated yet. All midi handling is currently being >>> done through Gervill, a software synthesizer. This has as advantage (or >>> disadvantage, depending on your view), that no direct integration with >>> the native platform soft synths needs to be done. >>> >>> I have CCed Anthony Green, who originally wrote the DSSI backend for GNU >>> Classpath, to see if he might be interested in porting it to IcedTea. >>> Hi Anthony! :) >>> >> Hi Mark. The DSSI providers were written using JNI, so they should >> be easy to port over to IcedTea. I'm happy to try. It will give me >> something to do on my flight today. >> >> AG >> > > * > > *sprd.net AG* > *Karl-Heine-Stra?e 97* > *04229 Leipzig* > *Germany* > > *Vorstand/Executive Board: Jana Eggers (Vorsitzende/CEO), Matthias > Spie?, Andreas Schr?teler* > > *Aufsichtsratsvorsitzender/Chairman of the Supervisory Board:* *Lukasz > Gadowski* > > *Handelsregister/Trade Register: Amtsgericht Leipzig, HRB 22478* > > *Umsatzsteuer-IdentNummer/VAT-ID: DE 8138 7149 4* > > > * > > > From mark at klomp.org Thu Jul 10 03:52:48 2008 From: mark at klomp.org (Mark Wielaard) Date: Thu, 10 Jul 2008 12:52:48 +0200 Subject: IcedTea6 1.2 Released! In-Reply-To: <4875733D.2000004@redhat.com> References: <483F0563.2080103@redhat.com> <17c6771e0805291317r512c6cc6xdd610f26013cb41c@mail.gmail.com> <1213705038.3156.11.camel@dijkstra.wildebeest.org> <4857D87A.7070406@redhat.com> <776D35B0-C8A7-4A02-9521-9730C622E25A@spreadshirt.net> <4875733D.2000004@redhat.com> Message-ID: <1215687168.3053.26.camel@dijkstra.wildebeest.org> Hi Anthony, On Wed, 2008-07-09 at 19:26 -0700, Anthony Green wrote: > I got on my flight that day and looked at the IcedTea src tree for the > first time, then quickly realized I wasn't going to be able to do this > in a vacuum. > > First question for the IcedTea hackers: where in the tree should my > source code live? It looks like there are a few viable spots. Yes, there are indeed a couple of ways to extend icedtea/openjdk depending on how big and how invasive your change is. For smaller changes the simplest way is to just add a patch under patches/icedtea-your-cool-hack.patch and then add that to the ICEDTEA_PATCHES in the Makefile.am. Your change will th