CMake Error at /home/....../bin/cmake_install.cmake:46 (file):
file Paths to dependencies are not supported
Call Stack (most recent call first):
/home/....../bin/sub/cmake_install.cmake:99 (include)
CPack Error: Error when generating package: mypkg
Can somebody help me interpret what this error message is trying to tell me, and how I can fix it?
I looked at the source code where the error is triggered in cpack but I still don’t get it. If I interpret it correctly, it tells me that there is a dependency which includes a path (something with a forward slash in it), and that cmake cannot handle such a dependency. But it seems there is no way to get cpack to tell me what dependency is causing this problem. If I see correctly, there currently is no way to get cpack to output the name of the offending depency. Should I report a bug for this? Otherwise it seems like a frustrating guessing game to fix such a problem…
The command in my cmake code which leads to the error is:
And before, I’m adding several executable and shared library targets to the MyDependencySet via install(TARGETS libname RUNTIME_DEPENDENCY_SET MyDependencySet (RUNTIME|LIBRARY) DESTINATION destfolder)
Can you post whatever’s at line 46 of that /home/....../bin/cmake_install.cmake file? (And any relevant context in either direction.)
The problem might be that first backslash in your PRE_EXCLUDE_REGEXES list (the first argument is [[\libc\.so\..*]] instead of [[libc\.so\..*]]), since it might be failing to exclude libc.so.whatever as a result?
Basically, what happens in that code is that GetFileInfo runs objdump -p on whatever binary file (executable or shared library) you’re installing, parsses out all of the NEEDED, RPATH, and RUNPATH lines in the output (by regex), and returns lists of them to the ScanDependencies function.
ScanDependencies expects any NEEDED line that isn’t PRE_EXCLUDED to have no path separators in it — to be a dynamic linker soname reference like libfoo.so.1 or libbar-2.so.0. If it finds a path separator in a non-excluded NEEDED line, you’re toast.
So, one thing to do would be to run objdump -p on whatever file is being processed at line 46 of your install script, and see if its NEEDED lines include any path separators. If they do, that’s bad, so figuring out why would be important.
Even local binaries in the build tree would normally be linked using SONAME references and RUNPATHs, when building with CMake, so the path separators exclusion is a good safety check.
For example, I have a CMake build of Graphviz where the dot executable is linked with the shared libs in the build directory, but even there that’s done using a combination of RUNPATH and sonames:
In the meantime I rebuilt cpack to output the content of the “dep” message in the output. This showed me that it’s a dependency of one of my shared libraries that my build references via full path (libopenvr_api.so).
Investigating a bit further with objdump -p (thanks for that recommendation), this actually gets pulled in automatically by the dependency to vtkRenderingOpenVR. The linked libvtkRenderingVR-9.3.so.1 also has this direct path dependency.
I haven’t come around to test the VR stuff yet under linux anyway, so I’m going to discard it from build for now I guess…
I suppose if you’re using some form of CMake’s SKIP_BUILD_RPATH, that might cause binaries to be linked with full paths. If so, don’t do that.
I’m not doing this; the path somehow seems to come from the way that vtk links to the openvr api (I’m just specifying a path to the shared library via OpenVR_LIBRARY, the rest is done by the vtk build as far as I can tell).
Hmm, yeah… it sounds like libvtkRenderingVR was just misbuilt, possibly in a brute-forcey sort of way. For a RUNTIME_DEPENDENCY_SET, that’s not going to work, because the whole point of collecting runtime dependencies is to link to them in a relocatable way.
If a library is linked with libopenvr_api.so.1 by soname reference, and (if needed) has a RUNPATH that includes /path/to/that/lib, no problem; the library can be copied anywhere, and a RUNPATH set in its dependencies like libvtkRuntimeVR.so that points to the destination directory.
But if something’s linked with the full path, then no matter where you put the library and no matter what you do with RUNPATHs, the dependents are going to be looking for it at /path/to/that/lib/libopenvr_api-so.1, and your runtime dependencies are no longer self-contained and relocatable.
Fedora doesn’t seem to have libvtkRenderingVR packaged; it does have a VTK package without that library, and openvr-api contains libopenvr_api.so.1, but I guess the question is where does vtkRenderingOpenVR come from and can it be rebuilt without full-path linking?
Other than, maybe, that it’s obsolete. That doc says:
The OpenVR standard has been succeeded by the industry-wide OpenXR standard. See the VTK OpenXR module for modernized support. The VTK OpenVR module is preserved for legacy support.
