Re: frameworks, dynamic_cast and gcc 4.0
Re: frameworks, dynamic_cast and gcc 4.0
- Subject: Re: frameworks, dynamic_cast and gcc 4.0
- From: Andreas Grosam <email@hidden>
- Date: Tue, 23 Aug 2005 16:59:17 +0200
On 23.08.2005, at 15:53, Stephan Huber wrote:
Hi Andreas,
firstly thanks a lot for all your input.
Secondly, a few questions:
1) are you using gcc-4.x for ALL your sources?
yes.
2) do you use the shared library version of the std C++ lib? (will be
*implicitly* linked to your products!)
yes. (otool says this)
3) does the app link without link errors?
yes. no errors.
4) in case of gcc-4, did you "export" the classes in question
propperly (look for "symbols visibility").
The symbols are visible, (the default option), but nevertheless I
exported all the classes with the appropriate settings.
note: for gcc-4 and gcc-3, the default for symbol visibility is
"default", which means they are all exported.
(note: visibility is either "hidden" or "default", and the former
means "private and the "latter means "exported", odd yes)
However, in XCode, for shared libraries, the default build settings are
set such that the visibility is "hidden" (private).
5) Triple-check, that your are **indeed** linking against the
frameworks you intend to!! Often, when starting the program, the
dynamic linker may fool you and link against others (old versions?)
frameworks (not really, *you* made an error, but it is not that
obvious in XCode ).
I checked that again, and I am sure, the frameworks are correct. I
embed all the necessary frameworks inside the app-bundle, and otool
reports the correct paths to the frameworks.
So firstly, you must not include the *module* where the class is
defined, in the calling DSO. This causes that two instances of RTTI
symbols will be created, and as a result, dynamic_cast might fail.
How should I do that? Sorry, I don't understand...
If you propperly link against the DSO where the class is defined, you
couldn't compile successfully anyway, because you would get link
errors. Just ensure, you *link* against the DSO where the class is
defined - and do *not* include the modul (.cpp) where the class is
defined in the set of source files of the DSO where you perform the
dynamic cast.
Please clarify:
Which type of objects do you create in DSO app?
Sorry, things went a little bit wrong in my last e-mail. Here is the
right scenario:
My class is a "simple object" no singleton, not static etc. It is
defined in my application (DSO 3). It has two baseclasses, one is
defined in my custom framework (DSO 1), and the other base-class (with
all its base-classes) is defined in another framework (DSO 2)
The baseclass defined in DSO 1 is an abstract class, completely
defined in the header.
How many DSOs are involved (including the app)?
In my minimal setup: three.
In which DSO do you invoke the dynamic_cast?
I create new instances inside the application (DSO 3) and hand them to
DSO 2, which calls a function in DSO 1, which processes my objects and
there the dynamic cast fails inside (DSO 1). The dynamic_cast does NOT
fail in DSO 3.
k,
so firstly, since you create an object in DSO 3, which has base classes
defined in DSO 2, you need to link DSO 3 against DSO 2.
Furthermore, you need link DSO 2 against DSO 1, since a class in DSO 2
inherits from a base in DSO 1.
For your App, unless you do not directly reference symbols from DSO 1,
you need not link App against DSO 1, for this case though. (IFF i'm
remember right, since the dynamic linker transparently resolves symbols
from DSO 3 through DSO 2 to DSO 1).
Well, since you invoke the dynamic cast in DSO 1, for a class which is
defined in DSO 3 (App), you need to link DSO 1 against DSO 3. That
might seem odd, since DSO 3 is your application. But this seems to be
the case.
If this is not possible, try to create another DSO, say DSO 4, and
define the class there. Then link DSO 3 (the app) against DSO 4, and as
well link DSO 1 against DSO 4.
Then you get this picture:
App --> DSO 2 (Derived)
\-> DSO 4 (Super)
DSO 2 --> DSO 1 (base)
DSO 1 --> DSO 4 (Super)
Hope this helps. Please msg me about your results, thanks.
INFO: In XCode, for an Application product, the default build settings
for symbol visibility are "exported" (aka "default" for the compiler,
"extern" for the linker).
Andreas
Here's the real world scenario: I am using a scene-graph which renders
objects, called Geodes (defined in DSO2). The whole scenegraph is
inside a framework (DSO 2). Then I implemented a custom routine
(inside DSO1), which handles picking of the objects with the mouse.
Only objects get picked which has also a baseclass called Pickable
(which is defined in DSO1).
Yep, search again. Look for how to export symbols in gcc with the
__attribute__ spec.
Then define some handy macros. There is already enough info in this
list, go figure.
So, I figured it out, and no, it does not make any difference. The
problem with dynamic_cast remains.
Thanks again for all your valuable input!
Stephan
_______________________________________________
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