Issue with linking SQLite

I am trying to run a ROOT program that inserts into an SQLite table. However, I am running into the following error.

symbol lookup error: /home/ana/cuts/fitProMM2_C.so: undefined symbol: sqlite3_open

When I type the command root-config --has-sqlite, it returns “yes”. However, when I try root-config --libs, I don’t see -lsqlite.

ROOT Version: 6.24/02
Platform: Ubuntu 20.04
Compiler: gcc 9.4.0

Maybe: sudo apt-get install libsqlite3-0

Thank you for the response. I already have that package installed.

LANG=C ldd $(find ${ROOTSYS}/lib -name "*.so*") |& grep -i libsqlite3

BTW. “root-config --libs” will never contain “-lsqlite3” (it was only needed to build ROOT libraries).

1 Like

I get the following output when I run that command. Should I add that path to my LD_LIBRARY_PATH?

libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007feb5a1a3000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f6e97e7a000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f9bffbe5000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fc488102000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f3d46e6c000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f5cbf2cd000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f1800f53000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007f893ef31000)
libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fb759c77000)

LANG=C ldd $(find ${ROOTSYS}/lib -name "*.so*") |& grep -i "not found" | sort -u

liblhapdfdummy.so.8 => not found
libpq.so.5 => not found
libpythia.so.8 => not found

So, it means you won’t be able to use “Pythia8” and “PostgreSQL”, but the rest should be fine (just make sure you use ROOT binaries build for “Ubuntu 20.04 / x86_64, GCC 9.4” and maybe try the latest release).

If everything is fine, it means you have a problem with your own procedure which builds your own libraries / executables.

1 Like

I added /lib/x86_64-linux-gnu to LD_LIBRARY_PATH and it is working now!

Sooner or later, you’ll pay for such a brutal hack (you polluted your environment).

I see. So are you saying that I should simply re-build ROOT?

ROOT looks fine (ldd finds all needed libraries).

It seems your own “fitProMM2_C.so” was not correctly linked against “-lsqlite3” (by the way, you need “libsqlite3-dev” for this).

But then why am I getting the error message from my initial message?

ldd /home/ana/cuts/fitProMM2_C.so

1 Like

It seems to be pointing towards the proper dependency so I am baffled as to why I get an error.

||linux-vdso.so.1 (0x00007ffdaab1f000)|
||libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc18c1cd000)|
||libCore.so.6.24 => /home/patrick/root/lib/libCore.so.6.24 (0x00007fc18bcad000)|
||libRIO.so.6.24 => /home/patrick/root/lib/libRIO.so.6.24 (0x00007fc18b8bb000)|
||libMathCore.so.6.24 => /home/patrick/root/lib/libMathCore.so.6.24 (0x00007fc18b660000)|
||libGraf.so.6.24 => /home/patrick/root/lib/libGraf.so.6.24 (0x00007fc18b4e0000)|
||libHist.so.6.24 => /home/patrick/root/lib/libHist.so.6.24 (0x00007fc18b0a1000)|
||libsqlite3.so.0 => /lib/x86_64-linux-gnu/libsqlite3.so.0 (0x00007fc18af76000)|
||libGpad.so.6.24 => /home/patrick/root/lib/libGpad.so.6.24 (0x00007fc18ae96000)|
||libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007fc18acb4000)|
||libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007fc18ac99000)|
||/lib64/ld-linux-x86-64.so.2 (0x00007fc18c3e5000)|
||libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007fc18abf0000)|
||libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fc18abea000)|
||libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007fc18abc5000)|
||libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007fc18aa76000)|
||libThread.so.6.24 => /home/patrick/root/lib/libThread.so.6.24 (0x00007fc18aa0b000)|
||libImt.so.6.24 => /home/patrick/root/lib/libImt.so.6.24 (0x00007fc18a9f8000)|
||libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007fc18a939000)|
||libMatrix.so.6.24 => /home/patrick/root/lib/libMatrix.so.6.24 (0x00007fc18a7b1000)|
||libtbb.so.2 => /home/patrick/root/lib/libtbb.so.2 (0x00007fc18a76e000)|
||libMultiProc.so.6.24 => /home/patrick/root/lib/libMultiProc.so.6.24 (0x00007fc18a75f000)|
||libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007fc18a727000)|
||libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007fc18a70b000)|
||libNet.so.6.24 => /home/patrick/root/lib/libNet.so.6.24 (0x00007fc18a624000)|
||libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007fc18a591000)|
||libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007fc18a2ba000)|

Make sure you remove your LD_LIBRARY_PATH modification before trying “ldd”.

After resetting the LD_LIBRARY_PATH, I no longer see libsqlite3.so.0

||linux-vdso.so.1 (0x00007ffe60bc1000)|
||libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f2e1d67d000)|
||libCore.so.6.24 => /home/patrick/root/lib/libCore.so.6.24 (0x00007f2e1d15d000)|
||libRIO.so.6.24 => /home/patrick/root/lib/libRIO.so.6.24 (0x00007f2e1cd6b000)|
||libMathCore.so.6.24 => /home/patrick/root/lib/libMathCore.so.6.24 (0x00007f2e1cb10000)|
||libGraf.so.6.24 => /home/patrick/root/lib/libGraf.so.6.24 (0x00007f2e1c990000)|
||libHist.so.6.24 => /home/patrick/root/lib/libHist.so.6.24 (0x00007f2e1c551000)|
||libGpad.so.6.24 => /home/patrick/root/lib/libGpad.so.6.24 (0x00007f2e1c46f000)|
||libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f2e1c28d000)|
||libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f2e1c272000)|
||/lib64/ld-linux-x86-64.so.2 (0x00007f2e1d895000)|
||libzstd.so.1 => /lib/x86_64-linux-gnu/libzstd.so.1 (0x00007f2e1c1c9000)|
||libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f2e1c1c3000)|
||libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f2e1c1a0000)|
||libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f2e1c04f000)|
||libThread.so.6.24 => /home/patrick/root/lib/libThread.so.6.24 (0x00007f2e1bfe4000)|
||libImt.so.6.24 => /home/patrick/root/lib/libImt.so.6.24 (0x00007f2e1bfd1000)|
||libfreetype.so.6 => /lib/x86_64-linux-gnu/libfreetype.so.6 (0x00007f2e1bf12000)|
||libMatrix.so.6.24 => /home/patrick/root/lib/libMatrix.so.6.24 (0x00007f2e1bd8c000)|
||libtbb.so.2 => /home/patrick/root/lib/libtbb.so.2 (0x00007f2e1bd47000)|
||libMultiProc.so.6.24 => /home/patrick/root/lib/libMultiProc.so.6.24 (0x00007f2e1bd38000)|
||libpng16.so.16 => /lib/x86_64-linux-gnu/libpng16.so.16 (0x00007f2e1bd00000)|
||libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f2e1bce4000)|
||libNet.so.6.24 => /home/patrick/root/lib/libNet.so.6.24 (0x00007f2e1bbff000)|
||libssl.so.1.1 => /lib/x86_64-linux-gnu/libssl.so.1.1 (0x00007f2e1bb6a000)|
||libcrypto.so.1.1 => /lib/x86_64-linux-gnu/libcrypto.so.1.1 (0x00007f2e1b893000)|

Try to link your shared library adding “-Wl,-z,defs -lsqlite3

Sorry I don’t have much experience linking shared libraries. Did you mean to run my program as root fitProMM2.C -Wl -z -lsqlite3? I am not sure what defs means.

I did try adding he following line to my code and it seems to work now: gSystem->Load("/lib/x86_64-linux-gnu/libsqlite3.so.0");

Maybe a clarification about shared libraries: -lsqlite3 is a linker option and it only affects how a binary is built (and goes hand in hand with the -L option that tells the linker where to look for those libraries at link time). Then when you run the binary the linker still needs to be able to find the library – that’s what ldd is about. The shared library you link against at build time could be different and reside at a different path from the shared library you load at runtime.

Here it looks like the program needs a certain shared library at runtime that it was successfully built with, but it can’t find it back. LD_LIBRARY_PATH tells the runtime to also look at those locations to find back the libraries, so it fixes the problem.

Alternatively, for standard C++ applications, you could use the rpath mechanism to “build into the executable” the library paths or link the application statically so it doesn’t even need to find any library at runtime.

For a ROOT macro/script that you run via the root interpreter, gSystem->Load is another solution.

Cheers,
Enrico

1 Like