GET_RUNTIME_DEPENDENCIES does not seem to work with MinGW

Usage
,
1

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.

2

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

3

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.

4

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.