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@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On Behalf Of Doug Zwick Sent: Monday, June 07, 2004 3:17 PM To: gcc-help@xxxxxxxxxxx Cc: csc@xxxxxxxxxxx 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
