Brian Jones wrote:
> No, I've not found a fix. I've also not looked any further since
> then due to lack of time spent working on Classpath. I've been
> meaning to send Chris Toshok email asking him if he had an idea where
> I should look?
Well, I have narrowed down the (likely) cause to HVM_DllFind(). Apparently,
it is reporting success even when the file it is trying to load doesn't
exist...now I've just got to figure out why...
>
>
> I would also like to find out why Japhar requires loading its own
> javalang, javaio, etc. Maybe there are things in there which should
> be moved to some other generic library.
You can specify the path to search for native libraries by setting the
LDTD_LIBRARY_PATH environment variable. However, the string that japhar
passes to HVM_DllFind is just the last sub-package (e.g., to load the shared
library for java.lang, it calls HVM_DllFind("io") and to load the shared
library for java.lang.reflect it calls HVM_DllFind("reflect"). And because
of the bug mentioned above, unless /usr/local/japhar/lib is the first entry
in LDTD_LIBRARY_PATH (or the env is not set), it will try to load a
nonexistant library
Well, back to bug hunting. I hope to have more to report soon.
Ian
