file GET_RUNTIME_DEPENDENCIES in generated cmake_install.cmake fails to find dependencies

Code
1

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

  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:

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.

2

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.

3

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

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 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.