# file GET\_RUNTIME\_DEPENDENCIES in generated cmake\_install.cmake fails to find dependencies

**URL:** <https://discourse.cmake.org/t/file-get-runtime-dependencies-in-generated-cmake-install-cmake-fails-to-find-dependencies/12761>\
**Category:** Code\
**Tags:** os:linux\
**Created:** [October 11, 2024, 3:18pm UTC](https://discourse.cmake.org/t/file-get-runtime-dependencies-in-generated-cmake-install-cmake-fails-to-find-dependencies/12761 "2024-10-11T15:18:42Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Anton\_Kryukov](https://discourse.cmake.org/user_avatar/discourse.cmake.org/anton_kryukov/32/5011_2.png) [@Anton\_Kryukov](https://discourse.cmake.org/u/Anton_Kryukov)\
**Post date:** [October 11, 2024, 3:18pm UTC](https://discourse.cmake.org/t/file-get-runtime-dependencies-in-generated-cmake-install-cmake-fails-to-find-dependencies/12761/1 "2024-10-11T15:18:42Z")

</div>

I am trying to use `install(TARGETS...RUNTIME_DEPENDENCIES...)`  
with CMake 3.30 in an Ubuntu 14 Docker container. When I try to run the generated _cmake\_install.cmake_ file with `cmake -P`, I get an error

```auto
  file Could not resolve runtime dependencies:

    libboost_system.so.1.57.0
    libcrypto.so.3
    libssl.so.3

```

even though _ldd_ has no problems resolving everything correctly with or without `LDD_LIBRARY_PATH` being set. These libraries exist in custom (not system-wide) directories and the directories are listed in the `RUNPATH`. There are no complaints about other dependencies. One curious thing is that there are no complaints about other _boost_ library dependencies existing in the same directory as _libboost\_system_.  
I created a simple custom test.cmake script to just run `file(GET_RUNTIME_DEPENDENCIES...`) on a binary:

```cmake
file(GET_RUNTIME_DEPENDENCIES
    RESOLVED_DEPENDENCIES_VAR resolved
    UNRESOLVED_DEPENDENCIES_VAR unresolved
    CONFLICTING_DEPENDENCIES_PREFIX "con"
    EXECUTABLES ${EXECUTABLES}
    LIBRARIES ${LIBRARIES}
    PRE_EXCLUDE_REGEXES
      "^/lib/.*"
      "^/usr/.*"
    POST_EXCLUDE_REGEXES
      "^/lib/.*"
      "^/usr/.*"
)
message(STATUS "Resolved: \"${resolved}\"")
message(STATUS "Unresolved: \"${unresolved}\"")
message(STATUS "Conflicts: \"${con_FILENAMES}\"")

```

and when I run it specifying my executable, I get

> – Resolved: “…;/3rdparty/boost/lib/libboost\_filesystem.so.1.57.0;/3rdparty/boost/lib/libboost\_regex.so.1.57.0;/3rdparty/boost/lib/libboost\_system.so.1.57.0;/3rdparty/boost/lib/libboost\_thread.so.1.57.0;/3rdparty/openssl/lib/libcrypto.so.3;…;/3rdparty/openssl/lib/libssl.so.3;…”  
> – Unresolved: “libcrypto.so.3;libssl.so.3”  
> – Conflicts: “”

This is very confusing, as _libboost\_system_ is not in the Unresolved list, and _libssl_ and _libcrypto_ are both resolved and unresolved,  
Here is an excerpt from `objdump -p` run on the executable:

> Dynamic Section:  
> …  
> NEEDED libboost\_thread.so.1.57.0  
> …  
> NEEDED libboost\_filesystem.so.1.57.0  
> NEEDED libboost\_system.so.1.57.0  
> …  
> NEEDED libboost\_regex.so.1.57.0  
> NEEDED libssl.so.3  
> NEEDED libcrypto.so.3  
> …  
> RUNPATH …:/3rdparty/boost/lib:…:/3rdparty/openssl/lib:…

Any suggestions on how to get clarity on the cause of the problem and its solution are appreciated.

---

<div class="post-metadata">

**Author:** ![Anton\_Kryukov](https://discourse.cmake.org/user_avatar/discourse.cmake.org/anton_kryukov/32/5011_2.png) [@Anton\_Kryukov](https://discourse.cmake.org/u/Anton_Kryukov)\
**Post date:** [October 11, 2024, 10:31pm UTC](https://discourse.cmake.org/t/file-get-runtime-dependencies-in-generated-cmake-install-cmake-fails-to-find-dependencies/12761/2 "2024-10-11T22:31:33Z")

</div>

To complicate (or simplify?) matters further, if I add the `POST_EXCLUDE_FILES_STRICT` argument with the other dependencies (shared libs) that come from the same build, like in the generated `cmake_install.cmake`, `libboost_system` is also listed as both resolved and unresolved, just like Open SSL libraries. So it seems that it was not complaining about `libboost_system` before by recursively following the dependencies, not by examining information in the executable itself.

---

<div class="post-metadata">

**Author:** ![Anton\_Kryukov](https://discourse.cmake.org/user_avatar/discourse.cmake.org/anton_kryukov/32/5011_2.png) [@Anton\_Kryukov](https://discourse.cmake.org/u/Anton_Kryukov)\
**Post date:** [October 12, 2024, 12:37pm UTC](https://discourse.cmake.org/t/file-get-runtime-dependencies-in-generated-cmake-install-cmake-fails-to-find-dependencies/12761/3 "2024-10-12T12:37:44Z")

</div>

After much investigation and debugging CMake source code I decided that it’s a bug in CMake. The patch

```auto
diff --git a/Source/cmRuntimeDependencyArchive.cxx b/Source/cmRuntimeDependencyArchive.cxx
index 2fbf2fa04c..a8f9e05840 100644
--- a/Source/cmRuntimeDependencyArchive.cxx
+++ b/Source/cmRuntimeDependencyArchive.cxx
@@ -187,10 +187,18 @@ bool cmRuntimeDependencyArchive::GetRuntimeDependencies(
       return false;
     }
   }
- return std::all_of(
+ if(!std::all_of(
     modules.begin(), modules.end(), [this](std::string const& mod) -> bool {
       return this->Linker->ScanDependencies(mod, cmStateEnums::MODULE_LIBRARY);
- });
+ }))
+ {
+ return false;
+ }
+ for (auto const & resolved : ResolvedPaths)
+ {
+ UnresolvedPaths.erase(resolved.first);
+ }
+ return true;
 }

 void cmRuntimeDependencyArchive::SetError(const std::string& e)

```

fixed it for me, but it seems that the issue [was recently resolved](https://gitlab.kitware.com/cmake/cmake/-/merge_requests/9704) in CMake 3.31 in a different way. Although I think my solution is shorter and more logical and general, it would require additional testing on non-LinuxELF platforms. Alternatively, the unresolved path clean-up step could be put into a `cmBinUtilsLinker` virtual function if something different needs to be done on different platforms.  
For now upgrading CMake should solve my problem.