Strange behaviour when loading two class one after the other

ROOT
1

Dear ROOTers,

I have the files of the two classes “GenericDAQBoard” and “LHCbM1R1_3GEMChamber” in the same directory:

root [0] .! ls GenericDAQBoard.cxx GenericDAQBoard_cxx.so LHCbM1R1_3GEMChamber.cpp LHCbM1R1_3GEMChamber_cpp.so GenericDAQBoard_cxx.d GenericDAQBoard.h LHCbM1R1_3GEMChamber_cpp.d LHCbM1R1_3GEMChamber.h

  1. If I load one of the class:

root [1] .L GenericDAQBoard.cxx+ dlopen error: LHCbM1R1_3GEMChamber_cpp.so: cannot open shared object file: No such file or directory Load Error: Failed to load Dynamic link library /home/supergem/CosmicRays/New/./GenericDAQBoard_cxx.so *** Interpreter error recovered ***

I have to load the LHCbM1R1_3GEMChamber class to avoid this error, but the two classes have NOTHING in common… no included headers, no member object… nothing

If I remove the *.so and *.d files and recompile them in the opposite order, I get the “opposite dependence”

[quote]root [0] .! ls
GenericDAQBoard.cxx GenericDAQBoard.h LHCbM1R1_3GEMChamber.cpp LHCbM1R1_3GEMChamber.h
root [1] .L GenericDAQBoard.cxx+
Info in : creating shared library /home/supergem/CosmicRays/New/./GenericDAQBoard_cxx.so
root [2] .L LHCbM1R1_3GEMChamber.cpp+
Info in : creating shared library /home/supergem/CosmicRays/New/./LHCbM1R1_3GEMChamber_cpp.so
root [3] .q
~/CosmicRays/New>root.exe
[…]

  •    W E L C O M E  to  R O O T       *
  • Version 4.03/04 12 April 2005 *
    […]
    root [0] .L LHCbM1R1_3GEMChamber.cpp+
    dlopen error: GenericDAQBoard_cxx.so: cannot open shared object file: No such file or directory
    Load Error: Failed to load Dynamic link library /home/supergem/CosmicRays/New/./LHCbM1R1_3GEMChamber_cpp.so
    *** Interpreter error recovered ***
    root [1] .!ls
    GenericDAQBoard.cxx GenericDAQBoard.h LHCbM1R1_3GEMChamber_cpp.d LHCbM1R1_3GEMChamber.h
    GenericDAQBoard_cxx.so LHCbM1R1_3GEMChamber.cpp LHCbM1R1_3GEMChamber_cpp.so[/quote]

Is it the standard behaviour? (and i never noticed it because i have always loaded classes in the same order…)

  1. Moreover I have noticed that, after every time i delete the *.so and *.d file, the .d file is not always regenerated… I cannot understand why…
2

I tryed loading two classes in one directory without any problem. I used JetEvent and Quad classes from $ROOTSYS/tutorials (really independent)

Jan
ROOT_5.11.06

3

The .d files are only generated if the code is compiled. Aka never delete the .d independently of .so.

In order to implement proper dependency loading, a shared library is always (on linux) linked against all the library already loaded.

If you need independent libraries, you need to build them in separate ROOT session.

Cheers,
Philippe.

4

[quote=“pcanal”]The .d files are only generated if the code is compiled. Aka never delete the .d independently of .so.

In order to implement proper dependency loading, a shared library is always (on linux) linked against all the library already loaded.

If you need independent libraries, you need to build them in separate ROOT session.

Cheers,
Philippe.[/quote]

So, to avoid any problem, can I build library in separate session as a general rule?
I mean: I use these classes in three unnamed macro. In the first two I use only 1 of them and in the third both of them.
Is it suitable for all these cases?

About the .d files, I always deleted it together with the .so . I noticed that when i recompiled the library again, they are not always regerated together with the .so

5

[quote]So, to avoid any problem, can I build library in separate session as a general rule?
[/quote]Indeed.

[quote]Is it suitable for all these cases? [/quote]Yes.

[quote]About the .d files, I always deleted it together with the .so . I noticed that when i recompiled the library again, they are not always regerated together with the .so[/quote]Sorry, I was mistaken. The .d files is generated only if you execute .L macro.C+ and the macro_C.so already exist.

Cheers,
Philippe.