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: "David Litwin" <email@hidden>
- Date: Mon, 10 Apr 2006 16:54:26 -0700
- Thread-topic: gcc 3.3 and exceptions across dynamic libs
So basically it looks like simulating the gcc4.0 shared libc++ lib seems
my best bet, but how might this be done?
I've built a shared lib for just this purpose, but it isn't clear how to
get it to pull in the proper code from the static libc++. I've tried
the -u <sym> linker flag, but that seems completely ignored.
Separately, I've also tried the -exported_symbols_list and that doesn't
seem to change any 't' symbols to 'T'.
Guys at Apple: How might I do this?
If creating my own dynamic libg++ is the wrong way to go about it, how
might I get my .dylibs to properly export their exception handling
routines such that they are properly coalesced to one version on link?
Thanks,
David Litwin
BigFix
-----Original Message-----
From: Paul Forgey [mailto:email@hidden]
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