diff options
author | Alex Merry <alex.merry@kde.org> | 2014-11-14 18:20:50 +0000 |
---|---|---|
committer | Alex Merry <alex.merry@kde.org> | 2014-11-14 18:20:50 +0000 |
commit | 3f1020ca0ae58dbfd43169a691313116898647d5 (patch) | |
tree | a74a0df5f3382908843a6c8e41b158b4adeb4584 | |
parent | e92da3387bdca560074656b65e3367f9c4086d4c (diff) | |
download | extra-cmake-modules-1.5.0-rc1.tar.gz extra-cmake-modules-1.5.0-rc1.tar.bz2 |
Update the comments about the default lib MSVC hacksv1.5.0-rc1v1.5.0
Having done a lot of (unrelated) Windows development recently, I've come
to understand the situation much better, so I'm recording that
information here for the benefit of others.
-rw-r--r-- | kde-modules/KDECompilerSettings.cmake | 28 |
1 files changed, 19 insertions, 9 deletions
diff --git a/kde-modules/KDECompilerSettings.cmake b/kde-modules/KDECompilerSettings.cmake index b5a9d423..aa0249d9 100644 --- a/kde-modules/KDECompilerSettings.cmake +++ b/kde-modules/KDECompilerSettings.cmake @@ -396,20 +396,30 @@ endif() if (WIN32) if (MSVC OR "${CMAKE_CXX_COMPILER_ID}" STREQUAL "Intel") - # Make sure that no header adds libcmt by default using - # #pragma comment(lib, "libcmt.lib") as done by mfc/afx.h - # Error message this fixes: + # MSVC has four incompatible C runtime libraries: static (libcmt), + # static debug (libcmtd), shared (msvcrt) and shared debug (msvcrtd): + # see http://support.microsoft.com/kb/154753 + # + # By default, when you create static libraries, they are automatically + # linked against either libcmt or libcmtd, and when you create shared + # libraries, they are automatically linked against either msvcrt or + # msvcrtd. Trying to link to both a library that links to libcmt and + # library that links to mscvrt, for example, will produce a warning as + # described at + # http://msdn.microsoft.com/en-us/library/aa267384%28VS.60%29.aspx + # and can produce link errors like # "__thiscall type_info::type_info(class type_info const &)" # (??0type_info@@AAE@ABV0@@Z) already defined in LIBCMT.lib(typinfo.obj) - # See http://msdn.microsoft.com/en-us/library/aa267384%28VS.60%29.aspx - # and http://support.microsoft.com/kb/154753 - # FIXME: is this still an issue with Visual Studio 2010 and later? + # + # It is actually the options passed to the compiler, rather than the + # linker, which control what will be linked (/MT, /MTd, /MD or /MDd), + # but we can override this by telling the linker to ignore any "libcmt" + # or "libcmtd" link suggestion embedded in the object files, and instead + # link against the shared versions. That way, everything will link + # against the same runtime library. set(CMAKE_EXE_LINKER_FLAGS_RELEASE "/NODEFAULTLIB:libcmt /DEFAULTLIB:msvcrt ${CMAKE_EXE_LINKER_FLAGS_RELEASE}") set(CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO "/NODEFAULTLIB:libcmt /DEFAULTLIB:msvcrt ${CMAKE_EXE_LINKER_FLAGS_RELWITHDEBINFO}") set(CMAKE_EXE_LINKER_FLAGS_MINSIZEREL "/NODEFAULTLIB:libcmt /DEFAULTLIB:msvcrt ${CMAKE_EXE_LINKER_FLAGS_MINSIZEREL}") - # use the debug versions of the libraries for debug builds - # if we just set /NODEFAULTLIB:libcmt /DEFAULTLIB:msvcrt unconditionally in CMAKE_EXE_LINKER_FLAGS we end up - # linking to the debug and the release C runtime at the same time which will cause crashes set(CMAKE_EXE_LINKER_FLAGS_DEBUG "/NODEFAULTLIB:libcmtd /DEFAULTLIB:msvcrtd ${CMAKE_EXE_LINKER_FLAGS_DEBUG}") endif() endif() |