The libjava.so replaces a variety of system calls, in particular the open call.
The open call makes a call to a method pointer - if this has not been init'd then when open is called then this function core dumps.

Caused this by creating a C++ java executable which linked in C++ libraries
which has initializers. One of which open'd a file. This then cored dumped at
address 0x0 within libjava.so:open. The libjava.so:open function should either
check if the function pointer is null or the docs should indicate under
what conditions the functions are valid.

Problem resolution, that of moving all the initialization to within the
library start up routines causes problems as the library code base used is frozen and in production.

N/A

The problem is that the green threads VM is not
embeddable - trying to link it into another
application will be problematic.  We've always
known that, and I think this is implicit in
the fact that the JNI Invocation API is
documented not to work for green threads.
The green threads VM assumes it is the
application on top, and that it is
not being linked in by another application.

The first step toward getting this to work
is always to link libjava.so into the executable
*first*, even before libc.so:

 xxxxx@xxxxx :/space/ws/1.1.2/build/bin/sparc/green_threads( 139 )% ldd java
	libjava.so =>	 (file not found)
	libdl.so.1 =>	 /usr/lib/libdl.so.1
	libX11.so.4 =>	 /usr/lib/libX11.so.4
	libsocket.so.1 =>	 /usr/lib/libsocket.so.1
	libnsl.so.1 =>	 /usr/lib/libnsl.so.1
	libresolv.so.2 =>	 /usr/lib/libresolv.so.2
	libc.so.1 =>	 /usr/lib/libc.so.1
	libXext.so.0 =>	 /usr/lib/libXext.so.0
	libmp.so.2 =>	 /usr/lib/libmp.so.2

There will still be major headaches trying to
use the green-threads VM in this way.  For what
you want to do, the 1.1.2 Solaris native-threads
VM is infinitely more suitable.