PROOF does not load objects in compiled .par packages

ROOT
#1

Hello,

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");
ch->SetProof();
int answ = ch->Process("my_beautiful_sel.cc");
p->Close();

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

[size=150]2.[/size]
Problems start when I create a proof archive: if I try the same but uploading the package

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

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.

[size=150]3.[/size]
A very strange behaviour is the following: the code in my PROOF-INF/SETUP.sh is

Int_t SETUP() {
  gSystem->Load("libPhysics");
  gSystem->Load("libmy_beautiful_sel.so");
  return 1;
}

and if I pass it to the Cint:
[color=#800080]$> root -l PROOF-INF/SETUP.sh[/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,
Federico

#2

Hi,

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

#3

Hello,

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:
SETUP.xyz

// THIS_IS_PROOF_SETUP
//
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!

bye,
federico

#4

Hi,

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

#5

Hi,

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,
federico