Re: Segmentation fault of shared libraries

[Joerg Faschingbauer <jfasch at hyperwave dot com>]

wsonguci@my-deja.com writes:

> Hi, folks
> 
> I used gcc/g++ 2.8.1 to build a shared library under solaris 7 x86 like:
> g++ -g -D_REENTRANT -fpic -shared -o libmylib.so file1.o file2.o
> 
> Then I used a main.cpp to test the shared library like
> g++ -g -o main main.cpp -lmylib
> 
> But when I run 'main', I got 'Segmentation fault (core dumped)'.
> It happens even before main() function gets executed. I guess
> it happens when the run-time system tries to load the shared
> library libmylib.so. ( I tried to use dlopen("libmylib.so",RTLD_LAZY),
> the same problem happened when dlopen was called )
> 
> Could anyone help me how to figure this out? Are there any
> special compiler or linker switches to build the shared library?

Have you tried gdb? 

When a C++ shared library is loaded (either by the dynamic loader or
explicitly), constructors of global objects get called. It's not
always trivial to ensure that this happens correctly (i.e., in the
right order) because a global object of class A might depend a global
object of class B being already initialized. C++ makes no guarantees
about in which order the ctors in file1.o and file2.o are
called. (Though it guarantees that the ctors in, say, file1.o itself
are called in order of declaration.)

Joerg