Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The build failed because of a runtime libraries incompatibility #774

Closed
artiomn opened this issue Jul 3, 2024 · 4 comments
Closed

The build failed because of a runtime libraries incompatibility #774

artiomn opened this issue Jul 3, 2024 · 4 comments

Comments

@artiomn
Copy link
Contributor

artiomn commented Jul 3, 2024

@rdementi , why do you added /MT$<$<CONFIG:Debug>:d> in the CMakeLists?

It breaks builds with another types of runtime and doesn't work in the most cases, due to library incompatibility.
If I comment out the two lines with target_compile_options, the library and my project are built successfully.

Could you remove this options?

    target_compile_options(PCM_STATIC PRIVATE "/MT$<$<CONFIG:Debug>:d>")

    # Graphical perfmon front-end: pcm-lib, pcm-service
    # Files: COMMON_FILES() + pcm-lib.cpp winpmem\winpmem.cpp dllmain.cpp
    file(GLOB PCM_LIB_SOURCES winpmem/winpmem.cpp dllmain.cpp pcm-lib.cpp )
    add_library(pcm-lib SHARED ${COMMON_SOURCES} ${PCM_LIB_SOURCES})
    target_compile_definitions(pcm-lib PRIVATE _WINDOWS _USRDLL PCM_EXPORTS _WINDLL _UNICODE UNICODE)

    target_compile_options(pcm-lib PRIVATE "/MT$<$<CONFIG:Debug>:d>")

P.S.: It's incorrect to use compiler options to specify runtime: CMake has built-in variables and properties for it, but libraries should not to use this.

@rdementi
Copy link
Contributor

rdementi commented Jul 3, 2024

Thanks for the suggestion. The change was introduced to reduce the risks of DLL hijacking.

Would you be able to submit a pull request with a CMakeLists.txt change to specify the runtime using the built-in variables and properties?

@artiomn
Copy link
Contributor Author

artiomn commented Jul 3, 2024

Perhaps reducing the risk of DLL hijacking is the responsibility of the application developer?

Several compilers. I'm porting framework to Windows from Linux.
Ideally, I should not specify runtime, and everything should be built "out of the box", like in Linux.

But neither MSVS 19 nor MSVS 2022 was able to build due to linking errors.

And I must to set only static MT runtime to build.

This gives rise to several problems:

  • It's difficult.
  • Using this runtime generates errors when deleting objects (I don't want to debug this).
  • I cannot use pre-built libraries, were built with a different runtime.

I just commented lines with target_compile_options(PCM_STATIC PRIVATE "/MT$<$<CONFIG:Debug>:d>").

Correct "CMake-style way" to change runtime is using MSVC_RUNTIME_LIBRARY property, i.e.:

if (MSVC)  # AND ($<COMPILE_LANGUAGE> STREQUAL CXX OR $<COMPILE_LANGUAGE> STREQUAL C))
        set_property(TARGET "${target}" PROPERTY MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>DLL")
    endif()

And variable to set runtime: set(CMAKE_MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>DLL").

But, please, don't specify runtime in the library.

@rdementi
Copy link
Contributor

rdementi commented Jul 3, 2024

thanks for the recipe. We will evaluate it. As a work-around we can offer a new -DNO_STATIC_MSVC_RUNTIME_LIBRARY=1 option which you can use with cmake when compiling pcm.

@artiomn
Copy link
Contributor Author

artiomn commented Jul 3, 2024

Thank you. It's better than nothing. But if you have a real reason to set the runtime library (like formal SDL requirements), perhaps in the future it would be better to add an option where the user can set an arbitrary runtime?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants