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

-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

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

[Ian Lance Taylor]

Bob Rossi <bob@brasko.net> writes:

> 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)?

If the shared object is dynamically linked against libstdc++.so, then
the dynamic linker will look for a libstdc++.so to satisfy that
requirement.  If the only one it finds is the system one, then it will
link that one into the process.  If the shared object requires symbols
with versions which are not present in the libstdc++.so that the
dynamic linker finds, then the dynamic linker will report a version
dependency error.

In short, yes, you will get the same errors.


> 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.

On a sufficiently new system, it will work if you have the same
version of libgcc and libstdc++ statically linked into your executable
and your shared object.  "Sufficiently new" means that the linker
supports the --eh-frame-hdr and that the compiler uses it when
linking.  You can detect this by seeing whether readelf -l on your
executable and shared library shows a GNU_EH_FRAME program header.

Ian