Problems using ACLiC on Mac OS X v10.6

I have successfully (I think!) built ROOT v5.30/00 on my MacBook Pro running Mac OS X v10.6.8. Here are the steps I followed:

  1. Download Xcode4
  2. run ./configure (with no arguments)
  3. run make

I am then able to successfully run root from the command line. Now, I am trying to use the ACLiC compiler within a macro to compile some C code. The macro is below (file name ana_standalone.C):

#include “…/…/…/GMSBTools/Filters/interface/Typedefs.h"
void ana_standalone() {
gSystem->Load(“libSusy.so”);
gSystem->Load(”…/jec/lib/libJetMETObjects.so");
gSystem->Load("…/…/…/GMSBTools/lib/libFilters.so");
gROOT->LoadMacro(“SusyEventPrinter.cc++”);
}

The first 3 lines are shared libraries I successfully built using gcc. I am trying to have ACliC compile the SusyEventPrinter.cc file. When I run root -l -q ana_standalone.C from the command line, I get the following error:

Processing ana_standalone.C…
Info in TUnixSystem::ACLiC: creating shared library /Users/rachelyohay/RA3/src/SusyAnalysis/SusyNtuplizer/macro/./SusyEventPrinter_cc.so
dlopen error: dlopen(/Users/rachelyohay/RA3/src/SusyAnalysis/SusyNtuplizer/macro/./SusyEventPrinter_cc.so, 10): Library not loaded: …//lib/libJetMETObjects.so
Referenced from: /Users/rachelyohay/RA3/src/SusyAnalysis/SusyNtuplizer/macro/./SusyEventPrinter_cc.so
Reason: image not found
Load Error: Failed to load Dynamic link library /Users/rachelyohay/RA3/src/SusyAnalysis/SusyNtuplizer/macro/./SusyEventPrinter_cc.so
Undefined symbols for architecture x86_64:
"_main", referenced from:
start in crt1.10.6.o
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
(Int_t)0

Following some Google and ROOTTalk suggestions, I double checked using root-config --arch that the architecture ROOT was built for was indeed macosx64. However, it seems like ACLiC is somehow getting confused about what architecture it should be. Should I have instead built it for 32 bits? When I run uname -p, it says macosx64, so I think it should all work with the 64-bit architecture.

I also tried compiling with g++, i.e. g++ -c root-config --cflags SusyEventPrinter.cc. This gives no errors and successfully creates the .o file.

I would really appreciate any suggestion as to why this is not working, and what I can do to fix it.

Thanks,
Rachel Yohay

I have solved my problem. Alas, It had nothing to with ACLiC. Word to the wise: when writing makefiles for Mac OS X, always use absolute path names, not relative ones (e.g. /home/yourname/yourdir/makefile instead of …/makefile). The path name is somehow encoded into the shared library objects that are created by the makefile, but it is not very smart about relative path names. So, when you change directories and try to include that shared library in a new object (as I tried to do when calling LoadMacro), somebody gets confused about where the needed libraries should be (“Reason: image not found.”). This website had the hint: cmake.org/pipermail/paraview … 08649.html

  • Rachel

Ciao,

I found your post ‘googling’ and I was exactly the same problem: if I

  1. load my library (a. so)
  2. add the include path
  3. load and compile my macro (.L macro.C+)

from the “root” directory of my software, where the library has been compiled (and put inside lib//…) it works, while if I do from a subdirectory, ‘Analyze’, where the macro is supposed to be, it does not compile giving this ‘image not found’ error and this error about a missing “_main” (obviously step 1 and 2 gives NO error and the library is correctly loaded: the dictionary is loaded and I’m able to see my classes from CINT…).

Did you understand how to solve the problem compiling the library in a different way?

Thanks,
Matteo

In my ROOT macro, the important lines are

gSystem->Load("…/jec/lib/libJetMETObjects.so");
gROOT->LoadMacro(“SusyEventPrinter.cc++”);

When it tries to compile SusyEventPrinter.cc, it complains because it depends on, but can’t find, libJeMETObjects.so, which is supposed to be loaded in an earlier line of the macro. The problem is that libJETMETObjects.so was compiled using a makefile that used relative path names, which Mac OS X doesn’t like. So I ended up changing the relative paths to absolute paths in the makefile, recompiling libJetMETObjects.so, and then rerunning the macro. Then the gROOT->LoadMacro(“SusyEventPrinter.cc++”); line worked fine on my Mac.

The makefile that worked for libJetMETObjects.so on my Mac is here:

github.com/rpyohay/usercode/blo … s/Makefile

But in your case, you probably just want to see the places where I had to change from relative to absolute path names. Here is a diff of the makefile between the OS X and non-OS X versions:

github.com/rpyohay/usercode/com … 4074dd9e82

So basically in most of the places where I originally had things like “…/whatever”, they had to be changed to “/full/path/to/whatever”. Hopefully your problem will be solved if you try this trick on your makefiles.

Ciao,

thanks a lot for the answer!

But so does it means that if you take the whole directory with your sw and try again to load the library and then to compile the macro it will fail again?
If yes I don’t like… There should be some smarter solution…

I will try to find something and in case I will let you know.

Thanks again!
Matteo