• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: C++ RTTI/dynamic_cast across shared module boundaries?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: C++ RTTI/dynamic_cast across shared module boundaries?


  • Subject: Re: C++ RTTI/dynamic_cast across shared module boundaries?
  • From: Michael Rice <email@hidden>
  • Date: Sat, 18 Feb 2006 00:43:16 -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.

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
  • Follow-Ups:
    • Re: C++ RTTI/dynamic_cast across shared module boundaries?
      • From: Zachary Pincus <email@hidden>
References: 
 >C++ RTTI/dynamic_cast across shared module boundaries? (From: Zachary Pincus <email@hidden>)
 >Re: C++ RTTI/dynamic_cast across shared module boundaries? (From: Howard Hinnant <email@hidden>)
 >Re: C++ RTTI/dynamic_cast across shared module boundaries? (From: Zachary Pincus <email@hidden>)
 >Re: C++ RTTI/dynamic_cast across shared module boundaries? (From: Michael Rice <email@hidden>)
 >Re: C++ RTTI/dynamic_cast across shared module boundaries? (From: Zachary Pincus <email@hidden>)

  • Prev by Date: Re: Universal Cocoa plug-in
  • Next by Date: Re: Universal Cocoa plug-in
  • Previous by thread: Re: C++ RTTI/dynamic_cast across shared module boundaries?
  • Next by thread: Re: C++ RTTI/dynamic_cast across shared module boundaries?
  • Index(es):
    • Date
    • Thread