Re: C++ RTTI/dynamic_cast across shared module boundaries?
Re: C++ RTTI/dynamic_cast across shared module boundaries?
- Subject: Re: C++ RTTI/dynamic_cast across shared module boundaries?
- From: Zachary Pincus <email@hidden>
- Date: Sat, 18 Feb 2006 00:13:22 -0600
It sounds like you are running into the C++ ABI described in the
GCC FAQ (http://gcc.gnu.org/faq.html#dso). I ran into this problem
long ago and have still to find a good, generic solution for this
problem (i.e., not having to export every symbol in the library).
My best solution so far has been to implement my own, less
efficient, RTTI system.
Wait, I'm not sure this is the problem.
The page you pointed to says this can be fixed with using RTLD_GLOBAL
and exporting all symbols from the library. The page refers to a
linker option '-E' to ensure that all symbols are exported. However,
Apple's ld (according to its man page, for what that's worth) doesn't
have a -E option to control symbol visibility. Instead, g++ has that
'-fvisibility=[default|hidden|...]', which I presume does the same
thing. Note that the default value is to generate public symbols, and
I'm using the default.
So -- is there a secret '-E' option I have to pass to ld in addition
to making sure that '-fvisibility' is not set to 'hidden'? Or is
there something else I have to do to get RTTI to work across DSOs on
OS X?
Moreover, looking at the symbols from the shared modules that I have
created, I see that each module exports the typeinfo and typeinfo
name for the shared types as 'weak external'. (As in my previous
email.) Presumably this means those symbols are public, no? Could
there then be a loader issue where since all of them are exported as
'weak', none is selected to be the 'main' typeinfo? That seems unlikely.
Otherwise, what else could I be doing wrong here? I'm totally mystified.
Zach
On Feb 17, 2006, at 8:43 AM, Zachary Pincus wrote:
Thanks Howard.
In the Code Generation build settings of all targets, uncheck
"Symbols Hidden by Default".
Right now, I'm not actually using XCode (part of my debugging was
to remove XCode from the mix and do all of the building and
linking directly on the command line, so I could easily fix
problem flags). There are absolutely no '-fvisibility=hidden'
flags on the link or compile command lines I have been using, so I
don't think symbols are being hidden. (Given that the man page for
g++ says that the default is for public visibility.)
Is there any way I verify this with, say, otool?
Also, a correction: telling Python to load with *either* dyld
flags of RTLD_LAZY|RTLD_GLOBAL *or* RTLD_NOW|RTLD_GLOBAL doesn't
help.
Zach
On Feb 17, 2006, at 8:24 AM, Howard Hinnant wrote:
On Feb 17, 2006, at 9:01 AM, Zachary Pincus wrote:
Hi folks,
I've been trying for a while to get c++ RTTI and dynamic casting
to work across the boundaries of several "bundle" shared
modules. I've spent a day looking at man pages and online, to no
avail.
In my case, instances of particular classes can be created in
various modules, but need to work (and dynamically cast
properly) when passed to other modules. (Before you ask: it's an
image processing library, where different image filter types are
defined in different modules, but they all need to be able to
send and receive the same image types.)
I've linked the modules as follows:
/usr/bin/c++ -bundle -o [output].so [object files] -L[link
paths] -l[link libs]
Now, how do I need to set up my environment to get RTTI and
dynamic_cast working across several such modules?
Right now, the module loader is Python, which I think uses
dlopen to load the modules. I've set the dlopen flags (in
python, sys.setdlopenflags()) to 0x9, which is RTLD_LAZY|
RTLD_GLOBAL (as they are defined in /usr/include/dlfcn.h), but
that really doesn't help. (Other permutations on the dlopen
flags don't help.)
Is there anything else I need to do? Is there anything else I
can try? Is this a hopeless project?
In the Code Generation build settings of all targets, uncheck
"Symbols Hidden by Default".
-Howard
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
40stanford.edu
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:
40knology.net
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