Hi,
I have an stand-alone application that just collects data and writes to root files. I need this application statically linked to root libraries, because I don’t have the luxury of bringing root shared libraries on this external machine.
I generally build root from source and would very much need that option in the cmake in root, which seems to be the only build tool in root (they got rid of configure).
Hi, I am looking into this, but I think that it will not be an easy change. I could build most of ROOT statically, but when linking root.exe there are still problems. I will update the JIRA ticket with more information soon.
Do we really need root.exe statically linked? If I’m not mistaken, most are asking for this feature to have the option to have static root libs available (in addition to shared libs) built, so that with their stand-alone applications could statically link to root libs. Am I wrong about that?
I don’t know if the complications of statically linking root.exe necessarily impacts the ability for other applications to statically link to static root libs. But if that’s the case (that root.exe is a special case), then I think the ideal situation would be to setup cmake to always build shared libs and to make static libs an additional option to the build (have both shared and static libs), where root.exe will always be using the shared libs.
The difficulty of statically building an executable is if the library source code dependencies are not hierarchical, then one would have to list the libs recursively until all symbols are resolved. Hopefully that is not the case.
I think some users also want to be able to compile ROOT somewhere and then move it to another machine.
Yes, there is a complication: rootcling needs to dlopen libCling.so to work, and that is where I’m stuck currently in supporting static builds. But root.exe links statically and works, despite having some runtime issues I’m also trying to tackle. CMake has the special variable BUILD_SHARED_LIBS that lets the user control the default behavior of add_library(), but unfortunately there is no way to use that to build both types of libraries, one has to choose between building all static libraries or all shared.
Unfortunately, this is the case. We do have some problems with this in the build system, but fortunately this is not difficult to fix, since CMake lets you use INTERFACE when linking to propagate things to dependent targets.
At the moment, I can build almost everything statically, except for the dictionaries since they depend on rootcling and it’s not working. I think I will need some help to understand how to get around the dlopen issue, but hopefully in a week or so we will have the ability to build ROOT statically with CMake as well.
What’s the kind of objects you are trying to write out?
I am working on providing write support for this Go-HEP library of mine (should land by the end of the summer). Go has top-notch support for static compilation
I could prioritize for the objects you want to write out…
Hi sbinet,
My objects are various classes and the contents of the classes are a mixtures of doubles, and integers. But I want to keep them in classes for ease in management, so I do generate dictionaries for these classes and don’t mind keeping the corresponding dictionary as shared objects, since analysis can be done on my own laptop.
But the standalone executable that collects data in the form of these objects, that needs to to be statically build since it runs on an external machine that I don’t have the luxury of porting root’s shared objects (it’s complicated). Once it finishes collected the data, I then just export the root file to my own laptop where I run the analysis.
I think this standalone executable is only dependent on root’s libCore library. So at the minimum, I’d need to have a static version of libCore.
CMake has the special variable BUILD_SHARED_LIBS that lets the user control the default behavior of add_library(), but unfortunately there is no way to use that to build both types of libraries, one has to choose between building all static libraries or all shared.
According to here, you can have both static and shared libs in cmake. Rather than relying on that special variable, by default have it build shared libs, but then provide a cmake option to also provide static libs in addition to the shared libs.
Looking at that link, it’s just recommending to add each library twice, one shared and one static, and that’s not really something we would like to do. In general we don’t want static libraries, and that would require conditionally adding the static library in addition to the shared library for each target. Moreover, even if ROOT is compiled statically, it still needs other things like headers, etc, at runtime that make it hard to just compile it on one machine and move it somewhere else. And that is not possible now in any case, because of rootcling, which doesn’t work when compiled statically. I’m afraid it will take some time before we can resolve this issue.
if time is of the essence, I guess you could fallback on using a dedicated serialization library (that is easier to compile statically and more modular than statically compiling the whole ROOT project).
from python (and Go), ingesting any of these formats is rather straightforward.
I suppose converting any of these formats to ROOT, in C++, is doable as well.
worse comes to worse, you could roll your own TLV-like binary format.
(or use sio from SLAC.)
ah! there’s also the library used by Geant4 that implements some limited ROOT I/O features, in pure C++, w/o any ROOT headers.
see:
