This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
-static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling.
- From: Bob Rossi <bob at brasko dot net>
- To: gcc-help at gcc dot gnu dot org
- Date: Sat, 15 Jan 2011 14:12:19 -0500
- Subject: -static-libgcc, static libstdc++.a, dynamically loaded so files and exception handling.
Hi,
I've got a main C++ executable that I am linking with
-static-libgcc and libstdc++.a. This works fine.
I'm doing this to make linux distribution easier.
I've also got a C shared object library which I load from the
main executable. The C shared object library, has function pointers
which get registered in it from the main executable. So this happens,
- the main executable loads the shared object
- the main executable sets function pointers in the shared object
- the main executable calls a function in the loaded shared object file
- the shared object file calls a function pointer getting back into
the main executable
- an exception is thrown from the main executable (nested in the call
stack of the shared object)
- the exception propogates through the shared object interface and
is caught in the main executable again.
Is this use of -static-libgcc, libstdc++.a, shared objects and
exceptions safe in all known configurations?
I'm worried about this text from the gcc documentation related
to the static-ligcc option,
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.
although, I don't think what I'm doing is related to what this text
is discussing.
Thanks,
Bob