Build a Shared Library with selected objects?

Good afternoon,
I am writing a series of application in C++ and I am using some of the objects built by ROOT, such as TFile, TTree, TH*F [and basically nothing more].
Instead of depending on a complete ROOT install on every machine I test my code on, I’d love to put together a shared library (libSONAME.so.x.y.z) that include everything and nothing else than I use in my code.

I’ve installed ROOT from source, and I noticed that, after compiling the code, the .o objects of the single classes survived…So I was wandering if I could just use the .o of the classes I need [I mean, are they compiled using “-fPIC” options?] or if a complete recompiling of the required classes [and dependencies] is needed…and, if so, whether or not can I find a complete dependency list of the Classes TFile, TTree, TH1/2/3F to compile the libraries from “scratch”.

Thanks!

m.

[quote]So I was wandering if I could just use the .o of the classes I need[/quote]Not quite. All ROOT classes requires a dictionary, we currently build only one dictionary file per library (which of course requires every single .o file in the library). So you would also need to generate the dictionary for the subset of classes you need.

[quote]Instead of depending on a complete ROOT install on every machine I test my code on, I’d love to put together a shared library (libSONAME.so.x.y.z) that include everything and nothing else than I use in my code.[/quote]Unless you have extreme memory constraint (as in only a few MB of rams on the target machine),
I strongly recommend against you plan.

In addition, please note that in addition to the library you need a lot of helpers files ($ROOTSYS/etc $ROOTSYS/cint $ROOTSYS/icons) and we do not per se support partial installation.

If you still need to proceed in that direction, I recommend that you either just includes the few ROOT libraries you need or generate the root static library (gmake static) and link you executable against this static library and explicitly request the linking of the dictionary (see the way we build roota).

Cheers,
Philippe.

Good Morning, and thanks Phillippe for your reply.

I see your point, even if I’m not very familiar with dictionaries.

It would be interesting, even if I have no idea about how to proceed

[quote]Unless you have extreme memory constraint (as in only a few MB of rams on the target machine),
I strongly recommend against you plan. [/quote]

It’s not a matter of memory, but of “portability”. I’d like to use the powerful ROOT libraries without actually having to perform a complete ROOT install on the destination machine. Since I must run more or less at the same time about 5 applications that would require the use of TTree, THxF and TFile and nothing more, I thought a shared libraries would have been easier to manage…moreover, if a ROOT lib looses backcompatibility for some reason, I would require to rewrite the application or to ship the application with a specific root version supporting my code…

I see. It’s more complicated than I thought, I am wandering if a direct build of the .cxx .h files would fit…but I think not!

I don’t get this point. I thought you told me that this direct inclusion just would not work…?

the static build is an option that solve a great part of my problem. As a matter of preferences, I find more elegant to use shared libraries [I do not actually like the idea to waste memory, even though I’m not short of] but if that part is too much of a trouble and the static linkage just work…

m.

Cheers,
Philippe.[/quote]

I’m trying to do something similar.

I just want to have a very simple standalone C++ program that only uses a tiny subset of root.

I’ve got the following program…

#include <string>
#include "TFile.h"
using namespace std;
int main(int argc, char **argv) {
	// get file arg
	string filename=argv[1];
	TFile root_file(filename.c_str());
	return 0;
}

and am starting to copy the .h and .cxx files needed to get it to compile into the same directory as that program.

When I compile I run up against errors like this…

In file included from TDirectoryFile.h:25,
                 from TFile.h:25,
                 from root_file.cxx:3:
TDirectory.h:25: fatal error: TNamed.h: No such file or directory
compilation terminated.

and am then finding that header file and copying it’s corresponding .cxx file into my standalone directory, doing my ‘make’ again and copying in the next .h & .cxx files that it needs to proceed further.
After 3 cycles I’m realising that there’s going to be a LOT of this so I’m about to write a python script to automate the whole process.

i.e
a) run make
b) get the name of the header file it fails to find and barfs on
c) find that header and it’s corresponding .cxx in the root source and copy to the working directory
d) go to a)

Once that’s done I’ll hopefully have just the subset of root headers and .cxx files needed to compile the above ‘do nothing’ program.

I’d be interested if you could send me the program you’re trying to write that just uses TFile, TTree andTH*F so that I can then run my python script against it to pull in just the subset of root source files needed to compile it.

Regards,
Emyr

[quote]It’s not a matter of memory, but of “portability”. I’d like to use the powerful ROOT libraries without actually having to perform a complete ROOT install on the destination machine.[/quote]Why not?

[quote]So you would also need to generate the dictionary for the subset of classes you need.
it would be interesting, even if I have no idea about how to proceed[/quote]Unless you really have strong constraint of memory or disk space that warrant spending the serious effort to create those (and later maintain them to keep with our updates), I strongly suggest not to pursue this idea.

[quote]if a ROOT lib looses backcompatibility for some reason, I would require to rewrite the application or to ship the application with a specific root version supporting my code…[/quote]If you concern is indeed to make sure you have a consistent set of libraries, you could simply include a full build of ROOT with your application (possibly with has many optional features disables as possible and even some unused (in your case) libraries removed).

Cheers,
Philippe.

[quote]and am then finding that header file and copying it’s corresponding .cxx file into my standalone directory, doing my ‘make’ again and copying in the next .h & .cxx files that it needs to proceed further.[/quote]Humm … you will also need to create the correct dictionary for each and every of those classes and make sure that all the auxiliary helper files are also included.

Cheers,
Philippe.

Thanks for the information Philippe.
Are you able to give an example of what you mean by a dictionary and an auxilliary helper file ?

Hi,

‘auxiliary’ files, all the files in $ROOTSYS/cint (when installed) and $ROOTSYS/etc and some in $ROOTSYS/bin.

[quote]what you mean by a dictionary [/quote]For more details, re-read the User’s Guide especially the chapter on adding you own class. A random ROOT dictionary tree/tree/src/G__Tree.cxx (and G__Tree.h) generated using tree/tree/inc/LinkDef.h.

Cheers,
Philippe.

I try one last time with a simple question: would a static library require much less effort in creating a single repository or would it need the same ‘hard and discouraged’ work?
Your point on the static library seems more bright now that you closed my eyes on the secred dream of taming the .so! :wink:

[quote]I try one last time with a simple question: would a static library require much less effort in creating a single repository or would it need the same ‘hard and discouraged’ work?[/quote]Yes, it would require less effort (you would just need to link your executable against the dictionary .o files as seen when linking roota and copy all the files in $ROOTSYS/etc and $ROOTSYS/cint/cint/[include|lib|stl], $ROOTSYS/icons and $ROOTSYS/fonts).

Cheers,
Philippe.