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 06:52:30 -0600
I've not tried this on OS X (my problems were on Linux, IRIX, and
Solaris). However, I assume (maybe incorrectly) the problem exists
in all GCC implementations. I also have not tried this in GCC 4, we
were using GCC 3. Maybe the problem identified in the FAQ was fixed
in GCC 4? If so, that would be fantastic.
The problem we had is that we were using dynamic_cast as a method
for implementing a plug-in architecture. The dynamic_cast was used
to access data types provided by each plug-in. The problem we ran
into was that some of our plug-ins were also libraries that others
linked to. We had tons of duplicate symbol errors when we exported
all symbols.
This is definitely the same species of difficulty that I'm having:
dynamic_cast used for data types across plugins. I'm sure there's
some little OS X-specific twist with how gcc works that I'm just not
understanding. Arrg.
Zach
On Feb 17, 2006, at 9:33 PM, Zachary Pincus wrote:
Michael,
Thanks for this information! That's exactly what I was looking for.
I assume that you're saying linking with "-Wl,-E" (as specified on
the web page you referred) isn't a good solution because it
exports all global symbols. Our of curiosity, what about exporting
all the global symbols is bad? Just that it increases the
potential for symbol-name collisions?
Zach
On Feb 17, 2006, at 6:55 PM, Michael Rice wrote:
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.
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