Seeking debug tips for Kaffe on NSPR

[Robert S. Thau]

Godmar Back writes:
 > Tim/Transvirtual hasn't checked in anything, and I can't blame them:
 > if there is nobody out there who is interested and willing to contribute, 
 > why should they put any effort in making stuff available or in coordinating
 > a development effort?  After all, the whole "bazaar" model works only if 
 > there actually is someone at the bazaar.

There is a chicken-and-egg problem here --- what rational person is
going to *show up* at the bazaar if the most interesting merchandise
is not on view?  (The most salient distinction between "cathedral" and
"bazaar" models in that paper isn't the form of control of development
--- Eric had final control of the contents of all fetchmail releases,
and makes no bones about it --- but rather, the release of potentially
interesting, buggy and incomplete code early).  And, on that cheery
note...

Largely for my own amusement, as a way to get to know both codebases,
I'm working on a port of Kaffe onto the Netscape Portable Runtime;
this is a package internal to the publically released Mozilla source
which provides a platform-independant API for threads, I/O, and
various other system services, which is consistent on Unix, Win32, and
to some extent on the Mac.  [See NSPR note below, particularly the
caveat on distribution].

The port is to the point of correctly running HelloWorldApp and most
of the other regression tests.  However, in addition to a couple of
failures there which I understand, I'm seeing some behavior which is,
at this point, a bit mysterious.  

In particular, javac run on the port always fails --- within the
java.util.zip code, findEND throws a ZipException saying "not a zip
file (END header not found)", following which the compiler itself very
shortly reports that it can't find java.lang.Object.  (This is, of
course, with a classpath and other environment variables on which
jthreads Kaffe runs javac perfectly).

What makes this particularly strange is that I can see it calling the
open method from my syscall interface (which sets up shadow file
descriptors, as the equivalent NSPR construct is a structure pointer),
but not the read method.  

One thing which is somewhat suspicious is code in the VM proper which
reads zip files without going through the Kaffe_SystemCallInterface
(jar.c, findInJar.c); this code would, of course, gag on one of my
shadow descriptors if it ever saw one.  However, I can't see any
direct connection between that code and the native methods in
libraries/clib/zip, so I thought I'd ask for a sanity check before
hacking away.  (NB findInJar.c is perfectly capable of finding
java.lang.Object on its own --- or it couldn't run HelloWorldApp! ---
but javac is apparently playing other games).

If anyone has seen behavior like this in the past, and might have some
insight, I'd appreciate it.

TIA,
rst

NSPR Note: Other packages are also being ported onto NSPR --- there
  is, for instance, an incipient Apache port.  In fact, integrating
  Kaffe with something like that might be a more immediately
  interesting application for this port than integrating Kaffe with
  Mozilla itself, at least until Kaffe gets AWT support back and the
  Java integration stubs for Mozilla are finalized.  However, that's
  academic at this point; aside from the bugs discussed above, I'm not
  sure under what conditions, if any, I can legally distribute the
  thing, due to GPL/NPL license interference.