ACLiC problems with CINT dll

From: Jacek M. Holeczek <holeczek_at_us.edu.pl>
Date: Fri, 15 Apr 2005 22:20:54 +0200 (MET DST)

Hi,
following my recent experience, I would like to report one problem here, which may be encountered by other people, too.

When creating shared libraries, ACLiC uses the so called "LinkedLibs" variable (among others). The problem is that this way it also includes all CINT dll shared libraries ("precompiled headers"), in case they have already been "loaded" in the ROOT session.

In order to see/understand the problem, create a small "blah.cxx":

        void blah(void) {;}

Then try to precompile it:

	root [0] .L blah.cxx++
	Info in <TUnixSystem::ACLiC>: creating shared library /..././blah_cxx.so
	root [1]

... which, of course, works.

Now, try the same example, but AFTER a CINT dll has been loaded:

	root [0] #include <stdlib>
	root [1] .L blah.cxx++
	Info in <TUnixSystem::ACLiC>: creating shared library /..././blah_cxx.so
	g++: stdfunc.dll: No such file or directory
	Error in <ACLiC>: Compilation failed!
	root [2]

As can be seen, the "#include <stdlib>" triggers loading of the CINT
"stdfunc.dll", which afterwards is added by ACLiC to the list of
"required" libraries (when creating the "blah_cxx.so").

Note that, in the "test case" above i used the "stdlib" but, one should expect such problems for every "precompiled CINT header" (i.e. for all
"cintdlls") as soon as one explicitly or implicitly "#includes" it.

According to Philippe, the solution is to try:

	TString s = gSystem->GetMakeSharedLib();
	gSystem->SetMakeSharedLib(s.ReplaceAll("$LinkedLibs",""));

The "permanent" ROOT fix, however, will first be available (hopefully) in summer, when the need for linking to existing libraries will be removed.

Hope it helps,
Best regards,
Jacek. Received on Fri Apr 15 2005 - 22:21:07 MEST