Red Hat Bugzilla – Bug 162177
ecj intermittently fails to parse classpaths correctly.
Last modified: 2007-11-30 17:11:09 EST
Description of problem:
ecj intermittently fails to parse classpaths correctly. The bit that splits the
path on colons fails, so it treats the whole classpath as a file/directory.
You'll get an "incorrect classpath" message, then your build will fail because
there'll be nothing on the classpath.
Version-Release number of selected component (if applicable):
eclipse-ecj-3.1.0_fc-0.M7.9 and eclipse-ecj-3.1.0_fc-0.RC3.3
Fails at different places on different machines, but if it fails at a specific
place on one machine then it'll always fail there.
Steps to Reproduce:
Try and build a package. nanoxml and perseus-cache fail in beehive but not on
my machine. joram fails on my machine if you add ship.jonasadapter to the list
of targets on the ant command line. Or, start up jonas and try and view a JSP
-- the JSP compiler fails on both mine and Mark Wielaard's boxes.
An "incorrect classpath" warning, followed by a failed compilation.
Neither of the above.
I hate bugs.
Actually, the joram failure might actually be because joram's build script is
simply broken. If so, then perhaps I can narrow down what versions things are
The joram build fails for me because build.kjoram wants midpapi.jar,
which doesn't exist.
perseus-cache seems to build but there are errors about missing
'fractal' imports; so I think it probably has some other problem.
Is this architecture specific?
Created attachment 116322 [details]
Build log from beehive
No, fractal is there: the errors are because ecj is failing to parse the
classpath with the fractal jars in it.
Check the attached log for the line that starts "incorrect classpath". After
splitting classpaths on colons, ecj performs a file existance check on every
element of the classpath to see if it exists, and prints out an "incorrect
classpath" message for _each_ element that's missing. The fact that the whole
classpath appears in the message would imply that splitting the classpath on
I'm not sure about the joram error, so please disregard it for now.
I ran this on one of the beehive boxes with an empty classmap.db, so it's not a
native compilation issue:
[root@crowe redhat]# rpm -q eclipse-ecj libgcj
[root@crowe redhat]# gcj-dbtool -l /usr/lib64/gcj-4.0.0/classmap.db
[root@crowe redhat]# rpmbuild -ba SPECS/perseus-cache.spec
+ ant jar jdoc
[mkdir] Created dir: /usr/src/redhat/BUILD/cache/output/build
[javac] Compiling 24 source files to /usr/src/redhat/BUILD/cache/output/build
[javac] incorrect classpath: /usr/src/redhat/BUILD/cache/output/build:...
[javac] incorrect classpath: /usr/src/redhat/BUILD/cache/src
Created attachment 116323 [details]
Script to exercise java.util.StringTokenizer
When I put the failing classpaths through java.util.StringTokenizer, though, it
splits them perfectly:
[root@crowe ~]# javac Test.java
[root@crowe ~]# java Test
Oddly, the second "incorrect classpath" is just one element (and it exists) so
quite what the problem is there I don't know.
This is because of https://bugs.eclipse.org/bugs/show_bug.cgi?id=92398.
See also https://www.zarb.org/pipermail/jpackage-discuss/2004-March/004644.html.
To be clear: it's because ecj now treats "[" and "]" as special characters. Ths
breaks because jpackage.org uses "[" and "]" as characters in filenames. You
can blame jpackage.org for this (and I do) but in the meantime we need to fix ecj.
I've committed a patch to eclipse that disables it's "" parsing, and Andrew
Overholt is going to build it for me overnight (my overnight, not his).
Hopefully we'll have a working beehive again by tomorrow :)
eclipse-3.1.0_fc-2 finished. I tried to reproduce your perseus build issue but
I'm having issues doing so :) Hopefully you can see if things are fixed
Yeah, perseus and everything else are building. nanoxml isn't, but I expect
that's a separate issue so I'm closing this.
The nanoxml failure I mentioned originally is actually
Should we close this now, Gary? We're still carrying the patch but I'd like to
move it upstream if that's acceptable. Thoughts?
Sure. Though our patch simply disables the broken bit, whereas I expect
upstream would want it fixing properly...
I'm reopening this bug against rawhide.
Did Gary's "" parsing patch get dropped when we upgraded to Eclipse 3.2 in
rawhide? I'm getting "incorrect classpath" messages when I try to build things
with jpackage managed symlinks.
The patch didn't work anymore due to access restrictions now being used in 3.2.
We made a new patch and tested it and it worked. Can you give an example?
(In reply to comment #16)
> The patch didn't work anymore due to access restrictions now being used in 3.2.
> We made a new patch and tested it and it worked. Can you give an example?
Thanks. Just try anything that uses "build-jar-repository". The tomcat5 SRPM
would be a good example for instance.
I'm not sure how the  are interpreted by Eclipse, but do you think we should
be pushing for JPackage to change their ways?
(In reply to comment #17)
> (In reply to comment #16)
> > The patch didn't work anymore due to access restrictions now being used in 3.2.
> > We made a new patch and tested it and it worked. Can you give an example?
> Thanks. Just try anything that uses "build-jar-repository". The tomcat5 SRPM
> would be a good example for instance.
Hmm. I build the Eclipse SDK with some build-jar-repository calls and it works
fine. I'll try tomcat5 when I get 3.2 final built.
> I'm not sure how the  are interpreted by Eclipse, but do you think we should
> be pushing for JPackage to change their ways?
We just changed the patch so that filenames that *begin* with [ are parsed as
files and not as compiler flags. Of course, I still think that JPackage
conventions of s are silly but I'm pretty sure that's changing with their next
*** This bug has been marked as a duplicate of 199961 ***