Hi Steve, On Tue, 27 Aug 2002 11:12:19 -0500 Stephen Sanders <ssanders@ku.edu> wrote concerning "Problem with brat on Mac OSX": > Hi Christian, > I'll post more information once I do some more checks, but the core > symptom is seen playing with bratroot. > > In bratroot I can create instances of all classes located in the first > brat > library referenced in the link statement (libBratDataAbc). However, if I > try to access any class NOT in this library, I get an error saying the > class was > not found. > > Below is typical: (also notice the warnings; maybe significant?) > > [kunuc5:brat/applications/bratroot] sanders% > [2] + Done xemacs BrRintDict.cxx > [1] + Done xemacs make.log > [kunuc5:brat/applications/bratroot] sanders% bratroot Try to install the stuff first. My guess is that you're not loading the libraries properly from the source directory. > Warning in <TClassTable::Add>: class TVector allready in TClassTable Do you statically link the libraries to the executable? Does ROOT on MacOSX load more libraries than on GNU/Linux? > brat [0] BrEventIO * io = new BrEventIO("name","name") > Error: Symbol BrEventIO is not defined in current scope Try `ldd bratroot' (substitute the `ldd' for the MacOSX equivalent) and check if it lists the BRAT libraries. If it doesn't someting is wrong with your link. Can you link an executable? (try one in the test directories). Can you run it? > > Compiled headers? We do not compile headers. CINT has this odd idea > > of `precompiled headers' - like with MSVC - which I must confese I > > don't truely understand. Could you give a bit more info? thanks. Ah, I see what you mean. You're talking about the _dictonaries_ here. The CINT dictionaries are C (yes, plain C) functions to wrap C++ method calls, and collected into a table. This is needed in the interactive environment, as it is not possible to use the names of the methods directly, as they are mangled (and that the mangling is different for different compilers - a recomendation in ARM in fact). So if you have the class class Foo { private: int _foo; public: Foo(int foo) : _foo(foo) {} int GetIt() const { return _foo; } void SetIt(int foo) { _foo = foo; } }; CINT will create C functions like static int G__Foo_Foo_0_0(G__value *result7, G__CONST char *funcname, struct G__param *libp, int hash) { result->ref = new(ptr) Foo((int)libp->para[0]); ... } and so when you write cint> Foo* foo = new Foo(1); CINT will try to find the symbol `G__Foo_Foo_0_0' in the library and then call that via a dl_pointer, passing it the needed arguments. This is what is meant by a dictionary, and how it works. That is also the reason why the BRAT libraries are so large - they need to have all this extra stuff in them for interactively calling the member functions. Yours, ____ | Christian Holm Christensen |_| | ------------------------------------------------------------- | | Address: Sankt Hansgade 23, 1. th. Phone: (+45) 35 35 96 91 _| DK-2200 Copenhagen N Cell: (+45) 24 61 85 91 _| Denmark Office: (+45) 353 25 305 ____| Email: cholm@nbi.dk Web: www.nbi.dk/~cholm | |
This archive was generated by hypermail 2b30 : Tue Aug 27 2002 - 13:31:58 EDT