There are some genericly common compile-, link- or run-time errors you may encounter using Daya Bay software. For ones more specific to our code see Offline Software Installation Trouble Shootting.
An error that includes a statement like:
undefined symbol: _ZN8TVector3C1Eddd
can be found during the linking of a library or application or when a library is dynamically loaded into a Gaudi or ROOT based application.
Demangling the symbol name
If the symbol was produced by C++ it will be mangled to hold type and
other information. Do make it more readable ("demangle") use
c++filt, for example
shell> c++filt _ZN8TVector3C1Eddd TVector3::TVector3(double, double, double)
To better locate what library provides the symbol, use this useful script written by Nick West for MINOS.
shell> find_global_symbol.sh _ZN8TVector3C1Eddd Searching for mangled symbol _ZN8TVector3C1Eddd ... Found in libPhysics.so Entry: 1482:0003076e T _ZN8TVector3C1Eddd Translates to 0003076e T TVector3::TVector3(double, double, double)
Cause of the error
The most common cause of this error is "version shear" where different parts of the code have been compiled against differing versions of libraries and/or with different versions of the C++ compiler.
Another possible way to produce this error is to load a library that references a symbol that is provided by a library that hasn't yet been loaded.
The symbol name should indicate what library should provide it. Make sure your code is compiled against the same version that is being linked. If you are dynamically loading a library needing this symbol, make sure the library that provides it is loaded first.