Re: gcc 3.3 and exceptions across dynamic libs
Re: gcc 3.3 and exceptions across dynamic libs
- Subject: Re: gcc 3.3 and exceptions across dynamic libs
- From: Paul Forgey <email@hidden>
- Date: Sat, 8 Apr 2006 23:38:57 -0700
We ran into something like this on Linux, which uses ELF and
therefore different linker options. I think you can still get at the
basic idea with the darwin specific tools, but you'll have to poke
around the linker options.
The ELF based linkers have an -export-dynamic (or something like
that) option which makes the linker output's symbols visible to any
shared libraries it loads.
So what you do is link against the static libg++ in your main
executables, but not in your shared libraries. For all your
executables and shared libraries, use the option to make all your
symbols visible.
That's what worked for us anyway.
A cleaner solution might be to make a shared libg++ of your own by
making a dynamic library exporting all symbols from the static libg+
+. Then tell your executables and shared libraries not to link
against the static libg++ and use your own library instead.
The downside to any of this is if another application not following
these rules links against any of your libraries it all breaks.
I haven't needed to do with with pre-g++ 4.0 on Mac OS so I can't
tell you if this solution will work on this platform.
On Apr 7, 2006, at 7:07 PM, David Litwin wrote:
I’m having some trouble with exceptions across dynamic libs with
gcc 3.3. All works well with gcc4.0.
This situation is a bit complex, but can be summarized as follows:
There is code in one dynamic lib that has a throw and catch. In
the catch, it calls to another dynamic lib which does a rethrow of
the exception.
The code fails on the re-throw, because it has lost track of the
exception and thinks the re-throw is happening outside of a catch
block, so it terminates. This seems to happen because each of my
dynamic libraries has its own __cxa_begin_catch, __cxa_throw and
__cxa_rethrow, and I suspect that there should only be one. With
gcc4.0 there is the dynamic libg++, and so there is only one set of
code for these routines.
What I’ve been able to piece together so far indicates that when
the implementation of __cxa_begin_catch gets the globals
(__cxa_get_globals) so it can store the exception it is catching,
it is getting a different memory address across the different
shared lib versions (and certainly a different address than the
__cxa_throw call to __cxa_get_globals). So when one dylib handles
the catch and sets up the exception, then calls through to another
dylib which does the re-throw, the re-throw can’t find the
exception because it is looking in the wrong place.
Does anyone have any experience with anything like this? We had to
do some work with symbol visibility (export everything) in gcc4.0
to get the run time type information properly hooking up across
dynamic libs, but this seems more related to the static libc++ of
gcc3.3 vs. the dynamic libc++ of gcc4.0.
My current thoughts are to create a dynamic lib containing just
some dummy throw and catch code, and adding an export file to
export the __cxa* calls. Then I’ll have to add similar import
files on all my other .dylibs in the hopes that they will all wind
up sharing the same version. But I’m not sure if that is going to
work, and it would be a pain.
Does anyone have any good ideas?
Thanks,
David Litwin
BigFix
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40aphrodite.com
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden