ejohanson <epj@xxxxxxxxxxxxxxxx> writes:
> ok, the global constructors in the 3rd party library seem to work fine when
> you create an executable. it's only when you create a ".so" shared object
> link against the 3rd party library and then use dlopen() to load the module
> that this problem occurs.
Do you mean something like:
gcc mycode.o mylib.o -l3rdparty
works, but
gcc -shared -o foo.so mylib.o -l3rdparty
gcc mycode.o
where mycode.o does dlopen("foo.so"), fails?
> when i link to create executable, libgcc_s is not referenced. when i link
> to form a shared object, libgcc_s is referenced (by ldd).
This is not unusual.
> maybe it's not libgcc_s, i certainly can't prove it. if not, then i am
> stuck. why else might a 3rd part library work when in executable form, but
> crash on dlopen when in shared object form?
There are any number of possible reasons. And it could even be
libgcc_s.so. But I think you need to figure out what the problem is,
rather than just try to eliminate libgcc_s.so.
Ian
