input line is too long

Andrew Haley aph@redhat.com
Mon Dec 23 07:17:00 GMT 2002


Erik Poupaert writes:
 > 
 > >>>> I'd like to know too. The only way I know at the moment is in your case,
 > compile everything with jikes if you haven't been able to track
 > dependencies between sources or keep the number of files within a
 > package relatively small. Then jar everything up and generate a library:
 > 
 > GCJ seems to have a problem with figuring out dependencies between source
 > files. GCJ does not seem to have any concept of "sourcetree", only of
 > "classpath". I haven't been able to get one single alternative way
 > operational, except for using Jikes.

As far as I know gcj will find source files whenever they are
referenced.  If not, please let me see a test case.

 > >>>>> gjc --shared -o lib-package.so package.jar
 > 
 > I don't know why, but that fails consistently in GCJ/minGW.

 > GCJ never manages to solve dependencies in the jar that it is busy
 > compiling.

Again, please send a test case.

 > It manages, however, to use a foldertree of .class files to resolve
 > dependencies. So, I first create this foldertree of .class files
 > with jikes, and then I use it as a classpath for GCJ. By the way,
 > it only works with jikes. GCJ goes abend on .class files generated
 > with the JDK1.4 javac; something to do with the exception tables in
 > in the .class files.

Okay, so I need to find out what is different.  Any error messages?

 > Jikes is a brilliant "header-file" producer for GCJ!
 > 
 > Another bizar thing: Jikes compiles sources about a 100 times faster than
 > GCJ. Admitted that GCJ does a bit more work, but not a hundred times!

I'm surprised at that if the difference is jikes versus gcj -C.

If the difference is between jikes and gcj generating object files,
then I'm not surprised at all.  Generating bytecode is quite trivial
in comparison with generating assembler and assembling it.

Andrew.



More information about the Java mailing list