Stati c связь исполняемого файла с CMAKE_MSVC_RUNTIME_LIBRARY в Visual Studio 2019 - PullRequest
Новая
       102

Stati c связь исполняемого файла с CMAKE_MSVC_RUNTIME_LIBRARY в Visual Studio 2019

1 голос
/ 28 апреля 2020

Я использую опцию CMAKE_MSVC_RUNTIME_LIBRARY , чтобы MSV C использовал /MTd для статической ссылки исполняемого файла.

CMakeLists.txt 

    cmake_minimum_required (VERSION 3.15 FATAL_ERROR)
    cmake_policy(SET CMP0091 NEW)
    set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")

    project ("cmaketoy")

    find_package(GDAL REQUIRED)
    add_executable (cmaketoy "cmaketoy.cpp" )
    target_include_directories(cmaketoy PUBLIC ${GDAL_INCLUDE_DIR})
    target_link_libraries(cmaketoy PRIVATE ${GDAL_LIBRARY})

cmaketoy. cpp

#include <iostream>
#include "gdal_priv.h"

int main() {
    std::cout << "Hello CMake.\n";
    GDALAllRegister();
    return 0;
}

CMakeSettings. json (спецификация Visual Studio c конфигурация) 

{
    "configurations": [
        {
            "name": "x64-Debug",
            "generator": "Ninja",
            "configurationType": "Debug",
            "inheritEnvironments": [ "msvc_x64_x64" ],
            "buildRoot": "${projectDir}\\out\\build\\${name}",
            "installRoot": "${projectDir}\\out\\install\\${name}",
            "cmakeCommandArgs": "",
            "buildCommandArgs": "-v",
            "ctestCommandArgs": "",
            "environments": [
                { "GDAL_ROOT": "C:\\OSGeo4W64" }
            ]
        }
    ]
}

Вывод компилятора подтверждает, что используется опция MTd: 

  [1/2] "C:\PROGRA~2\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\bin\HostX64\x64\cl.exe"  
/nologo /TP  -IC:\OSGeo4W64\include /DWIN32 /D_WINDOWS /GR /EHsc /Zi /Ob0 /Od /RTC1 -MTd 
/showIncludes /FoCMakeFiles\cmaketoy.dir\cmaketoy.cpp.obj /FdCMakeFiles\cmaketoy.dir\ /FS -c ..\..\..\cmaketoy.cpp

  [2/2] cmd.exe /C "cd . && "C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" 
-E vs_link_exe --intdir=CMakeFiles\cmaketoy.dir --rc="C:\PROGRA~2\Windows Kits\10\bin\10.0.18362.0\x64\rc.exe" 
--mt="C:\PROGRA~2\Windows Kits\10\bin\10.0.18362.0\x64\mt.exe" --manifests  -- "C:\PROGRA~2\Microsoft Visual Studio\2019\Community\VC\Tools\MSVC\14.25.28610\bin\Hostx64\x64\link.exe" 
/nologo CMakeFiles\cmaketoy.dir\cmaketoy.cpp.obj  /out:cmaketoy.exe /implib:cmaketoy.lib /pdb:cmaketoy.pdb 
/version:0.0  /machine:x64 /debug /INCREMENTAL /subsystem:console  
C:\OSGeo4W64\lib\gdal_i.lib  kernel32.lib user32.lib gdi32.lib winspool.lib 
shell32.lib ole32.lib oleaut32.lib uuid.lib comdlg32.lib advapi32.lib && cd ."

Но когда я запускаю exe, он пытается найти gdal300.dll, которого нет на PATH, и завершается с 

The program '[19452] cmaketoy.exe' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.

Какие изменения необходимы для создания автономного статически связанного исполняемого файла?

Обновление

Копаем еще, эта проблема не указана c CMake, но скорее относится к тому, как библиотека GDAL встроена в OS4GeoW . Я получаю ту же проблему, используя обычное решение Visual Studio без CMake.

Я предполагал, что мог бы статически связываться с gdal_i.lib, чтобы создать автономный исполняемый файл, но dumpbin /symbols gdal_i.lib - это просто библиотека-заглушка, которая сопровождает gdal300.dll ( см. Здесь ) 

001 00000000 SECT2  notype       External     | __IMPORT_DESCRIPTOR_gdal300

См. Также этот ответ о двух типах .lib файла.

...