Re: classpath 0.10 and GCJ Version 3.3.3 20040215
Hi Steve, On Tue, 2004-07-20 at 23:27, Steven Augart wrote: > I just accidentally tried to build Classpath 0.10 using GCJ (I was > using an AIX machine, and I'd left Jikes out of my path). The GCJ > version is: > > gcj (GCC) 3.3.3 20040215 (release) > > This gave the error: > > /usr/gnu/bin/gcj --bootclasspath '' --classpath > ../../classpath-0.10:../../classpath-0.10/external/jaxp/source:../vm/current:.: -C > -d . @classes > ../../classpath-0.10/java/security/cert/X509Certificate.java:143: error: Class > `java.security.cert.X509Certificate' can't subclass interface > `java.security.Certificate'. >public abstract class X509Certificate extends Certificate implements X509Extension > > The "configure" script currently tests whether GCJ, if used, has at > least version 3.3. This doesn't seem to be adequate to get around > the error. > > Does anybody know what version of gcj we need to avoid this > complaint? We should update the configure script appropriately. The release was tested against gcj (GCC) 3.3.4 (Debian 1:3.3.4-3) and gcj CVS. Hopefully 3.3.4 is enough. But I see that Debian actually includes a couple of patches for the compiler... One of which looks like it was for the above issue. Darn. So you might actually need the 3.4 FSF release. The "official" policy is to make sure that the java source files can be compiled against the latest official releases of gcj and jikes. (So if gcj 3.4 and/or jikes 2.21 don't work, we have a bit of a problem.) But in practice (in my case) this often means the last releases of gcj and jikes in Debian. We do have a problem in any case since at least the INSTALL/hacking-guide document doesn't explicitly say that (and the configure script version check could indeed be updated). Cheers, Mark signature.asc Description: This is a digitally signed message part ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: classpath 0.10 and GCJ Version 3.3.3 20040215
Michael Koch programmed a nightly build executed every night, which is compiled with jikes 1.16. on a Suse 8.1 machine (with a few patches) Maybe this could be extended to use more compilers and versions thereof? -Patrik --On Mittwoch, 21. Juli 2004 09:10 +0200 Mark Wielaard <[EMAIL PROTECTED]> wrote: Hi Steve, On Tue, 2004-07-20 at 23:27, Steven Augart wrote: I just accidentally tried to build Classpath 0.10 using GCJ (I was using an AIX machine, and I'd left Jikes out of my path). The GCJ version is: gcj (GCC) 3.3.3 20040215 (release) This gave the error: /usr/gnu/bin/gcj --bootclasspath '' --classpath ../../classpath-0.10:../../classpath-0.10/external/jaxp/source:../v m/current:.: -C -d . @classes ../../classpath-0.10/java/security/cert/X509Certificate.java:143: error: Class `java.security.cert.X509Certificate' can't subclass interface `java.security.Certificate'. public abstract class X509Certificate extends Certificate implements X509Extension The "configure" script currently tests whether GCJ, if used, has at least version 3.3. This doesn't seem to be adequate to get around the error. Does anybody know what version of gcj we need to avoid this complaint? We should update the configure script appropriately. The release was tested against gcj (GCC) 3.3.4 (Debian 1:3.3.4-3) and gcj CVS. Hopefully 3.3.4 is enough. But I see that Debian actually includes a couple of patches for the compiler... One of which looks like it was for the above issue. Darn. So you might actually need the 3.4 FSF release. The "official" policy is to make sure that the java source files can be compiled against the latest official releases of gcj and jikes. (So if gcj 3.4 and/or jikes 2.21 don't work, we have a bit of a problem.) But in practice (in my case) this often means the last releases of gcj and jikes in Debian. We do have a problem in any case since at least the INSTALL/hacking-guide document doesn't explicitly say that (and the configure script version check could indeed be updated). Cheers, Mark ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: classpath 0.10 and GCJ Version 3.3.3 20040215
Mark Wielaard wrote: Does anybody know what version of gcj we need to avoid this complaint? We should update the configure script appropriately. The release was tested against gcj (GCC) 3.3.4 (Debian 1:3.3.4-3) and gcj CVS. Hopefully 3.3.4 is enough. But I see that Debian actually includes a couple of patches for the compiler... One of which looks like it was for the above issue. Darn. So you might actually need the 3.4 FSF release. If someone wants to identify the patch in question, and post a bug report to gcc.gnu.org/bugzilla, we can probably get that patch into the 3.3.5 release. This will make sure that other distributions still using gcc 3.3 pick up the fix. Regards Bryce ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
Re: classpath 0.10 and GCJ Version 3.3.3 20040215
Am Mittwoch, 21. Juli 2004 20:07 schrieb Patrik Reali: > Michael Koch programmed a nightly build executed every night, which > is compiled with jikes 1.16. on a Suse 8.1 machine (with a few > patches) > > Maybe this could be extended to use more compilers and versions > thereof? It's easy to extend or to use on other hosts. I will clean it up and commit it to CVS into the scripts directory. This reminds me that I need to sent its mails to [EMAIL PROTECTED] ml again. Michael ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
[gui][patch] monthly merge from java-gui-branch
hi, this is the "monthly" merge from java-gui-branch to gcc trunk. this will be the last such regularly scheduled merge for a while; we're going to be taking a slightly less disruptive (to trunk) route for a bit, as an experiment: merging between the gui branch and classpath directly more frequently, and doing a 1-way merge into trunk at lower frequency (say every 2-3 months). this is primarily to reduce the number of times we risk breaking the gcc trunk build, which is a recurrent problem of mine. I'd ask that future work on gui-related stuff go into the gui branch or classpath, *not* gcc trunk, since this will ease integration and reduce the risk of a merge clobbering your changes. anyways, the july patch is here: http://people.redhat.com/graydon/java-gui-merge-july-20-2004.patch it's another 600k of diffs, all confined to java.awt, javax.swing, and jni/gtk-peers. I've done a build test against the trunk and run the recent "activityboard" test: http://people.redhat.com/graydon/activityboard.java which appears to work out of the box with it. please let me know if you have any objections; I'll be committing shortly (say, tomorrow morning) if not. I'd welcome anyone with an extra autobuilder and some spare cycles to check it out and make sure I'm not causing any trouble. last time was almost too frustrating for me to believe my own test results anymore. -graydon ___ Classpath mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/classpath
