This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

Bob Rossi <> writes:

> The shared object has a dependency on 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 shared object file) or will
> it just pull in the system (thus giving me the initial
> C++ link errors in the first place)?

If the shared object is dynamically linked against, then
the dynamic linker will look for a 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 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]