GET_RUNTIME_DEPENDENCIES does not seem to work with MinGW

Hi,

Using arch linux with MinGW and cmake 3.19. The following code works on Windows / MSVC / cmake version 3.18.20081302-MSVC_2, but on MinGW does not find any dependencies at all. mylib is a shared library. On Windows CMake seems to use dumpbin, on MinGW it uses objdump.

    install(CODE [[
        message(STATUS "Looking for deps in ${CMAKE_SYSTEM_LIBRARY_PATH};${CMAKE_MINGW_SYSTEM_LIBRARY_PATH}")
        file(GET_RUNTIME_DEPENDENCIES
            RESOLVED_DEPENDENCIES_VAR deps_resolved
            UNRESOLVED_DEPENDENCIES_VAR deps_unresolved
            LIBRARIES $<TARGET_FILE:mylib>
            DIRECTORIES ${CMAKE_SYSTEM_LIBRARY_PATH} ${CMAKE_MINGW_SYSTEM_LIBRARY_PATH} 
            PRE_EXCLUDE_REGEXES "api-ms-*" "ext-ms-*"
            POST_EXCLUDE_REGEXES ".*system32/.*\\.dll"
            )
        message(STATUS "Resolving runtime dependencies for $<TARGET_FILE:mylib>")
        foreach(dep ${deps_resolved})
            file(INSTALL ${dep} DESTINATION ${CMAKE_INSTALL_PREFIX})
        endforeach()
        foreach(dep ${deps_unresolved})
            message(WARNING "Runtime dependency ${dep} could not be resolved.")
        endforeach()
        ]])

The variable CMAKE_MINGW_SYSTEM_LIBRARY_PATH is defined using install(CODE "set(CMAKE_MINGW_SYSTEM_LIBRARY_PATH \"${CMAKE_FIND_ROOT_PATH}/bin/\")") and points to the correct path on my system which is /usr/x86_64-w64-mingw32/bin.

if I manually do objdump i do get back some deps (although not recursive so not complete):

$ objdump -x mylib.dll | grep DLL
        DLL
 vma:            Hint    Time      Forward  DLL       First
        DLL Name: libgcc_s_seh-1.dll
        DLL Name: KERNEL32.dll
        DLL Name: msvcrt.dll
        DLL Name: libstdc++-6.dll
        DLL Name: libopenlibm.dll
        DLL Name: libceres.dll
        DLL Name: libglog.dll

So in short, works on Windows 10, doesn’t work on Arch/MinGW. Any ideas what might be going on here? Thanks.

These look like globs. You want regexes (though these are valid regexes, they’re not exactly what you might think they are).

We don’t want recursive dependencies in our process.

I suspect our logic needs updated for MinGW support. Please file an issue asking for support.

Cc: @kyle.edwards

We don’t want recursive dependencies in our process.

I see, what I meant was that I don’t get the indirect dependencies, which are also necessary (for example mylib -> libceres.dll -> libopenblas.dll.

These look like globs. You want regexes (though these are valid regexes, they’re not exactly what you might think they are).

True, I just checked if the outcome was what I expected.

Please file an issue asking for support.

Thanks, I will file an issue at https://gitlab.kitware.com/cmake/cmake/-/issues.

We do the recursion on our own so that the various {IN,EX}CLUDE_REGEXES can apply at every step of the process.

Thanks, I see this issue.