Big Project Ported

[Steven Ashe]

 >  Steven Ashe writes:
 >  
 >  > Just finished porting a fairly large java project to run under gcj
 >  > compilation.
 >  
 >  Way cool.
 >  
 >  > It required working around some gcj-2.95.1 problems, but they
 >  > weren't too bad.
 >  
 >  GNATS (or at least the way I use it) tells me you (via Tom) filed the
 >  gcj PR #56 that I haven't got a chance to work on. I guess you had to
 >  work around this one.
 >  
 >  Any other front-end problems you ended up developing workarounds for
 >  and eventually not bothered reporting?
 >  
 >  ./A
 >  
There were:
1) some problems reported (as you noted)
2) some that I tried against a recent snapshot and found to be fixed
   so I didn't report them
3) Code I had to change because it was 1.1
4) Problems I had because java seems to allow more liberal namespace overlap
   that does C++, for instance, Java appears to allow a static field and
   a method to have the same name, but gcjh barfs when it sees this.
5) Problems because there is no documentation (I could find) that indicates
   how gcj goes about resolving external class information.  In particular,
   it appears to look for a .class in CLASSPATH first, but then will poke
   at .java files.  What are the candidate .java files it will inspect?
   Also, this is unreliable, because of the one-to-many problem -- gcj cannot
   know, in the absense of any .class files, what .java to look in
   other than the one with the public name.  This required forcing 'make'
   to set up a cleaner environment than I normally would have, and required
   putting various explicit dependencies in the Makefile to handle the
   one-to-many problem.  Note: the project builds from .java, in general,
   not from .class [It seems gcj needs a --sourcepath option to control
   where it will look for .java files to scan to resolve external class info.
6) mysteries I found some adhoc solution to.
   The most perplexing is the J?? undefined message.  When compiling from
   .java, sometimes I get undefined's with short names (I don't remember
   them exactly, something like ?J?? that don't correspond to any symbols
   in the .java file).  However, if I compile to .class with jikes or javac
   first, and go to .o from that, this fixes the problem.
   Also, when I took libgcj-2.95.1 and tried to build it with -02, it
   had the exact same problem when trying to link 'javaconvert' or some
   such-named utility.
7) Setting up make to look in both the libgcj source and the target-build
   directories for .h's since 'make install' doesn't install include's
   correctly (or at all?).
8) Misc: Needing to make the calls to loadLibrary conditional on gcj compilation;
   in the gcj-built executable there is no need to dynamically link, so I
   conditionally bypass these calls.  I can't think of anything gcj itself
   can do about this.  Also, it sure seems like the no-threads runtime spends
   a lot of instructions, esp. during instantiation, doing threads-related
   stuff (mutexes/monitors?) before it discovers there are no threads. [This
   may be my misunderstanding of what the code is doing]

Another good reason for producing executables from Java has to do with setuid.
My program talks to various user-space devices using the Linux sched_xxx
realtime code, and so must run as root.  But the suid-root programs can't
load shared libraries other than 'trusted ones', which makes suid-root java
a *real* pain.  The gcj compiled version has no such problems, because I
built all its CNI as .a's rather than .so's.

-Steve