the binaries of the current release (2.22/0x) are compiled with RTTI
and exception info enabled by default. So there should be no problem
concerning that anymore. We never had missing vtbl's.
Cheers, Fons.
Christian Holm Christensen wrote:
>
> Hi Olivier,
>
> Well, I know Rene has answered you, but I think a couple of comments
> is in order.
>
> First of, you can find out which references that are unresolved in a
> object or library file, using the standard Unix command `nm'. Asuming
> your obejct/library file is <file>.o (or .so for shared library) the
> command line would be
>
> $ nm <file>.o | more
>
> The pipe is used, since the output of `nm' is bound to be rather
> lengthy. Please refer to manpage nm(1).
>
> Incidently, you ld output shows member names like `__vtbl_8Detector',
> where the `__vtbl' part properly stands for `virtual table'. (On
> systems that support it, passing the `-C' swtich to `nm' causes member
> `__vtbl_8Detector' to be displayed as `Detector virtual table', making
> it more human readable). What you are missing is the virtual table for
> the class `Detector', i.e. it isn't present in any of the object files
> you thus far has created. Now how to create the virtual table, in
> paricular, which object file it should be in, is quite tricky and
> compiler dependant. If you use GCC the virtual table (and the two
> other members `type_info function' `type_info node') goes into the
> file where the first declared (in the class declaration) non-inline
> function is defined. That is the first the first function in the class
> header, that doesn't have it's full definitionin that file. Other
> complierrs may (and some does) use another scheme - there is no
> standard way of handling those things. You should refer to your
> compiler documentation for more info on this topic. However, the
> output of ld in your case suggest you use GCC.
>
> A final word. Some of the precompiled ROOT libraries from CERN
> (root.cern.ch) DOES NOT contain `virtual table', `type_info function'
> and/or `type_info node' for each class. That means, that your object
> files should not reference those members, since they are nowhere
> present on the system. (In EGCS there is a `#pragma' directive
> `implementation <object>', that may create the needed members). So you
> need to pass some option to your compiler that instructs it not to
> reference these members. This will mean a loss of security in your
> linked file, and really why the ROOT team ships libraries without
> those members are beyond me (perhaps Rene would like to elaborate). I
> solved that problem on my Linux machine, by recompiling ROOT, making
> sure the above members where in the libraries.
>
> Hope that was of some help.
>
> Cheers,
>
> Christian
> ----------------------------------------------------------------
> Christian Holm Christensen Phone: (+45) 35 35 96 91
> Sankt Hansgade 23. 1, th Office: (+45) 353 25 307
> DK-2200 Copenhagen N Email: cholm@nbi.dk
> Denmark Homepage: www.nbi.dk/~cholm
-- Org: CERN, European Laboratory for Particle Physics. Mail: 1211 Geneve 23, Switzerland E-Mail: Fons.Rademakers@cern.ch Phone: +41 22 7679248 WWW: http://root.cern.ch/~rdm/ Fax: +41 22 7677910