Adapting Unnamed Macro for Valgrind

Hi, this is a long post, but here is what I am trying to do: I want to convert a non-compiled macro into a thing that I can compile without ACLiC (i.e. using clang++) so that I can use valgrind. Details follow.

I have an unnamed script that runs. A recent modification made it crash with an unhelpful error message, and it was recommended that I use valgrind to diagnose. Unfortunately the unnamed script is run by root and compiles stuff on the fly with ACLiC. It uses an analysis class “MydaqT” which inherits from “daqT” produced by TTree::MakeClass. Here is the original macro which I run with “root -l do_ana.C”:

{
  // Load macros used

   gROOT->ProcessLine(".L Utility.C+");
   gROOT->ProcessLine(".L JFTrackFit.C+");
   gROOT->ProcessLine(".L daqT.C+");
   gROOT->ProcessLine(".L MydaqT.C+");
   gROOT->ProcessLine(".L t2x.C+");

  // Opening a single TFile:
  TFile f("infiles/run00119_h.root"); // phi = -22, dip 10
  TTree * ft = (TTree*)f.Get("daqT");
  
  // Instantiate the analysis class with the pointer ft.
  MydaqT t(ft);

  // Do some stuff.
  t.hTOF_Fit("outfiles");
  t.hTOF_2D("outfiles");
  t.draw_signals(50);

  // Later we can do things like
  t.Loop();
}

On the way to making a standalone executable, I would like to make my macro compileable with ACLiC, so that I can run it with “root -l do_ana.C+”. I have tried removing the ProcessLines commands and instead adding the following lines to the top of the macro:

#include "TFile.h"
#include "TTree.h"

#if defined(__CINT__) && !defined(__MAKECINT__)
#include "Utility.C+"
#include "JFTrackFit.C+"
#include "daqT.C+"
#include "MydaqT.C+"
#include "t2x.C+"
#else
#include "Utility.C"
#include "JFTrackFit.C"
#include "daqT.C"
#include "MydaqT.C"
#include "t2x.C"
#endif

void do_ana()

This allows the code to be run as before in non-compiled mode using “root -l do_ana.C”. If I try to run it in compiled mode (root -l do_ana.C+) I get many errors about redefinitions of member functions of the daqT class. The errors are in the attached error1.txt file.

In order to use valgrind, I understand that I’ll need to compile it without ACLiC’s help. So I also add a basic main function to the code:

int main(int argc, char * argv[]) { do_ana(); }
Unfortunately now compiling with: clang++-mp-3.2 -std=c++11 -Wno-c++11-extensions -o ana do_ana.C -I`root-config --incdir` `root-config --glibs` gives even more errors, though most are the same about redefining methods on daqT. One of the confusing errors is the following:

In file included from do_ana.C:12: ./JFTrackFit.C:294:23: error: no matching constructor for initialization of 'ROOT::Math::Functor' ROOT::Math::Functor ftor(&jftf,2,"JFTrackFit"); ^ ~~~~~~~~~~~~~~~~~~~~ /opt/local/include/root/Math/Functor.h:358:4: note: candidate constructor [with PtrObj = JFTrackFit *, MemFn = int] not viable: no known conversion from 'const char [11]' to 'unsigned int' for 3rd argument Functor(const PtrObj& p, MemFn memFn, unsigned int dim ) ^ /opt/local/include/root/Math/Functor.h:369:4: note: candidate constructor template not viable: requires 2 arguments, but 3 were provided Functor( const Func & f, unsigned int dim ) : ^ /opt/local/include/root/Math/Functor.h:351:4: note: candidate constructor not viable: requires 0 arguments, but 3 were provided Functor () : fImpl(0) {} ^ /opt/local/include/root/Math/Functor.h:389:4: note: candidate constructor not viable: requires single argument 'rhs', but 3 arguments were provided Functor(const Functor & rhs) : ^
Recall that this code works with ACLiC compiling the required .h and .C files when the macro is interpreted. The only difference here is that I am trying to compile the macro. The other code was compiled all along. It seems that the ROOT::Math::Functor header is not defining the right constructors, but it was working with the interpreted do_ana.C, so I am very confused.

Note: if I comment out the #include “daqT.h” line from the named macro file, the errors about redefining daqT go away. The one about the ROOT::Math::Functor constructors when using clang++ explicitly remains. In the case of using “root -l do_ana.C+”, a new error shows up about daqT: “ld: symbol(s) not found for architecture x86_64”.

My full code can be found at http://bazaar.launchpad.net/~jfcaron/+junk/Proto2BeamTest2/files if anyone wishes to take a look. I would appreciate any assistance.
error1.txt (11.4 KB)

I have finally solved this problem (after nearly a week of problems…)

My eventual solution kept the #preprocessor macros as before (with a separate #include “foo.C+” for CINT and #include “foo.C” for non-CINT). The “no matching constructor” error was resolved here: [url]Functor Issues when Compiling

The basic problem I was having was that ACLiC was hiding a whole bunch of stuff from me. The compiled components of my program (the _C.so files) are not easily loadable by hand for clang++, because it expects things named “libfoo.so” and such. I eventually learned to compile my own .o files from the .C files using clang++, then creating libfoo.so files from the .o files (including how to -L and -l to resolve dependencies), then finally compiling the macro that had my main() function. I eventually wrote a makefile to keep it better organized. My full explanation is here: http://www.phas.ubc.ca/~jfcaron/ROOTTricks.html#[[Compiling%20a%20ROOT%20macro%20with%20clang%2B%2B%2Fg%2B%2B%20%28with%20libraries%29]]

Jean-François

While it was compiling and running using clang and interpreted with CINT, the ACLiC-compiled version was not working.

The fix was to add some gSystem->Load commands before trying to .x do_ana.C+, as suggested in this post: Probleme with GSLIntegrator

So I had to do:

gSystem->Load("libMathMore")
gSystem->Load("daqT_C.so") // Created by ACLiC
gSystem->Load("MydaqT_c.so") // Also
.x do_ana.C+

Is there a way to put these load commands as a preprocessor directive in the do_ana.C file?

Jean-François