Clarification needed on pcm dictionary files

ROOT
1

ROOT Version: 6.32.02
Platform: docker image (based on rocky linux 9)
Compiler: gcc

Using a program compiled against Root libraries, which reads some Root-formatted files, I end up with this kind of error :

In file included from G__KM3NeTROOT dictionary payload:290:
/Jpp/externals/km3net-dataformat/online/JDAQDataTypes.hh:4:10: fatal error: 'km3net-dataformat/definitions/daqdatatypes.hh' file not found
#include "km3net-dataformat/definitions/daqdatatypes.hh"
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Error in <TInterpreter::AutoParse>: Error parsing payload code for class Vec with content:

that I can make disappear by changing the ROOT_INCLUDE_PATH variable.

Do I understand correctly that, if my dictionary was correctly generated in the first place (i.e. complete?) , the includes would not even have to be “reparsed” (and so their location would be irrelevant) ? If that’s the case how do I find out which object in the Root is triggering the parsing of the includes ?

Just by the reading of the question you may infer that my understanding of the dictionary business is shaky as best, so please bare with me :wink:

2

Do I understand correctly that, if my dictionary was correctly generated in the first place (i.e. complete?) , the includes would not even have to be “reparsed” (and so their location would be irrelevant) ?

This is true only if the types in the dictionary are only used for I/O. If they are used for interpretation then you need the dictionary (because the dictionary does not register anything about methods, for example).

It is likely you have a missing request for dictionary in your LinkDef/Selection.xml

If that’s the case how do I find out which object in the Root is triggering the parsing of the includes ?

It looks like it is the Vec class and/or a typedef related to that spelling.

Error in <TInterpreter::AutoParse>: Error parsing payload code for class Vec with content:

Cheers,
Philippe.

In the longer term, the need for header file will be replaced by the generation of a Clang C++ module. You can test this via the MODULE option of ROOT_GENERATE_DICTIONARY in CMake or directly the -cxxmodule option of rootcling

3

Thanks Philippe for your answer,

If they are used for interpretation

by interpretation do you mean for instance simply using a method of one of the object read from file or something different ?

For the cxxmodule I assume that is only applicable if using a C++ compiler >= 20, right ?

4

Yes, using a method (or even just the pointer to the object) through the interpreter (it would of course not be an issue to use it from compiled code).

For the cxxmodule I assume that is only applicable if using a C++ compiler >= 20, right ?

No, it is independent from the compiler and C++ version you are using. For the purpose of the dictionary, the C++ module are produced by the Clang version internal to ROOT (i.e. the one used for Cling and Rootcling).

5

I’m still confused for the interpreted part : the error I can comes out from compiled code as far as I can tell.

For the cxxmode of rootcling, thanks for the tip, I’ll test that out for sure

6

laurent.aphecetche
I’m still confused for the interpreted part : the error I can comes out from compiled code as far as I can tell.

Yes but there is many ways the compiled code can call the interpreter (TMethodCall, TTree:Draw, etc.). Note that you can determine exactly what triggers the issue by running the failing case in gdb and putting a break point on TObject::Error.

But most likely the issue is a missing dictionary request (related to Vec)