"root-config --glibs" output does not match files in libs/ directory

ROOT Version: 6.20.02
Platform: Scientific Linux 6
Compiler: gcc 7.3.1

I’m trying to compile a package (rootana) against ROOT and am getting the following error:

g++ -o libAnalyzer/analyzer_example.exe -g -O2 -Wall -Wuninitialized -I./include -DHAVE_LIBZ -DHAVE_ROOT -pthread -std=c
++11 -m64 -I/cdms/app/home/nexusdaq/packages/root-6.20.02/include -DHAVE_ROOT_XML -DHAVE_ROOT_HTTP -DHAVE_THTTP_SERVER -
DHAVE_LIBNETDIRECTORY -DHAVE_XMLSERVER libAnalyzer/analyzer_example.o lib/librootana.a -L/cdms/app/home/nexusdaq/packag
es/root-6.20.02/lib -L/cdms/app/home/nexusdaq/packages/root-6.20.02/lib -lGui -lCore -lImt -lRIO -lNet -lHist -lGraf -lG
raf3d -lGpad -lROOTVecOps -lTree -lTreePlayer -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lMultiProc -lR
OOTDataFrame -pthread -lm -ldl -rdynamic -lThread -lXMLParser -lXMLIO -lRHTTP -lm -lz -lpthread -Wl,-rpath,/cdms/app/hom
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: cannot find -lGui
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: cannot find -lPostscript
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: cannot find -lROOTDataFrame
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: cannot find -lXMLIO
/opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: cannot find -lRHTTP

The reason I’m posting this on the ROOT forum is that I’m seeing a mismatch between what ROOT reports as the libraries it knows about and the files in the libs/ directory:

$ root-config --glibs
-L/cdms/app/home/nexusdaq/packages/root-6.20.02/lib -lGui -lCore -lImt -lRIO -lNet -lHist -lGraf -lGraf3d -lGpad -lROOTVecOps -lTree -lTreePlayer -lRint -lPostscript -lMatrix -lPhysics -lMathCore -lThread -lMultiProc -lROOTDataFrame -pthread -lm -ldl -rdynamic

Whereas if I look in the libs/ directory of my ROOT installation there is definitely no e.g. libGui.so.

Does anyone know why root-config --glibs doesn’t match up with the library files I see on disk? Or have ideas on how to avoid these errors?

I’ve seen a suggestion to yum install root-tree-dataframe -y but I can’t find any documentation on the ROOT site about this package.

Try: root-config --features

Interesting, this still doesn’t quite line up with the files in my libs/ directory. Notably, there’s no libROOTDataFrame.so file

$ root-config --features
cxx11 asimage builtin_afterimage builtin_clang builtin_davix builtin_fftw3 builtin_ftgl builtin_gl2ps builtin_glew builtin_llvm builtin_lz4 builtin_lzma builtin_pcre builtin_tbb builtin_vdt builtin_xxhash builtin_zstd clad dataframe davix exceptions fftw3 gdml http imt mlp mysql opengl pgsql pyroot roofit runtime_cxxmodules shared sqlite ssl tmva tmva-cpu tmva-pymva spectrum vdt x11 xml

Can it be that the building of ROOT died in the middle and so not all libraries were built?

@Axel Is the “devtoolset-7” supported on a “SL6” yet?

@Wile_E_Coyote oh yikes you’re exactly right. My build log indicates issues with building ROOTDataFrame against sqlite3:

/cdms/app/home/nexusdaq/packages/root/tree/dataframe/src/RSqliteDS.cxx: In function ‘int {anonymous}::VfsRdOnlyOpen(sqlite3_vfs*, const char*, sqlite3_file*, int, int*)’:
/cdms/app/home/nexusdaq/packages/root/tree/dataframe/src/RSqliteDS.cxx:195:4: error: too many initializers for ‘const sqlite3_io_methods’

It looks like a solution to this might be in the last post at Problems compiling root with gcc 9.1.

if you don’t need support for sqlite files in ROOT, you can build with -Dsqlite=OFF, that should avoid compilation errors in RSqliteDS.cxx. Now about why you get those errors, I think it’s because the sqlite version you have installed is too old for ROOT. @jblomer can confirm (if that’s the case, should/can/do we diagnose too old sqlite versions in our cmake configuration?).


Thanks for the problem report! Yes, it is a problem with older versions of sqlite. I think the code could be easily changed to work with older sqlite versions, too. Ticket created.

1 Like

I do not need sqlite and when I turn it off I no longer get this particular error. Right now I’m using the following arguments:

cmake -D builtin_fftw3:BOOL=ON -Dbuiltin_afterimage=ON -Dsqlite=OFF -Dbuiltin_xrootd=ON -Dhttp=ON ../root_6.20.06

However, I’ve been getting a slew of “error adding symbols: File in wrong format” issues, with

  • /usr/lib/libgif.so
  • /usr/lib/libtiff.so
  • /usr/lib/libgl.so

I think the issue may be that it’s trying to link against libraries in /usr/lib rather than /usr/lib64 but I’m not sure how to force it to change where it’s linking.

For the gif and tiff libraries I installed recent versions with spack, but I’m not able to install the gl libraries with spack.

Uhm I’m afraid I do not have enough experience with SL6 to help with libgl.

As an alternative to building ROOT yourself, however, I can suggest installing ROOT in a conda environment – if it works for your usecase/platform. It’s easy and quick to get it up, and it just works on 99% of the linux platforms. More information in this blog post.


You probably need to install “giflib-devel”, “libtiff-devel” and “mesa-libGL-devel” packages.

Little update: ROOT does not support SL6+devtoolset, and SL6 is very near to end of life so it’s unlikely to happen, I’m afraid.

I explicitly asked this question here …

I guess I would appreciate a “renewed” official statement from @Axel concerning building and using ROOT 6 with “devtoolset-8” and “devtoolset-7” on SL[C]6 / CentOS6 and SL7 / CentOS7 (e.g. maybe some “devtoolset” is known to work on one of them). Even if these system may seem outdated, there are still many batch clusters which use them. The old statement:

Nothing changed: we have not received a PR (or an offer to work on one with our guidance), and CERN isn’t increasing its investment in cling. As is, devtoolset is not supported in cling. Instead, one can install the full compiler (GCC >= 4.8) and use that on SLC6.

What about “devtoolset-[78]” on SL7 / CentOS7?


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