I’m trying to build a loadable shared library on my MacOSX 10.3.9 iBook, for use with ROOT 4.04/02g (CERN’s binary distribution). I have successfully compile my classes and put them into a self-contained shared library (using the .so suffix, since ROOT 4.04/02 doesn’t recognize .dylib).
When I load this library using
gSystem->Load("libCfgDBFactoryR_root");
(about the name, don’t ask :-), the command completes without error. However, if I try to open a ROOT file containing objects of my class types, I get a long cascade of TClass errors claiming “no class dictionary” for any of them! I have run into this problem with every one of my ROOT files, with many different sets of objects.
Because I’m working in the BaBar software framework, my actual link command is extremely long. However, the key issue is the set of linker flags I’m using, which is quite short:
Are there additional flags I need to specify in order for the class dictionaries to be properly recognized on MacOSX? With the exact same source code, I do not see these errors building on Linux (SL3).
on MacOS X < 10.4 you have to create bundles (.so) for libraries you want to dynamically load during running. Dylibs (.dylib) are used to link your program against and bundles are used as plugins. The main difference between the two is that .dylib’s don’t initialize global static symbols when they are loaded, and bundles do. The link sequence you used is for dylibs and hence the dictionary does not get initialized since that happens via a global static symbol. You create bundles using:
Note that all this nonsense has been fixed in Tiger (10.4) where .dylibs can be used as .so’s (with the only remaining difference between the two that dylib export all their symbols while bundles don’t). In ROOT on Tiger you we do: ln -s bla.dylib bla.so
Thank you very much, Fons! Especially for the clear explanation of the difference between .dylib’s and .so’s. I’ll make the modification above and see how it works.
– Michael Kelsey