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”)
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?
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.
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.
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 …
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.
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.
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.
:/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.
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…
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.