How to dump modulemap ".pcm" files

Cling
1

In ROOT 6.18 and earlier, for each “${ROOTSYS}/lib/lib*.so” library, there existed a corresponding “${ROOTSYS}/lib/lib*.rootmap” text file.
This allowed e.g. to easily find which library was needed for a class (when linking errors appeared).

In ROOT 6.19 and newer, there exist only “${ROOTSYS}/lib/*.pcm” binary files.
What is the command which dumps the contents of these files in a human readable (ASCII) form?
I guess I would like to get (ASCII) text output which kind of “resembles” what was contained in the old “.rootmap” files.

2

That’s something that @Axel should know.

3

One way is to use rootcling bare-cling -module-file-info some.pcm That will give you information which headers are contained in that module.

When there are linking errors I use nm -AC lib/*so | grep mangled_name to find which is the library containing the definition of the searched symbol.

4

Well, I wanted to escape from scanning all shared libraries with nm.

How do I get all available options for " bare-cling"?

5

Unfortunately, that is the only supported option for the moment. Alternatively, you could do strings some.pcm | grep identifier. What was your exact workflow with the rootmap files?

6

I need a way that unmistakenly works for the three “real life examples” shown below (i.e. it uniquely and easily identifies the missing library), but with “ .pcm ” files, and it should work for a “casual” / “novice” user who is not familiar with parsing “nm” nor “strings” output (which return multiple “possible” entries in multiple files):

7

Would that help:

root [7] gInterpreter->GetClassSharedLibs("TMatrixTBase<float>")
(const char *) "libMatrix.so"
root [8] gInterpreter->GetClassSharedLibs("TRotation")
(const char *) "libPhysics.so"
root [9]
8

Thanks. This trick works well.

I guess everybody who’s linking against ROOT libraries is also able to run “root”.

BTW. Could you, please, make sure that “rootcling bare-cling -help[-list][-hidden]” returns all available options.

9

I think in the gSystem->Load case we can print a more useful diagnostic.

For the rest we could use the interface which is supposed to resolve library dependencies:

root [11] gInterpreter->GetSharedLibDeps("libGui", /*useDyld*/true)
(const char *) "libGui libGpad.so libGraf.so "
10

We can’t – it is an argument sink. It gets all arguments and then pipes it to the underlying cling and clang infrastructure…

11

So, how is a gcc user expected to learn about them?

Actually, rootcling bare-cling -help returns various “-help-*” and “-print-*” options but they do not return anything useful.

12

They are not expected to work and be learnt. Those are expert-level features which are untested, undocumented and most of the time do not do what they are expected to do.

For example, if you pass rootcling bare-cling -Xclang -ast-dump it won’t do what clang would do because cling does not go entirely via the clang driver and requires scaffolding on the cling side (which is an inheritant design problem which I think I should be able to solve in midterm).

Some of the clang flags have no meaning for interactive use or our infrastructure (think cross compilation).

Please don’t use any of those in production of elsewhere as they will break and change :slight_smile:

13

O.K. But a small web page for “experts” (with options that actually do work or are expected to work) would be nice to have.

14

The -module-file-info was the only option that actually works. It is only used by me to detect suboptimal header duplication across modules. So I misspoke about experts – I meant implementers but I agree we should have an expert cheatsheet page.

15

Maybe one more thing … can you add another parameter to the TInterpreter::GetSharedLibDeps method … e.g. “bool recursive = false” … which (when “true”) could recursively go through and then list all dependent libraries.
For example, for “libGui”, it now returns “libGui libGpad.so libGraf.so” (note that “libGui” is returned without “.so”), so it then should find dependencies for “libGpad” and “libGraf” and then for their dependencies, and so on … in the end, one could run “uniq” on this full list.

16

I’ve got some related questions.

Well, rootcling bare-cling -module-file-info Core.pcm doesn’t list “gROOT” nor “gStyle”, even though strings Core.pcm shows them.
So, can I easily get the information which library is needed for some global?
Note: in general it is not necessarily the same library which provides the corresponding class.

Assume I want to find which #include is needed for some class (e.g “TMatrixTBase<float>” or “TRotation”) or global (e.g. “gROOT” or “gStyle”).
Is it possible to easily get this information?

17

@vvassilev can you help?

18

Could you open a JIRA ticket for that so that we do not forget.

That is the odd format – libGui (without the so) is the calling library – eg that one which triggered the dependency resolution.

19

Unfortunately, not, easy. In principle we can collect the actual owning module here: https://github.com/root-project/root/blob/master/core/metacling/src/TCling.cxx#L6844 and also use that implementation to show which header file(s) contain the definition of entity. I guess that’d be another feature request…

20

Thanks.

What about getting the information which library is needed for some global (e.g. “gROOT” or “gStyle”), which is not necessarily the same library that provides the corresponding class?