Detailed description of rootcling command options?

Cling
1

Hi,
So far I’ve been unable to find any detailed documentation concerning the command line options when using rootcling to create dictionaries . Can someone point me to a link or a document somewhere ? rootcling -h doesn’t tell me a lot about when and how to use -m , -rml and -rmf and what exactly they do. I am porting code from ROOT5 to ROOT6 .

peter

2

@pcanal might have more informations, but here is a short documentation

3

I looked at that but it does not go into any details about the options. I thought the -m option specified the destination for the .pcm file but it appears no to. I would have thought I should set it to my lib directory for the project - right ? .pcm files live in ROTSYS/lib . But for 6.20.00 which is what I’m using rootcling appears to override this. Hmm …

peter

4

After a bit of testing it looks to me like rootcling dumps the .pcm file in the directory specified by the -f option and if I use the library in any executable I get an error unless the .pcm file is in the same directory as the executable . No other directory is looked at according to strace. One post on the forum suggested ROOT_INCLUDE_PATH but that seems to have no effect. Wouldn’t the natural place be with the library ???

peter

5

Note that rootcling --help gives more information (and in v6.20 it is also printed for -h). In particular:

      -m=<string>           - The list of dependent modules of the dictionary.
      -rmf=<string>         - Generate a rootmap file with the specified name.
      -rml=<string>         - Generate rootmap file.

I thought the -m option specified the destination for the .pcm file but it appears no to.

It does not. It specifies the module, the one rootcling will build can use.

After a bit of testing it looks to me like rootcling dumps the .pcm file in the directory specified by the -f option

Yes this is the intent, you need to then copy it to your lib directory.

6

This is to indicates where to find header files for when rootcling does not generate a clang module (i.e. without the -cxxmodule option)

7

thanks for the clarification(s)

8

-rml and -rmf create the so-called rootmap file which is intended to be an performance optimization for ROOT. The *rdict.pcm also another optimization data structure which tells rootcling to precompute some of the i/o information at compile time. -m tells rootcling which are the dependent rdict.pcms (so that they do not duplicate information). When used with -cxxmodule flag -m tells rootcling which module to preload and make the currently built module dependent on.

There is some partial description about them here: https://github.com/root-project/root/blob/master/README/README.CXXMODULES.md

9

The rdict.pcm file needs to be in the same folder as the library to avoid very subtle bugs when things are out of date. It is essentially part of the library which gets read at dlopen. I would recommend that the pcm file and the rootmap file to stay next to the shared object as they are essentially its descriptor.

10

Hmm … My My application puts its library in a lib directory and the executable(s) in a bin directory. If I place the .pcm file in the lib directory ( with LD_LIBRARY_PATH pointing to it ) or get rid of it altogether I get an error when I run the code saying it cannot find my .pcm file in the bin directory plus a large number of warnings(?) about other ROOT6 things like :
Info in TCling::LoadPCM: In-memory ROOT PCM candidate /usr/local/root_v6.20_00/lib/libASImage_rdict.pcm
Placing my .pcm file in bin gets rid of all errors and Info .
I’m confused …

peter

11

Is your executable a fat binary, meaning that it does not refer to shared objects? One way to check that is to run ldd path/to/binary if it references nothing from your lib folder then it would explain the error. In that case you should probably move your rdict.pcm files next to the binary.

12

Vassil,

Yes, that’s it. For legacy reasons a lot of the code in this this project is linked statically. Not really sure why.

thanks,
peter

13

Good. Usually if you link things altogether there is a speed up on average by 10% because the linker has access to more information and may enable some additional optimizations.

14

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.