Problem compiling macros with 4.02.00 on MacOSX 10.3.6

Happy New Year to All,

I recently downloaded the binary version of root 4.02.00 for Mac OS X 10.3.6 and it seems to have 2 problems (uncorrelated ?) while compiling some code (using .L bla.C+)

First I got following error message:

[quote]
.L LumiChain.C+
Info in TUnixSystem::ACLiC: creating shared library /Volumes/Home/Users/boudry/Lumi/OnlineAnal/./LumiChain_C.so
dlopen error: dlcompat: dyld: /usr/local/root-4.02.00-tar2/root/bin/root.exe Undefined symbols:
/usr/local/root-4.02.00-tar2/root/lib/libNetx.so undefined reference to __ZN10TCondition9TimedWaitEm expected to be defined in a dynamic image
/usr/local/root-4.02.00-t
Load Error: Failed to load Dynamic link library /usr/local/root-4.02.00-tar2/root/lib/libNetx.so[/quote]

I guess the libNetx.so library has to be loaded (I don’t request it) but it’s not done correctly since this problem disappears if I load it “preventively” by hand:
gSystem->Load(“libNetx.so”)

Then I have errors on the subsequent compilations:

[quote] loading BaseData.C+
Info in TUnixSystem::ACLiC: creating shared library /Volumes/Home/Users/boudry/Lumi/OnlineAnal/./BaseData_C.so
g++: LumiChain_C.dylib: No such file or directory
Error in : Compilation failed![/quote]

Each file compiles fine if it is treated first. Starting at the second compilation an inexistant .dylib is requested.

Any idea from this might come from ?

Thanks, Vincent.

PS: I first wrongly posted this in Root discussion

Hello Vincent,

The first error happens when one tries to load libNetx.so (with, for example, .L ) before loading libThread.so. The error does not appear when you use gSystem->Load() because in this case the dependencies are taken into account correctly. So, there must be something in LumiChain.C which triggers the attempt of loading libNetx.so.
What is LumiChain.C exactly doing?

Your second problem seems to be related to the extension: ACLiC produces LumiChain_C.so, not LumiChain_C.dylib .
How does BaseData.C use LumiChain ?

Regards,
Gerri Ganis

Hello Gerri,

LumiChain.C/h contains a wrapup class of TChain, allowing me to load all the files in a directory. LumiChain inherits from TChain and was compiling without any problem until vers 4.01/02. If libNetx.so is needed, it is a side effect. Here are the includes I use:

#include <TRegexp.h> #include <TChain.h> #include <TROOT.h> #include <TString.h> #include <TUnixSystem.h> #include <TChainElement.h> #include <TFile.h> #include <TObjString.h> #include <iostream>

Any suspect in the list ? I attach LumiChain.C/h for completeness.

I never encountered the extension dylib before in my root compiled code. I suspect there was a change in the naming of the shared libraries and that some inconstencies remain, eventhough a simple linking of the .dylib’s to .so’s doesn’t help.
Note that the problem only occurs after a compilation… The loading of libraries (.so) before compilation is correctly performed.
So I can work provided that I compile only one library per root session and that I don’t load anything afterwards.

They are completly independant. BaseData.C was produced by a TTree::MakeClass call.

Cheers, Vincent.
LumiChain.h (1.16 KB)
LumiChain.C (4.51 KB)

Hello macrooters,
I have exactly the same problem! I have joined to this message a very simple example with two simple independant files. At the first compilations, I obtain the following error message:

root [0] .L Test1.C+
Info in TUnixSystem::ACLiC: creating shared library /Volumes/Utilisateurs/choubi/Documents/Travail/root/./Test1_C.so
root [1] .L Test2.C+
Info in TUnixSystem::ACLiC: creating shared library /Volumes/Utilisateurs/choubi/Documents/Travail/root/./Test2_C.so
g++: Test1_C.dylib: No such file or directory
Error in : Compilation failed!

If I quit ROOT and rerun it again, here is the error message I obtain:

root [0] .L Test1.C+
root [1] .L Test2.C+
Info in TUnixSystem::ACLiC: creating shared library /Volumes/Utilisateurs/choubi/Documents/Travail/root/./Test2_C.so
g++: Test1_C.dylib: No such file or directory
Error in : Compilation failed!

Now if I compile the second file, all seems to be OK:

root [0] .L Test2.C+
Info in TUnixSystem::ACLiC: creating shared library /Volumes/Utilisateurs/choubi/Documents/Travail/root/./Test2_C.so
root [1] .L Test1.C+
root [2] Test1()
This is the Test1 function…
root [3] Test2()
This is the Test2 function…

All work as if each file had to be compiled separately in different interactive ROOT sessions, and then all can be loaded in one single session. It would may be worth that the .dylib file be generated additionally with the .so file in AClic.

I use ROOT 4.02.00 on MacOS 10.3.8.

I hope this helps… :unamused:

Thanks for any suggestions

Daniel
Test2.C (167 Bytes)
Test1.C (167 Bytes)

ACLiC is currently deficient on MacOS (which includes but is not limited not properly creating the needed dylib). We hope to solve those issues in the coming weeks.

Cheers,
Philipppe

Bonjour,

I read the following in the release note for version 4.03/04:

* Fix several issues in libraries compiling and loading on MacOS.
* ix a few minor issues related to long long printings.

So I tried this version, but the lcmoopiling/loading problems remains.

Cheers, Vincent.

With the code now in the CVS repository, you should not see the problem (but the solution is not yet complete for macos).

Philippe.