[ginkgo] Fix build error on x64-windows-static

[JonLiu1993]

Fixes #35065
Fix error:

warning: The following binaries should use the Static Debug (/MTd) CRT.
  G:\v\vcpkg2\packages\ginkgo_x64-windows-static\debug\lib\ginkgo_cudad.lib links with: Dynamic Debug (/MDd)
To inspect the lib files, use:
  dumpbin.exe /directives mylibfile.lib
warning: The following binaries should use the Static Release (/MT) CRT.
  G:\v\vcpkg2\packages\ginkgo_x64-windows-static\lib\ginkgo_cuda.lib links with: Dynamic Release (/MD)
To inspect the lib files, use:
  dumpbin.exe /directives mylibfile.lib
error: Found 2 post-build check problem(s). To submit these ports to curated catalogs, please first correct the portfile: G:\v\vcpkg2\ports\ginkgo\portfile.cmake
error: building ginkgo:x64-windows-static failed with: POST_BUILD_CHECKS_FAILED

• Changes comply with the maintainer guide
• SHA512s are updated for each updated download
• The "supports" clause reflects platforms that may be fixed by this new version
• Any fixed CI baseline entries are removed from that file.
• Any patches that are no longer applied are deleted from the port's directory.
• The version database is fixed by rerunning ./vcpkg x-add-version --all and committing the result.
• Only one version is added to each modified port's versions file.

[dg0yt]

Doesn't the toolchain already care for these flag? Where do they get lost in gingko?

[JonLiu1993]

Yes, the toolchain already care for these flag:

    if(VCPKG_CRT_LINKAGE STREQUAL "dynamic")
        set(VCPKG_CRT_LINK_FLAG_PREFIX "/MD")
    elseif(VCPKG_CRT_LINKAGE STREQUAL "static")
        set(VCPKG_CRT_LINK_FLAG_PREFIX "/MT")
    else()

If feature cuda is not enabled it does not have this error, but if feature cuda is enabled it will occur, so I think it is the following code in cuda CMakeLists that is affected.

target_compile_options(ginkgo_cuda PRIVATE $<$<COMPILE_LANGUAGE:CUDA>:${GINKGO_CUDA_COMPILER_FLAGS}>)
target_compile_options(ginkgo_cuda PRIVATE $<$<COMPILE_LANGUAGE:CXX>:${GINKGO_COMPILER_FLAGS}>)

[dg0yt]

I don't know much about CUDA, but I see that it is treated as a separate language CUDA in CMake. Does the project need CMAKE_CUDA_FLAGS_<config>?

[JonLiu1993]

To be honest, I don’t know much about CUDA, so I can’t mislead you.

[dg0yt]

It is probably not the language stuff but the CUDA link libs incl. runtime
https://github.com/ginkgo-project/ginkgo/blob/fa719901970dea8aff3925dd9fcab94fe1d46ec3/cuda/CMakeLists.txt#L126
Here we see CUDA::cudart but it might need CUDA::cudart_static, etc. Cf.
https://cmake.org/cmake/help/v3.20/module/FindCUDAToolkit.html?highlight=cudart#cuda-toolkit-rt-lib

[data-queue]

I think we need to investigate the actual cause before merging. Converting the PR to draft.

[upsj]

Tagging along, cudart_static is likely the right solution, though it's annoying that this can't be handled by CMake itself. We don't really test CUDA static builds due to the storage requirements breaking Github Action limits.

Generally, if you loop in upstream maintainers to these discussions, we can help resolve these issues more quickly ;)