portability of shared libraries

[Zagorodnev, Grigory]

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@gcc.gnu.org [mailto:gcc-help-owner@gcc.gnu.org] On
>Behalf Of dave fournier
>Sent: Tuesday, April 05, 2005 9:39 PM
>To: gcc-help@gcc.gnu.org
>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