I have a small problem with two class we instantiate very early when loading the library: We have simple classes which inherit from TDatabasePDG and TParticlePDG (as we want to load particle data from the EvtGen pdl file instead of the root default). When loading the library the EvtGenDatabasePDG is created and filled with particle information from EvtGenParticlePDG. This way users can just use the normal TDatabasePDG and we have consistent particle data everywhere.
With ROOT 6.08/06 and C++11 it worked fine but now with 6.14/04 and C++17 I see
Error in <TClass::LoadClassInfo>: no interpreter information for class Belle2::EvtGenParticlePDG is available even though it has a TClass initialization routine.
Error in <TClass::LoadClassInfo>: no interpreter information for class Belle2::EvtGenParticlePDG is available even though it has a TClass initialization routine.
Error in <TClass::LoadClassInfo>: no interpreter information for class Belle2::EvtGenParticlePDG is available even though it has a TClass initialization routine.
I have a linkdef.h and compile a dictionary. If I disable the early loading of the class on library load the error disappears and I can use the class normally in python. If I don’t create any EvtGenParticlePDG early on (but fill the database with plain TParticlePDG objects) it also works fine.
Is there any way I can properly intialiize the EvtGenParticlePDG class early on?
it seems that the library is correctly loaded but in the context of interactive usage, PyROOT or prompt/macro, the interprerter info is not reachable.
This behaviour can be linked to a few set of causes. Are you sure that the headers where your classes are defined are available? Are all include guards and other preprocessor variables coherent, i.e. can you exclude that by accident parts of your headers are not properly parsed?
The includes are very simple so I’m quite sure the include guards are in place. I tried
pragma once
traditional ifndef guard
change order in linkdef
I now extracted the two classes from our stack and wrote a little Makefile which reproduces the problem for me. I’m fully aware that were probably doing something stupid here: particledb.tar.gz (14.9 KB)
I think the issue is linked to the initialisation of the static variables.
Upon starting the executable, the library libstuff is loaded. In order to initialise a constant in this lib, the pi0mass, a static function is invoked. This requires some information to be known by the interpreter, namely the content of the header “EvtGenParticlePDG.h”. ROOT can find automatically in normal conditions this file and parse it behind the scenes but this does not work in your case.
The problem is that the location of the header is known to ROOT thanks to a static function part of the dictionary which is invoked at library load. As you know though, statics are executed in random order and we we have a problem of ordering.
Let’s now come to the problem you are trying to solve: what to do.
The proper fix will be in ROOT 6.16 and it requires some thinking. To unblock you, it’s necessary to let the interpreter know something about the EvtGenParticlePDG.h file before the method EvtGenDatabasePDG::ReadEvtGenTable is invoked. To be more concrete, something like this statement gInterpreter->Declare("#include \"EvtGenParticlePDG.h\""); shall be executed before EvtGenDatabasePDG::ReadEvtGenTable. I tested that once running this in the EvtGenDatabasePDG::Instance() function itself your example works.
Thank you for the quick work around. I was aware that it’s probably a ordering problem of the initialization functions but no idea which part and where to look.
And yes, manually loading the header is perfectly fine. Hopefully that was the last small hitch before we can finally switch to 6.14