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

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

[lrtaylor]

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.

Thanks,
Lyle


-----Original Message-----
From: gcc-help-owner@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
Behalf Of Doug Zwick
Sent: Monday, June 07, 2004 3:17 PM
To: gcc-help@gcc.gnu.org
Cc: csc@cadence.com
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:
     g++ -print-file-name=libgcc_eh.a
or
     g++ -print-file-name=libstdc++.a

Re: 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

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

[Doug Zwick]

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?