Hi Christian, 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
This archive was generated by hypermail 2b29 : Tue Jan 04 2000 - 00:43:34 MET