Re: libgcc_s dependency when linking with -shared

[Ian Lance Taylor <iant at google dot com>]

ejohanson <epj@newpointtech.com> writes:

> I gave the -static-libgcc option a try, and ldd no longer reports a
> dependency on libgcc_s.so, but the the application instantly crashes on the
> call to dlopen() to load the shared library.  So it seems like libgcc_s is
> still in there-- it's just that now it's staticly linked as opposed to
> dynamic.

Sure.  That is exactly what happens with libgcc when you use
-static-libgcc.  Why are you focusing on libgcc as the problem?  What
led you to look at that?


> file f1.c:
> void dummyfunc(void) {
>     /* make a single function call into the 3rd-party library to force
> linking against their ".a" lib */
> }
> 
> file f2.c
> main() {
>     dlopen("f1.so",RTLD_NOW|RTLD_GLOBAL);
> }
> 
> the above two files are compiled like this on solaris 8 x86 intel:
> gcc -static-libgcc -shared -fPIC f1.c -o f1.so thirdparty.a
> gcc -static-libgcc -o f2 f2.c -ldl
> 
> when i try to run f2, it segfaults on the call to dlopen which tries to open
> f1.so.  the two files are literally as simple as the ones shown above (i am
> not oversimplifying this example for the sake of the message board).

There are a number of possibilities here.  You should be able to use a
debugger to see if the crash is occurring in a global constructor.
You should be able to use ld.so debugging (e.g., set the environment
variable LD_DEBUG, if that works on Solaris) to see where the crash
might be happening in the dynamic linker.

Ian