Library "not found" after building test with CMake on Ubuntu.

I built VTK from source (8.2.0) and I am using CMake 3.13.
My system is Ubuntu 19.10, with kernel 5.3.0-42-generic.

I copied the sphere example into a directory.

I did not use the CMakeLists.txt file in the example, but I did use it as a guide for what I wrote:
cmake_minimum_required(VERSION 3.12)
project(“Display Sphere Example”)

set(VTK_DIR /home/me/opt/vtk/lib/cmake/vtk-8.2)
find_package(VTK REQUIRED)

add_executable(test
  test.cpp)

target_link_libraries(test
  PRIVATE
  ${VTK_LIBRARIES})

Afterwards, the executable built without error, but when running it, it appears that there are some VTK libraries that are not found (and confusingly, some are found)? Running “readelf -d” on the resulting executable gives the correct RUNPATH:
(RUNPATH) Library runpath: [/home/me/opt/vtk/lib]
The RPATH is not set … and LD_LIBRARY_PATH does not contain “/home/me/opt/vtk/lib” (and I would rather not set LD_LIBRARY_PATH - although I will if I have to).

Running ldd on the resulting executable gives:

libvtkFiltersSources-8.2.so.1 => correct full path to library

libvtkFiltersGeometry-8.2.so.1 => not found

DT_RUNPATH is the replacement for DT_RPATH, so not having an RPATH is fine. However, it is odd that you have some VTK libraries and not others. Does ${VTK_LIBRARIES} look sensible to you when you build the example?

Hi Ben - VTK_LIBRARIES did indeed look sane, but what I was missing was:
include(${VTK_USE_FILE})

It has been a few years since I have used VTK, and things seem to have evolved somewhat in my absence …

Thanks for looking at my question.

Ah, yes, that would do it. In any case, VTK_USE_FILE is no longer needed in 9.0. I’ve grown foggy on remembering all the details of the 8.2 (and older) build system, sorry.

So - I should just get 9 … I’ll download it now.

Ok - downloaded 9.0.0, now the CMakeLists.txt file is:

cmake_minimum_required(VERSION 3.12)
project("Example")
set(VTK_DIR /home/me/opt/vtk/lib/cmake/vtk-9.0)
find_package(VTK REQUIRED)

add_executable(test test.cpp)
target_link_libraries(test ${VTK_LIBRARIES})
vtk_module_autoinit(TARGETS test
  MODULES ${VTK_LIBRARIES})

The executable builds fine, but only seems to be able to find all of the libraries when LD_LIBRARY_PATH is set (which I would prefer to not do). Apparently when it “worked” above, I was still in the shell that I had set LD_LIBRARY_PATH in.

ldd and readelf show similar results to the first time around.

CMake should be adding RPATH entries in your build tree automatically. You may need to add paths for your install tree manually.

I think that CMake is setting RUNPATH correctly (my understanding is that RUNPATH has superseded RPATH). This is a part of what readelf -d returns for the executable … by now, I am starting to get the feeling that this really isn’t VTK’s fault at all, but I figured that there were plenty of other VTK users on Ubuntu who might know the answer …

[me@laptop build]$readelf -d test 

Dynamic section at offset 0x4b50 contains 42 entries:
  Tag        Type                         Name/Value
 0x0000000000000001 (NEEDED)             Shared library: [libvtkInteractionStyle-9.0.so.1]
... stuff ...
 0x0000000000000001 (NEEDED)             Shared library: [libstdc++.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libm.so.6]
 0x0000000000000001 (NEEDED)             Shared library: [libgcc_s.so.1]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]
 0x000000000000001d (RUNPATH)            Library runpath: [/home/me/opt/vtk/lib]
... morestuff ...

I think I have an idea about what the reason might be. I found it on one of Qt’s pages. The libraries that are indirectly loaded from the directly loaded libraries don’t have the RUNPATH set, so they can’t find the indirectly loaded libraries since they are in a nonstandard location.

I could stick the RUNPATH in there with patchelf, but apparently chrpath won’t do the job. I’m stuck using LD_LIBRARY_PATH until I can figure out a way to get CMake to put it in there for me.

1 Like

RUNPATH is not inherited across the loaded library chain, so each library in a non-standard place would need the -rpath flag for $ORIGIN. You’ll have to update the builds of those projects to set the proper flags.

What was confusing to me was that OpenCV builds with CMake and I don’t have this problem (it embeds the right RUNPATH in the resulting libraries), but VTK doesn’t for some reason.

There is a CMake wiki that talks about RPATH and sort of mentions the problem that I was having. I thought that it would have been as simple as supplying -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE.

I guess that I will have to compare the two project CMakeLists.txt files to see if I can spot the difference.

OpenCV might be setting some settings apart from default CMake settings like that. But CMAKE_INSTALL_RPATH_USE_LINK_PATH could certainly help here.

I had the same issue today and this is the solution I found. I need to specify both commands for it to work in a non-default install directory:

cmake -DCMAKE_INSTALL_PREFIX=/opt/VTK -DCMAKE_INSTALL_RPATH=/opt/VTK/lib -DCMAKE_INSTALL_RPATH_USE_LINK_PATH=TRUE /opt/VTK-src

Now I can include VTK and ldd finds all libraries!

You are a hero! Thanks!

1 Like

Today I removed the apt package VTK7 from my Ubuntu20.04.
Then I compiled VTK8.2 from source with default configuration created with ccmake. (Eg.: CMAKE_INSTALL_PREFIX=/usr/local)
Now when I run my applications that are based on VTK I get errors like this:
“error while loading shared libraries: libvtksys-8.2.so.1: cannot open shared object file: No such file or directory”
readelf -d ./myApplication shows that I am using “RUNPATH”.
I did not change the default path but still I have the same problems described here.
Any tips on how to fix this? I have struggle to translate the solution to my problem.

What is the result of:
locate libvtk*.so ?

and then:
ls -l fileyoufound.so

Did you recompile your application after compiling VTK?

What is the output of
ldd ./MyApplication

:~$ locate libvtk*.so

returns nothing. Did not expect that…

:/usr/local/lib$ ls
[...]
libvtksys-8.2.so
libvtksys-8.2.so.1
libvtktheora-8.2.so
libvtktheora-8.2.so.1
libvtktiff-8.2.so
libvtktiff-8.2.so.1
libvtkverdict-8.2.so
libvtkverdict-8.2.so.1
libvtkViewsContext2D-8.2.so
libvtkViewsContext2D-8.2.so.1
libvtkViewsCore-8.2.so
libvtkViewsCore-8.2.so.1
libvtkViewsInfovis-8.2.so
libvtkViewsInfovis-8.2.so.1
libvtkzlib-8.2.so
libvtkzlib-8.2.so.1

And:

:/usr/local/lib$ ls -l fileyoufound.so
ls: Zugriff auf 'fileyoufound.so' nicht möglich: Datei oder Verzeichnis nicht gefunden
-> sth. like "Access not possible. File or directory not found"

My application uses library X and this has VTK as dependency. I recompiled both several times. Did not change anything. Already the compiled examples of library X fail at runtime with missing one of vtk’s .so files.

Run ‘sudo updatedb’ before calling ‘locate’.

How do you compile your library? With make or cmake?

Do you specify -Wl,rpath=/usr/local/lib ?

What is the output of:
ldd ./MyApplicaction

?

1 Like

Same result for “locate” after “sudo updatedb”.

VTK and library X using VTK are compiled with

mkdir build
cd build
ccmake ..
make -j
sudo make install

Yesterday I got:

ldd ./myApplication
libvtkfreetype-8.2.so.1 => not found
libvtkglew-8.2.so.1 => not found
libvtkCommonSystem-8.2.so.1 => not found
libvtksys-8.2.so.1 => not found
libvtkFiltersGeometry-8.2.so.1 => not found
libvtkCommonComputationalGeometry-8.2.so.1 => not found
libvtkCommonSystem-8.2.so.1 => not found
libvtkCommonMisc-8.2.so.1 => not found
libvtksys-8.2.so.1 => not found

Today libraries are found. I dont really know why…

$ ldd ./ground_truth_gen 
libvtkInteractionStyle-8.2.so.1 => /usr/local/lib/libvtkInteractionStyle-8.2.so.1 (0x00007f7e1a757000)
libvtkRenderingFreeType-8.2.so.1 => /usr/local/lib/libvtkRenderingFreeType-8.2.so.1 (0x00007f7e1a68b000)
libvtkRenderingOpenGL2-8.2.so.1 => /usr/local/lib/libvtkRenderingOpenGL2-8.2.so.1 (0x00007f7e1a2a1000)
libvtkRenderingCore-8.2.so.1 => /usr/local/lib/libvtkRenderingCore-8.2.so.1 (0x00007f7e19f0c000)
libvtkCommonDataModel-8.2.so.1 => /usr/local/lib/libvtkCommonDataModel-8.2.so.1 (0x00007f7e1989f000)
libvtkCommonMath-8.2.so.1 => /usr/local/lib/libvtkCommonMath-8.2.so.1 (0x00007f7e19873000)
libvtkCommonCore-8.2.so.1 => /usr/local/lib/libvtkCommonCore-8.2.so.1 (0x00007f7e18f2b000)

I dont know why it is suddenly running. I linked one of my several CMake tagets with -Wl,--enable-new-dtags which seemed to solve the problem. But this was no solution in my case as I also need the example tools build with library X. As these still failed, I deleted the extra flags in my CMakeList.txt.
These example tools still fail. I will look at this again.

Try with:
locate libvtksys
without the *

or
locate libvtk

-Wl,rpath=… could also help when compiling maybe.

Otherwise, exporting LD_LIBRARY_PATH with your extra search path, too, to see if it runs well.

1 Like