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

Doug Zwick dougz@elluminate.com
Mon Jun 7 19:34:00 GMT 2004


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.

If I remove -nostdlib, I get the initialization section, but
I also get dynamic library dependencies on libstdc++.so.5 and
libgcc_s.so.1. A test executable linked with the lib, and with
libgcc and libstdc++ available via LD_LIBRARY_PATH, works as
expected. However, we cannot depend on these libraries being
present (unless we include them in the JNLP download, which is
not practical due to the 9MB combined size).

Looking at the archives for this list, this question pops up
a few times, but in all cases I found, the cause was using
some other linker (e.g. ld), instead of g++. I added a -v to
my makefile and verified that the linker in use is collect2.

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.

Am I doing something wrong in my link command, or is this a
limitation of gcc? Is anyone doing this successfully with gcc
on Solaris?



More information about the Gcc-help mailing list