Distributing ROOT binaries with my program

Good catch, the referenced link literally points to a README saying:

libCore does a dlopen of libCling

…so that resolves that mystery.

And I would suppose that libCore cannot possibly run without libCling, right? I found this relevant thread on that topic, which seems to suggest so. This is a shame, given that I really only need to be able to load/write TTrees from/to ROOT files in my C++ program. I was hoping there would be a lightweight approach that I could adopt. Anyway, I will assume for now that libCling is required for my program even though I don’t really need to use it. With that in mind, I still do not understand why does cling look for headers? And why does it not honor ROOTSYS?

What follows is just a quick recap of what my program does. The main executable does not link against ROOT. Instead it just modifies the environment for ROOT, and passes control to another function in another library, which is linked against ROOT. Modelling the behavior of thisroot.sh, my main() function currently sets the ROOTSYS env. variable to the path where ROOT is distributed (contains lib, etc, icons and fonts; on Windows it contains bin instead of lib). And then on POSIX systems it appends $ROOTSYS/lib to the following env. variables:

  • LD_LIBRARY_PATH
  • DYLD_LIBRARY_PATH
  • SHLIB_LIBRARY_PATH
  • LIBPATH

Conversely, on Windows systems it adds $ROOTSYS/bin to PATH (with semicolon as delimiter) and sets CLING_STANDARD_PCH=none.

After the environment is appropriately modified, ROOT should have no difficulties running. So my main() simply loads the rest of my software from a dynamic library that directly depends on ROOT, which lets the dynamic linker resolve the rest of dependencies. All loaded modules inherit this augmented environment – with strace I can verify that this is the case.

I am failing to understand:

  • Why does cling look for headers when there are pre-compiled headers, dictionaries and module maps in $ROOTSYS/etc?
  • Why does cling look for headers in /boot/root/src/build/include? Is that some kind of fallback path from CI? Or is there an empty env. variable, which I was supposed to configure?

My digging led me to this function in ROOT source. Is this what is responsible for all those headers being probed on load?