[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: string STL assignment in g++ shared object crashes with core
From: |
Paul Pluzhnikov |
Subject: |
Re: string STL assignment in g++ shared object crashes with core |
Date: |
Wed, 20 Sep 2006 20:02:39 -0700 |
User-agent: |
Gnus/5.1006 (Gnus v5.10.6) XEmacs/21.4 (Jumbo Shrimp, linux) |
"Nilesh" <nileshg@gmail.com> writes:
> I am using my own shared object to link it dynamically to a program
> exe. The EXE makes a call to function in .so, in which l_str=
> "somestring"; code causes a core.
Just *how* did you come to that conclusion?
None of the info you posted points to "l_str = ..." statement.
> the way I build .so is like this:
> ======================
> g++ -D_DEBUG -g -shared -o libiif.so -O3 -v -Wl,-bexpfull -Wl,-G
> -Wl,-brtl ../src/BMCIIF_Source.d -L/usr/lib/threads -L../lib_aix
> -L../lib -L/usr/local/lib -L/usr/lib -lstdc++ -liiapi -lm -lnsl
> -lpthread -lnsl -lm -lc -ltli
You appear to be using "unconventional" naming -- I assume
BMCIIF_Source.d is actually an object file.
Adding -lstdc++ and -lc is entirely bogus (g++ will add them itself),
but this shouldn't cause a crash.
Also, my (incomplete) understanding is that you do not need -brtl
when linking the shared object, only when linking the main exe. But
this should no cause a crash either.
> The way I use it in EXE is as follows:
> ============================
> g++ -o PROGRAMEXE../src/main.o -O3 -v -L/usr/lib/threads
> -L/usr/local/lib -L/usr/lib -L./../../libs/aix -lstdc++ -lgcc -lgcc_eh
> -liiapi -lm -lnsl -lpthread -lc
> -Wl,-blibpath:/home/work/product/libs/aix -Wl,-brtl -liif
Again, -lstdc++ -lgcc -lgcc_eh and -lc are bogus.
What happens if you remove them all?
> After running this it gives a core at the source code containing
> following code in BMCIIF_Source.cpp:
> string l_str;
> l_str = "somethingstring";
You show absolutely no evidence that that source has anything to
do with the problem.
> The core trace shows:
> =================
> Program terminated with signal 11, Segmentation fault.
> #0 0xd025deb8 in ?? () from /usr/lib/libc.a(shr.o)
Gdb was not able to interpret core correctly.
I've seen this happen on aix, and switching to a different version
of gdb helps sometimes.
What happens if you run the program under gdb from the start?
Cheers,
--
In order to understand recursion you must first understand recursion.
Remove /-nsp/ for email.