PROOF does not load objects in compiled .par packages


I am using root, version 5.28/00, and proof.
Please forgive me, this is quite a long post…
I wrote a simple class, which inherits from TSelector, and provided it with the requested interface methods.
Class declaration and definition also expose the ClassDef and ClassImp macros.
I can compile it using g++ in order to obtain a dictionary (with LinkDef.h) and my shared library, and everything is ok: I can use it in a stand-alone program (no-proof).

[size=150]1. [/size]
if the main program calls directly the source-selector:

TChain *ch = ...;
TProof * p = TProof::Open("blabla");
int answ = ch->Process("");

the analisys starts and the variable answ is not -1; the same if the code is compiled with a “+”-flag.

Problems start when I create a proof archive: if I try the same but uploading the package

TChain *ch = ...;
TProof * p = TProof::Open("blabla");
p->UploadPackage("libmy_beautiful_sel.par", TProof::kRemoveOld);
int load = p->EnablePackage("libmy_beautiful_sel")
int answ = ch->Process("my_beautiful_sel");

the code is compiled, load is 0, but answ=-1, and an error is thrown:
[color=#800000]Error in TSelector::GetSelector: class my_beautiful_sel could not be loaded[/color]
Looking at the GetSelector method, one finds out that most probably something got wrong at these lines:

TSelector.cxx:166  Bool_t autoloaderr = kFALSE;
TSelector.cxx:167   if (!fromFile && gCint->AutoLoad(localname) != 1)
TSelector.cxx:168     autoloaderr = kTRUE;

and I do not understand why. This does not depend on setting the LD_LIBRARY_PATH correctly, as far as I can see.

A very strange behaviour is the following: the code in my PROOF-INF/ is

Int_t SETUP() {
  return 1;

and if I pass it to the Cint:
[color=#800080]$> root -l PROOF-INF/[/color]
everything is ok, the library correctly loaded, and users can create/play with the new class.

Does anyone has ever experienced such a behaviour?
Thank you very much in advance.

ciao ciao,


Before start guessing, is the extension of your file containing SETUP really ‘.sh’? If so, this file is never loaded by the PAR file manager. The extension must be ‘.C’ .

G. Ganis


I must admit I never thought to it! Now it works correctly, thank you very much!
Wouldn’t it be simpler if both BUILD and SETUP files had a sort of tag line inside instead of matching their functionalities by their extension? I mean something like:

Int_t Setup (...){...}

and for BUILD.something the very first line ([color=#800080]#!/bin/bash[/color]) maybe will suffice…
By the way, is ti possible to call other functions inside the Setup one?

Thank you again!



This will mean checking all the files in the directory, which adds complexity and fragility.
I do not think that having well defined names is, in this case, a limiting factor. If at a certain point this becomes critical then we may reconsider it.

SETUP.C is a ROOT macro and, as such, it can call any function which is known to it. What other function would you like to call at that level?

G. Ganis


OK, just a proposal, not necessary a good idea!

More a curiosity, to tell the truth: I was thinking about some configuration scripts which are analysis-dependent, but one can easly provide the same services by passing options to the Setup.C function.

Thank you again!

Bye bye,