ejohanson <epj@xxxxxxxxxxxxxxxx> 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
