Loading shared object library in root doesn't find root class in libraries

ROOT Version: 6.20.04
Platform: CentOS Linux release 7.9.2009
Compiler: 4.8.5

I find that when I create a shared object library for my own classes which contain other ROOT classes, specifically TLorentzVector, then when I load the library in root it can not find the ROOT class until I create an object of that type.

Here is an example class

#include <TLorentzVector.h>
class test : public TObject
    TLorentzVector 	x ;


#include "test.hxx"


#ifdef __CLING__
#pragma link C++ class test;

Commands to create shared object library

c++  -O2 -Wall -fPIC `root-config --cflags` -c test.cxx
rootcling -f testDict.cxx -c test.hxx test_LinkDef.h
c++  -O2 -Wall -fPIC  `root-config --cflags` -c testDict.cxx
c++ -shared -O2 -m64 test.o testDict.o -o  libtest.so 

What happens in root:

  | Welcome to ROOT 6.20/04                        https://root.cern |
  | (c) 1995-2020, The ROOT Team; conception: R. Brun, F. Rademakers |
  | Built for linuxx8664gcc on Apr 01 2020, 08:28:48                 |
  | From tags/v6-20-04@v6-20-04                                      |
  | Try '.help', '.demo', '.license', '.credits', '.quit'/'.q'       |

root [0] 
Processing libtest.so...
cling::DynamicLibraryManager::loadLibrary(): /home/aleph/ajf/t2k/analysis/analyseLowEnergyECalObjects/crazyROOT/libtest.so: undefined symbol: _

Bizarre observation. If I use the name myTest for the class and file names, it works.
This also works:

root [0] TLorentzVector v;
root [1] .L libtest.so
root [2] test z;
`root-config --cxx --cflags` -O2 -shared -o libtest.so test.o testDict.o `root-config --libs`

BYW. You probably want: #pragma link C++ class test+;

Thanks for that its been driving me crazy. The recipe I had been using worked fine in ROOT 5 for years.

Would it be possible to improve the description in the Users Guide : Compilation

Step 4: Compile the class using the `Makefile.

which just tells you to go and look in the $ROOTSYS/test Makefile, and includes a broken link to http://root.cern.ch/root/RootCintMan.html ?

Does it really end there? Nothing behind _?

As your library depends on libPhysics you should link against that, as @Wile_E_Coyote shows, root-config --libs is a good way to get there. This is only to some extent a change in ROOT itself, and to a larger extent a change in all modern Linux distributions many of which now error out when building shared libraries with unresolved symbols.

Thank’s for pointing out the doc issue; we’ll get that fixed.

Oops, didn’t notice it got cut off. It should have said.

cling::DynamicLibraryManager::loadLibrary(): /home/aleph/ajf/t2k/analysis/analyseLowEnergyECalObjects/libBadTreeDictionary.so: undefined symbol: _ZTV14TLorentzVector

Thanks for your help @Wile_E_Coyote 's solution worked, and hopefully updating the documentation will help anyone else out there with the same problem.

1 Like

The user guide is not updated any more. We keep it for the time being to not lose some possible missing information in “Manual” in the new web site. The root-config mechanism is explained here the Manual : Creating a user application with ROOT - ROOT . If you think something should be added there, let us know.

I am surely missing something but I do no see any link in $ROOTSYS/test/Makefile

The useful information is actually here:

I understand not wanting to remove potentially useful documentation but unfortunately in this case it is now out of date and of course it is hard to control which set of instructions people will pick up if they are using google to search for a solution. To see what I am talking when I refer to a broken link about look at ROOTUsersGuide (actually one line above this anchor location) where you will find the broken link. Similarly in the pdf version of the file.

We plan to remove the User’s Guide at some point. But I might be not enough to remove it completely from the web as Google has sometimes a very good memory.

Hopefully this thread will also appear near the top of people’s google searches!

This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.