conan: [bug] 'Visual Studio' settings are incorrect.

To date there are following settings for ‘Visual Studio’ compiler:

compiler:
    Visual Studio: &visual_studio
        runtime: [MD, MT, MTd, MDd]
        version: ["8", "9", "10", "11", "12", "14", "15", "16"]
        toolset: [None, v90, v100, v110, v110_xp, v120, v120_xp,
                  v140, v140_xp, v140_clang_c2, LLVM-vs2012, LLVM-vs2012_xp,
                  LLVM-vs2013, LLVM-vs2013_xp, LLVM-vs2014, LLVM-vs2014_xp,
                  LLVM-vs2017, LLVM-vs2017_xp, v141, v141_xp, v141_clang_c2, v142]
        cppstd: [None, 14, 17, 20]

The item runtime: should have the following values: [dynamic, static]

The reasons:

You can not use flags MDd, MTd in release builds (and vice versa):

There is the special warning for this case - https://docs.microsoft.com/en-us/cpp/error-messages/tool-errors/linker-tools-warning-lnk4098?view=vs-2019
The docs clearly stated

https://docs.microsoft.com/en-us/cpp/c-runtime-library/crt-library-features?view=vs-2019 To build a debug version of your application, the _DEBUG flag must be defined and the application must be linked with a debug version of one of these libraries.

Debug libraries use special version of memory allocation functions, and mixing them with release version is not a good idea - https://docs.microsoft.com/en-us/visualstudio/debugger/debug-versions-of-heap-allocation-functions?view=vs-2019

About this issue

Original URL
State: closed
Created 4 years ago
Reactions: 1
Comments: 19 (11 by maintainers)

Most upvoted comments

Don’t get me wrong. I am not against your proposal - I’ve even written that in my original comment in other thread:

Although I completely agree with your statement for the general conan default, please don’t prevent advanced users to still use the “unnatural combinations” as described above 😛

I just don’t want to be prevented from doing my “optimized debug builds”, as you call it. I’m perfectly fine with having [dynamic, static] option instead of [MD, MDd, MT, MTd], but I do have some questions about those:

eventually, msvc compiler needs to get one of the /MD /MDd /MT /MTd flags - who and where will make the conversion from static/dynamic to those flags?
what rules will it follow? I guess it’s easy to use MDd/MTd for Debug and MD/MT for Release, but what about RelWithDebugInfo?
what about custom build types that people add to their settings.yml?
should we add some kind of callback to let people choose if their custom build type should use debug or non-debug version of MSVC runtime library?
or is that something that new toolchains should handle?
should conan probably drop support for custom build types other than Debug, Release, RelWithDebugInfo and MinSizeRelease? I would be definitely against such a proposal

In general, I like the simplicity of static/dynamic very much - it’s much more clear, especially to beginners. But, eventually, someone needs to answer the questions above.

I’m OK with having some custom sub-settings, like current MD/MDd/MT/MTd in my own version of settings.yml if I add custom build types to the very same settings.yml - I just don’t want conan to prevent me from doing that, while still being simple, as you suggested, for most people out there that don’t need such fine-grained control.

DoDoENT on Dec 14, 2020

@DmitrySokolov , nothing prevents you to compile your code in release mode and link it with MDd or MTd. You just need to make sure to define _DEBUG flag so that correct runtime functions will be called. However, you are free to compile your code with optimizations (/Ox, /Oy, /Os and /Ot flags). We are actually regularly doing so in our development (we call that a dev-release build, as it contains all runtime checks as the debug build, but has optimizations of our code enabled, making it much faster).

Of course, you must not mix the object files/static libraries built against MD and MDd (or MT and MTd) in the same final binary (DLL or exe), as those two are not compatible.

DoDoENT on Dec 14, 2020