-static-libgcc, static libstdc++.a and dynamicly loaded so files

[Bob Rossi]

Hi,

I'm attempting to make a binary release of a C++ application on
Linux that was compiled with g++. As soon as I tried this release
on different platforms, I found errors like this,
  /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.11' not found
  /usr/lib/libstdc++.so.6: version `GLIBCXX_3.4.9' not found
  /lib/tls/i686/cmov/libc.so.6: version `GLIBC_2.7' not found

I now understand that building the binary with newer libraries
isn't the ideal solution. With that in mind, I will link against
an older GLIBC. I also decided it might be a good idea to link
the C++ libraries statically, since that would simply remove
the dependency on the C++ library.

My program consists of a C++ executable, and a few C++
shared object libraries that are loaded at runtime with dlopen.

I use the -static-libgcc and I link in the libstdc++.a library
statically when I create the executable. When I create the
shared object library, I do not use the -static-libgcc option
and I link in the libstdc++.so library dynamically.

Thanks for reading this far, I have a few questions now.

--

The shared object has a dependency on libstdc++.so. When I open it
with dlopen from the statically linked executable, will the dynamic
linker grab all the libstdc++ symbols from the executable (and avoid
a dependency on the system libstdc++.so shared object file) or will
it just pull in the system libstdc++.so (thus giving me the initial
C++ link errors in the first place)?

--

My next question involves throwing C++ exceptions across shared
object files. The documentation for -static-libgcc says, 

  There are several situations in which an application should use the
  shared libgcc instead of the static version. The most common of these is
  when the application wishes to throw and catch exceptions across
  different shared libraries. In that case, each of the libraries as well
  as the application itself should use the shared libgcc. 

The documentation describes that throwing exceptions across shared
object libraries require a dynamic libgcc. Is this true, even if
the statically linked executable (both -static-libgcc and static 
libstdc++.a) and the shared object files (dynamic libgcc and
libstdc++.a) are guarenteed to be compiled with the same 
libgcc and libstdc++? I distribute the executable and the 
shared object libraries together. I have complete control over this.

I wasn't clear if the dynamically loaded shared object
files should be linked with either a static libgcc, a static
libstdc++, both static or neither. For now they are both
dynamic, and things seem to work OK on the system I built them
on.

Any advice would be really appreciated.

Thanks,
Bob Rossi