This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: Some notes on our status
- From: Mark Wielaard <mark at klomp dot org>
- To: tromey at redhat dot com
- Cc: Java Discuss List <java at gcc dot gnu dot org>, apbianco at redhat dot com
- Date: 21 Apr 2002 17:54:31 +0200
- Subject: Re: Some notes on our status
- References: <87k7r3vzo9.fsf@creche.redhat.com>
Hi,
On Sat, 2002-04-20 at 05:04, Tom Tromey wrote:
> PR 6066 (can't rebuild Classpath) is growing and not shrinking :-(.
> The current Classpath triggers a known problem in gcj (re-reported as
> PR 6336, but also known as PR 1343). I have a partial patch for this,
> which I wrote in December, but it is unfinished. In any case this
> increasingly looks like something we'll unfortunately have to drop for
> 3.1. Any comments on that?
The current gcj can build the latest released version (0.03) of GNU
Classpath which is good. If we can find workarounds for the current
problems in Classpath CVS then we can make sure that a next version of
Classpath will work with gcj 3.1. Obviously as a Classpath hacker I
think it is very important to fix this issue since officially Classpath
is the upstream provider for a lot of the standard classes in libgcj.
PR6336/1343 isn't a real problem since it has a known workaround (rename
one of the inner classes) which I have already applied to my local
Classpath tree.
The problem(s) that I am seeing look like PR java/2791, which you will
get for java.io.FileChannel and java.util.Map. Luckily the patch given
in that PR does fix that problem (Back in August I reported that it
didn't solve the issue I had back then in Classpath, but the bug report
wasn't actually about compiling Classpath. Sorry, if my report made the
patch not go in.)
Applying that patch will show three more problems which you already
reported in the original PR java/6066 for java.util.AbstractMap (the
same happens for java.awt.AWTKeyStroke, java.awt.im.InputSubset). But a
workaround is to fully qualify the inner classes used. Which I have done
for my local Classpath tree.
With these changes I am able to compile Classpath CVS with gcj 3.1 CVS.
I have attached an updated version of the patch given in PR java/2791:
2001-08-17 Alexandre Petit-Bianco <apbianco@redhat.com>
* jcf-parse.c: (yyparse): Don't prepend "./" to relative
paths. Fixes PR java/2791.
This does not introduce any new regressions in libgcj or mauve, so if
Alexandre still believes this patch is right it would be very nice to
get this in 3.1.
I will post my patches for the Classpath source to the Classpath
mailinglist so you can check that they solve the remaining issues.
Cheers,
Mark
Index: jcf-parse.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/java/jcf-parse.c,v
retrieving revision 1.104.2.5
diff -u -r1.104.2.5 jcf-parse.c
--- jcf-parse.c 29 Mar 2002 00:14:00 -0000 1.104.2.5
+++ jcf-parse.c 21 Apr 2002 15:49:37 -0000
@@ -1014,9 +1014,6 @@
int twice = 0;
int len = strlen (list);
-
- if (*list != '/' && filename_count > 0)
- obstack_grow (&temporary_obstack, "./", 2);
obstack_grow0 (&temporary_obstack, list, len);
value = obstack_finish (&temporary_obstack);