RE: input line is too long

[Andrew Haley <aph at redhat dot com>]

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.