Shared C++ JNI library on Solaris -- no Static Initializers

[Doug Zwick]

I've managed to solve my own problem:

> I'm having difficulties linking a shared JNI library using
> gcc on Solaris. The JNI library is for use with Java Web Start,
> and as we cannot depend on gcc being installed on the computer
> running the program, we cannot have dynamic lib dependencies on
> libgcc or libstdc++. I am using this command line to link the
> library (using gcc 3.3.2):
>
>      g++ -olibtest.so -shared -fpic -static-libgcc -nostdlib \
>      x.o y.o ... [path to libstdc++.a] -lm -lc
>
> The resulting library has no static initializer. Diagnostics
> inserted in routines that should be run are not executed, and
> ldd -i libtest.so does not list an initialization section for
> the library.

The correct way to do this is to use -nodefaultlibs, not
-nostdlib. The -nostdlib arg also suppresses the "startup
files", which apparently are necessary for a shared library
with static initializers (I thought they were only necessary
for an executable file, to call main, etc.).

> Additionally, the [path to libstdc++.a] seems to be required
> to resolve the reference to symbol __gxx_personality_v0, and
> some ABI methods. However, it brings in some other undefined
> symbols (determined from nm libtest.so | grep UNDEF), such as
> _Unwind_DeleteException. If I try opening the library using
> dlopen with RTLD_NOW, these symbols must be resolved against
> libgcc dynamically, regardless of the -static-libgcc linker
> argument. Is there a better way of resolving libstdc++ as a
> static lib? I tried "-Bstatic -lstdc++ -Bdynamic ..." without
> success. These symbols do not seem to matter, at least in the
> normal case -- I worry that they'll need to be resolved if a
> C++ exception is thrown.

I've been able to resolve this by adding the lib libgcc_eh.a
absolute path to the link, immediately following libstdc++.a.
The paths to both these libs can be generated using:
     g++ -print-file-name=libgcc_eh.a
or
     g++ -print-file-name=libstdc++.a