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 libgcj-4.0.0-12, libgcj-4.0.0-13 java-1.4.2-gcj-compat-1.4.2.0-40jpp_30rh How reproducible: 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. Actual results: An "incorrect classpath" warning, followed by a failed compilation. Expected results: Neither of the above. Additional info: 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 failing on.
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 colons failed. 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 eclipse-ecj-3.1.0_fc-1 libgcj-4.0.0-13 [root@crowe redhat]# gcj-dbtool -l /usr/lib64/gcj-4.0.0/classmap.db Capacity: 0 Size: 0 Elements: [root@crowe redhat]# rpmbuild -ba SPECS/perseus-cache.spec ... + ant jar jdoc Buildfile: build.xml compile: [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 [javac] ----------
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 /usr/src/redhat/BUILD/cache/output/build:/usr/src/redhat/BUILD/cache/externals/[fractal][fractal].jar:/usr/src/redhat/BUILD/cache/externals/[monolog][ow_monolog].jar:/usr/share/java/ant.jar:/usr/share/java/ant-launcher.jar:/usr/share/java/jaxp_parser_impl.jar:/usr/share/java/xml-commons-apis.jar:/usr/share/java/objectweb-anttask.jar:/usr/lib/jvm/java/lib/tools.jar /usr/src/redhat/BUILD/cache/src result: > /usr/src/redhat/BUILD/cache/output/build > /usr/src/redhat/BUILD/cache/externals/[fractal][fractal].jar > /usr/src/redhat/BUILD/cache/externals/[monolog][ow_monolog].jar > /usr/share/java/ant.jar > /usr/share/java/ant-launcher.jar > /usr/share/java/jaxp_parser_impl.jar > /usr/share/java/xml-commons-apis.jar > /usr/share/java/objectweb-anttask.jar > /usr/lib/jvm/java/lib/tools.jar result: > /usr/src/redhat/BUILD/cache/src 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 tomorrow, Gary.
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 https://bugs.eclipse.org/bugs/show_bug.cgi?id=105430.
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 "release". >
*** This bug has been marked as a duplicate of 199961 ***