This is the mail archive of the
mailing list for the GCC project.
RE: Shared C++ JNI library on Solaris -- no Static Initializers
- From: lrtaylor at micron dot com
- To: <dougz at elluminate dot com>, <gcc-help at gcc dot gnu dot org>
- Cc: <csc at cadence dot com>
- Date: Mon, 7 Jun 2004 18:06:38 -0600
- Subject: RE: Shared C++ JNI library on Solaris -- no Static Initializers
You could also accomplish the same thing by temporarily moving the
shared GCC libraries out of the way while you build this. It would then
be forced to use the static libraries.
From: email@example.com [mailto:firstname.lastname@example.org] On
Behalf Of Doug Zwick
Sent: Monday, June 07, 2004 3:17 PM
Subject: Re: Shared C++ JNI library on Solaris -- no Static Initializers
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: