Libstdc++ is linked statically into your DSO. At run-time, however,
dynamic loader may (justly) mess up its symbols with those from "target"
libstdc++. That may cause some failures.
So the possible solution for you is to hide libstdc++ symbols from
run-time dynamic linking by means of a version script. Script like this
will hide all symbols except those you define as global-visible:
FOO {
global:
<your symbols>;
local:
*;
};
Use "-Wl,--version-script,script.name" to feed script to the linker.
---
Grigory Zagorodnev
Intel Corporation
>-----Original Message-----
>From: gcc-help-owner@xxxxxxxxxxx [mailto:gcc-help-owner@xxxxxxxxxxx] On
>Behalf Of dave fournier
>Sent: Tuesday, April 05, 2005 9:39 PM
>To: gcc-help@xxxxxxxxxxx
>Subject: portability of shared libraries
>
>Hi,
>
>I have been trying to make a shared library that is portable
>between different Linux versions. It is compiled on FC3 and
>runs fine on FC2 and Mandrake 9.1. However it crashes on
>RH8. I have compiled it with
>
> g++ x.c -shared -o nbmm.so -static-libgcc -shared -o $1.so \
> -Xlinker -static -lado
>
>When it crashes in RH8 the gdb stack trace reports
>
>Program received signal SIGSEGV, Segmentation fault.
>std::locale::operator=(std::locale const&) (this=0x403c23b8,
> __other=@0xbffff490)
> at
>/usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-
>linux/i386-redhat-linux/libstdc++-v3/include/i386-redhat-
>linux/bits/atomicity.h:40
>40
>/usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-
>linux/i386-redhat-linux/libstdc++-v3/include/i386-redhat-
>linux/bits/atomicity.h:
>No such file or directory.
> in
>/usr/src/build/146482-i386/BUILD/gcc-3.2-20020903/obj-i386-redhat-
>linux/i386-redhat-linux/libstdc++-v3/include/i386-redhat-
>linux/bits/atomicity.h
>
>which is related to the RH8 libraries since FC3 uses gcc3.4.2.
>
>So it appears to me that the shared library nbmm.so is still using
>calls to external libraries although ldd reports that it is statically
>linked. What I would like is to produce a shared library that does not
>use any external libraries if this is possible. Obviouslu I don't know
>what I am doing here. Any guidance would be appreciated.
>
> Cheers,
>
> Dave
>
>
>
>--
>Internal Virus Database is out-of-date.
>Checked by AVG Anti-Virus.
>Version: 7.0.300 / Virus Database: 266.4.0 - Release Date: 2/22/05
