Hi there,

I saw the BCEL in the source repository but at the moment the toplevel
make from RHUG won't build breaking on something from gnu.readline and
haven't had time to inspect the rest yet.

Some time ago there was a question about the
AssertionViolationException.java I delved into the code and there are
some notes from the authors stating it is only meant for internal use.
Furthermore it only occurs once in the Pass1Verifier.java. I included
two diffs that remove the offending method (something of an internal
name clash that GCJ can't resolve), and a diff that removes the only
call to the method in the whole sourcecode.

Applying these patches and removing: 
VerifierAppFrame.java VerifyDialog.java VerifierFactoryListModel.java
GraphicalVerifier.java

Will get it to compile. I looked into the RHUG cvs and saw that those
sources have been already removed.

I am well on my way compiling Tomcat at the moment, but am still bugged
by resourcefiles. Currently I fix this by dumping resource files into a
jar and placing them in the classpath

compiling using

gcj --resource xx/xx/xxx/xx/resource xx/xx/xxx/xx/resource -o
xx/xx/xxx/xxx/resource_res.o

does compile but the code will not find the resource in question. if it
doesn't take too much of your time, can anybody point out the code where
the core:// protocol in handled in the GCJ sources or what I am doing
wrong?

Xerces and Xalan compile without problems, except for 1 source file the
DTMDefaultTraverser where there is a bit of unreachable code, I have
posted a diff before but that one seemed incorrect, becuase in one case
of the for(;;) loops where the increment (last term of the for-loop) was
unreachable in some cases my modification of the code prevented
reexecution of the loop. I included the diff for that too. I know it's
all peanuts work, but hopefull it's of some use.

One worty thing to mention is that compiling directly from java sources
to native code seems to be the way to go with GCJ. A lot of the problems
I reported in the weeks before due to try{} catch {} loops etc. are only
encountered when generating classfiles from java sources and
subsequently generating native code from those classfiles. Generating
the native code from java sources directly also result in a smaller
number of object files because the inner classes are integrated into the
same object file.

Java_cup and regexp don't need any modifications at all.

Ant does have problems: 
The diff for GET solves the depedency on com.sun. packages for a Base64
encoder which is already implemented in the classfile itself.
The ImplementationSpecificArgument has problems resolving the
superclass, the diff extends the superclass with it's FQN instead of
it's short name.
The DateUtils diff prevents calling a format method that is broken in
GCJ 3.2.1 and cvs last time I checked.
Ant will not run correctly as long as the StringTokenizer.java isn't
fixed in GCJ and as such will not run correctly with GCJ 3.2.1. Oddly
enought the version from Classpath is correct and GCJ's version seems to
be an older version.
Rhug's version of Ant is very unlikely to build as it contains sun.*
dependent code for Get.java. I think it's not necessary to remove all
optional packages especially the xml tasks, as Ant depends on xerces
anyway and sourcecode for javax.xml.* interfaces of xerces and xalan
supplement each other.

Greets, Bhun.