Re: Segmentation fault of shared libraries

[wsonguci at my-deja dot com]

In article <864sfd9mdi.fsf@hwiw01.hyperwave.com>,
  Joerg Faschingbauer <jfasch@hyperwave.com> wrote:
> 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
>

Hi, Joerg

Thanks for the suggestion.

I tried 'gdb main core'. After 'Reading symbols from ....',
Gdb shows '#0 0x0 in ?? ()'

Actually the segmentation fault happens before any statements
in the main() function of the main.cpp, because it happened even
I put 'return 0' as the first statement in the main() function.

-Song


Sent via Deja.com http://www.deja.com/
Before you buy.