Include path when compiling, Mac Vs Linux

ROOT
1

Dear experts,

I will describe a problem that doesn’t appear when I work on a mac, but it appears in scientific linux.

I have a macro, called optimizeCuts.C, which needs to include an analysis class, which is compiled into d3pdGammaJetAnalysis_C.so.

The class d3pdGammaJetAnalysis needs a helper function that is in a subdirectory:
photonIDtool/PhotonIDTool.h
photonIDtool/PhotonIDTool.cxx

This helper function needs yet another helper function, which is in the same subdirectory:

photonIDtool/PtEtaCollection.h
photonIDtool/PtEtaCollection.icc

To compile on my mac, I use the following script:

compile.C 
{
  gSystem->AddIncludePath("-I\.\/photonIDtool\/");
  gSystem->CompileMacro("photonIDtool\/PtEtaCollection.h","kO") ;
  gSystem->CompileMacro("photonIDtool\/PhotonIDTool.cxx","kO") ;
  gSystem->CompileMacro("d3pdGammaJetAnalysis.C","kO") ;
}

I execute the above with root -l -q -b compile.C and I obtain the file d3pdGammaJetBalance_C.so. I gSystem->Load that file in my macro, optimizeCuts.C, and the macro runs.

So, it’s all fine, when I do this on my mac.

When I do exactly the same things on linux, it compiles, but when I try to run optimizeCuts.C it complains that it can’t find PtEtaCollection_h.so.

A patch to make it work in linux is to gSystem->Load() the helper functions explicitly, before I load the d3pdGammaJetAnalysis_C.so. That way it works.

I dug into what goes wrong in Linux, and I ran ldd on the d3pdGammaJetAnalysis_C.so file, to see this:

To compare, I do the same on my mac, where things work. (Mac OS replaces “ldd” with “otool -L”)

Obviously, the .so file I make on the mac has the other libraries correctly linked, which is not the case in linux.

The question is “why?”

Here is some potentially helpful info:

Mac ROOT version: 5.26/00 14 December 2009
Linux ROOT version: Version 5.26/00b 9 February 2010

Mac gcc version:

Linux gcc version:

Thank you in advance,
Georgios

  1. cg ↩︎

2

Hi,

Try putting the directory that contains PtEtaCollection_h.so to the LD_LIBRARY_PATH (and/or simply the ‘dot’ directory).

Cheers,
Philippe.

3

[quote=“pcanal”]Hi,

Try putting the directory that contains PtEtaCollection_h.so to the LD_LIBRARY_PATH (and/or simply the ‘dot’ directory).

Cheers,
Philippe.[/quote]

Thank you for the suggestion Philippe.

It surprises me a little that I have to do it “by hand” in Linux. I was assuming that the purpose of

was precisely to tell the compiler where the other libraries may be.

For comparison, here is the $LD_LIBRARY_PATH on the linux machine:

[quote]/afs/cern.ch/sw/lcg/app/releases/ROOT/5.26.00b/slc4_ia32_gcc34/root//lib:
[/quote]

and here it is on mac:

[quote]/Users/gchouda/root5.26/lib:
[/quote]

So, I would think they both say the same thing, and LD_LIBRARY_PATH shouldn’t be responsible for the difference between Mac and Linux. (?)

Thank you,
Georgios

4

Hi,

‘AddIncludePath’ only affect where to look for include files (i.e. for #include), the value that you pass there are most often different from the location of the library (i.e. usually myproject/include vs myproject/lib where we can not guess the ‘include’ and ‘lib’ part since they are only ‘convention’).

The different between linux and mac is in the way the linker records the library filename. On linux it records only the file name while on MacOS it records both the filename and its location and … thus can find it without help. On linux you must pass (via LD_LIBRARY_PATH for example) the location of the library.

Cheers,
Philippe.

5

I see… thanks a lot for the detailed explanation, Philippe!

Cheers,
Georgios