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
