Hi
I am sure there are some people who have gone through this problem, but
could not find specific solution to this.

I am using GCC 3.3.2, on Solaris 5.8 and I have a shared object using
lots of C++ code and STL classes too in it. This module is now built as
shared library, and I link stdc++ statically to it. Now executable
which links to this so, gives segmentation fault for STL functions.
I do see STL functions are defined in so with nm command.

Note that EXE and so are linked with same gcc version and with same C
runtime libraries. I use -G which works fine but -shared gives errors
of locations for functions.

I use following way of linking.
g++ -o libMy.so.1.0 -D_DEBUG -g -D_REENTRANT -D_POSIX_PTHREAD_SEMANTICS
-O3 -static-libgcc -nostdlib ../src/M.d  ../src/A.d  ../src/C.d
-L/usr/lib -L/usr/local/lib -L/usr/ccs/bin -L/usr/ccs/lib -G
-Wl,-Bstatic -lstdc++ -lgcc_eh -lgcc -Wl,-Bdynamic -lpthread -lposix4
-lc

I am able to get everything fine when I link libstdc++ dynamically to
so, but I do not want this for some reason.

Thanks,
Nilesh Gujarathi

[ Post a follow-up to this message ]

Nilesh wrote:

> I am using GCC 3.3.2, on Solaris 5.8 and I have a shared object using
> lots of C++ code and STL classes too in it. This module is now built as
> shared library, and I link stdc++ statically to it. Now executable
> which links to this so, gives segmentation fault for STL functions.
> I do see STL functions are defined in so with nm command.

[]

> I am able to get everything fine when I link libstdc++ dynamically to
> so, but I do not want this for some reason.

This is probably because doing so you get two c++ runtimes in your
process. Memory allocated by one can not be freed by another.

The solution to this is either link to libstdc++ dynamically, so that
you get single c++ runtime in your process, or rewrite the .so and its
users so that memory get allocated and freed in the same module.

[ Post a follow-up to this message ]

Hi Maxim and Paul
Thanks for your comments.

I had tried this to verify if newing in so and deleting in EXE is a
problem,- created  a global pointer in so, and allocated the pointer in
the code that is in so, and then deleted the pointer in the code that
is in EXE. EXE did not crash but worked fine. I also read that such
scenario will crash when CRT of DSO and EXE are different or compiled
with different compilers which is more plausible, i guess.

So it seems what Paul is saying is true.

I am using libstdc++.a that comes with gcc 3.3.2 installables from
sunfreeware.com and have notdone recompile with -fPIC . If i use -share
instead og -G it does give me lots of location errors.:-)  I will
recompile with -fPIC and checkl, do you know if there is such alrteady
compiled library at gun.org?

I did not want libstdc++ to be bundled just to avoid any possible
conflicts at any deployments..
I guess, are you sure, per GPL text I am not changing any stdc++ code
and am using using as is, and thats why I am not liable to make my so
GPL.

Thanks.
Nilesh

[ Post a follow-up to this message ]

Paul Pluzhnikov wrote:

[]

> Maxim,
> You are mistaken (carrying with you Win32 garbage).
> On UNIX, memory allocated (via malloc(), calloc(), realloc(),
> etc.) by one DSO can be free()d by another DSO or the main executable
> (under all "normal" circumstances).

Sorry, I was under impression that this held true for UNIX also.

libstdc++ allocator does caching. Will there be any problems when
memory allocated and freed by allocators in different DSOs?

[ Post a follow-up to this message ]

Paul Pluzhnikov wrote:

[]

> Maxim,
> You are mistaken (carrying with you Win32 garbage).
> On UNIX, memory allocated (via malloc(), calloc(), realloc(),
> etc.) by one DSO can be free()d by another DSO or the main executable
> (under all "normal" circumstances).

Does it work because the dynamic linker binds references to malloc/free
in all modules to the same ones?

[ Post a follow-up to this message ]

Maxim

I checked the license terms and specially
http://gcc.gnu.org/onlinedocs/libst...ro/license.html
Below FAQ 3rd question specifically allows the non-free softwares to
use the libstdc++ library.

Q: So any program which uses libstdc++ falls under the GPL?
A: No. The special exception permits use of the library in proprietary
applications.

Q: How is that different from the GNU {Lesser,Library} GPL?
A: The LGPL requires that users be able to replace the LGPL code with a
modified version; this is trivial if the library in question is a C
shared library. But there's no way to make that work with C++, where
much of the library consists of inline functions and templates, which
are expanded inside the code that uses the library. So to allow people
to replace the library code, someone using the library would have to
distribute their own source, rendering the LGPL equivalent to the GPL.

Q: I see. So, what restrictions are there on programs that use the
library?
A: None. We encourage such programs to be released as open source, but
we won't punish you or sue you if you choose otherwise.
******
Thanks,
Nilesh

[ Post a follow-up to this message ]