# "file Paths to dependencies are not supported" on cpack with RUNTIME\_DEPENDENCY\_SET
**URL:** https://discourse.cmake.org/t/file-paths-to-dependencies-are-not-supported-on-cpack-with-runtime-dependency-set/11434
**Category:** Usage
**Created:** [August 13, 2024, 2:29pm UTC](https://discourse.cmake.org/t/file-paths-to-dependencies-are-not-supported-on-cpack-with-runtime-dependency-set/11434 "2024-08-13T14:29:05Z")
**Posts on this page:** 6
**Page:** 1
### Author:  [@codeling](https://discourse.cmake.org/u/codeling)
#### Post date: [August 13, 2024, 2:29pm UTC](https://discourse.cmake.org/t/file-paths-to-dependencies-are-not-supported-on-cpack-with-runtime-dependency-set/11434/1 "2024-08-13T14:29:05Z")
Continuing my migration to [RUNTIME\_DEPENDENCY\_SET](https://discourse.cmake.org/t/migration-experiences-comparison-runtime-dependency-set-vs-fixup-bundle-bundleutilities/11323), I am now testing on Linux.
There, I get an error message:
```auto
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](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmBinUtilsLinuxELFLinker.cxx#L145-L146) 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:
```auto
install(RUNTIME_DEPENDENCY_SET MyDependencySet
PRE_EXCLUDE_REGEXES
[[\libc\.so\..*]]
[[libgcc_s\.so\..*]]
[[libm\.so\..*]]
[[libstdc\+\+\.so\..*]]
DIRECTORIES ${BUNDLE_DIRS}
DESTINATION .
)
```
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)`
---
### Author:  [@ferdnyc](https://discourse.cmake.org/u/ferdnyc)
#### Post date: [August 14, 2024, 12:55pm UTC](https://discourse.cmake.org/t/file-paths-to-dependencies-are-not-supported-on-cpack-with-runtime-dependency-set/11434/2 "2024-08-14T12:55:44Z")
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?
---
### Author:  [@ferdnyc](https://discourse.cmake.org/u/ferdnyc)
#### Post date: [August 14, 2024, 1:23pm UTC](https://discourse.cmake.org/t/file-paths-to-dependencies-are-not-supported-on-cpack-with-runtime-dependency-set/11434/3 "2024-08-14T13:23:27Z")
Basically, what happens in that code is that [`GetFileInfo`](https://gitlab.kitware.com/cmake/cmake/-/blob/master/Source/cmBinUtilsLinuxELFObjdumpGetRuntimeDependenciesTool.cxx#L22) 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 `RUNPATH`s, 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:
```console
$ objdump -p .../_build/cmd/dot/dot |grep -E '(NEEDED|RUNPATH|RPATH)'
NEEDED libm.so.6
NEEDED libgvc.so.6
NEEDED libcgraph.so.6
NEEDED libcdt.so.5
NEEDED libltdl.so.7
NEEDED libz.so.1
NEEDED libc.so.6
RUNPATH .../_build/lib/gvc:.../_build/lib/cgraph:../_build/lib/cdt:
```
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. 😀
---
### Author:  [@codeling](https://discourse.cmake.org/u/codeling)
#### Post date: [August 14, 2024, 1:35pm UTC](https://discourse.cmake.org/t/file-paths-to-dependencies-are-not-supported-on-cpack-with-runtime-dependency-set/11434/4 "2024-08-14T13:35:18Z")
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).
---
### Author:  [@ferdnyc](https://discourse.cmake.org/u/ferdnyc)
#### Post date: [August 14, 2024, 2:27pm UTC](https://discourse.cmake.org/t/file-paths-to-dependencies-are-not-supported-on-cpack-with-runtime-dependency-set/11434/5 "2024-08-14T14:27:54Z")
> [@codeling](#):
>
> 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.
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 `RUNPATH`s, 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?
---
### Author:  [@ferdnyc](https://discourse.cmake.org/u/ferdnyc)
#### Post date: [August 14, 2024, 3:07pm UTC](https://discourse.cmake.org/t/file-paths-to-dependencies-are-not-supported-on-cpack-with-runtime-dependency-set/11434/6 "2024-08-14T15:07:17Z")
Hm. Looks like vtkRenderingOpenVR is [part of the standard distribution](https://docs.vtk.org/en/latest/modules/vtk-modules/Rendering/OpenVR/README.html); I’m not sure why it isn’t packaged for Fedora.
Other than, maybe, that it’s obsolete. That doc says:
> The OpenVR standard has been succeeded by the industry-wide [OpenXR](https://www.khronos.org/openxr/) standard. See the VTK [OpenXR module](https://docs.vtk.org/en/latest/modules/vtk-modules/Rendering/OpenXR/README.html) for modernized support. The VTK `OpenVR` module is preserved for legacy support.
(…But Fedora doesn’t package vtkRenderingOpenXR either.)
Still, if there’s an OpenXR module available that _isn’t_ built weird, maybe you can switch to that?