2

I'm trying to add spdlog 1.9.0 to my CMake project, and for this project I'm using VS2019's new CMake-based project system for building/running it. When I include spdlog in my implementation using a very simple invocation, I get a linker error when I try to build.

#include <spdlog/spdlog.h>

App::App() :
    m_win(0) {
    if (SDL_Init(SDL_INIT_EVERYTHING) != 0) {
        spdlog::error("Failed to initialize SDL");
    }
}

The linker errors are as follows:

Error   LNK2038 mismatch detected for 'RuntimeLibrary': value 'MD_DynamicRelease' doesn't match value 'MDd_DynamicDebug' in App.cpp.obj 
Error   LNK2038 mismatch detected for '_ITERATOR_DEBUG_LEVEL': value '0' doesn't match value '2' in App.cpp.obj 

The errors are repeated a few (4, to be exact) times.

Seems like spdlog was built/deployed to conan's repository using one set of RuntimeLibrary settings and I'm using a different one? Is there anything I can do about that?

Here's some more data on my setup:

conanfile.txt

[requires]
sdl/2.0.14
spdlog/1.9.0

[generators]
cmake

CMakeLists.txt

cmake_minimum_required(VERSION 2.8.12)

project(my_project)

include(conanbuildinfo.cmake)
conan_basic_setup()

file(GLOB source_files
    "src/App.h"
    "src/App.cpp"
)

add_executable (${PROJECT_NAME} ${source_files})

# Compilers don't understand the different standards so
# we need to set them ourselves in various cases.
if(MSVC)
    add_compile_options("/std:c++17")
    set_property(TARGET ${PROJECT_NAME}
        PROPERTY MSVC_RUNTIME_LIBRARY "MultiThreaded$<$<CONFIG:Debug>:Debug>")
endif()

conan_target_link_libraries(${PROJECT_NAME} ${CONAN_LIBS})
Brad Heller
  • 95
  • 1
  • 6
  • 1
    When you do the ``conan install`` to install dependencies, you will see the "profile" being used to install binaries, including settings like ``build_type``, ``compiler.version``, etc. This should match the configuration you are using for building, if building for debug, you should use something like ``conan install . -s build_type=Debug``. For Visual Studio multi-configuration, you could use more modern generators like ``CMakeDeps``. – drodri Jul 24 '21 at 09:15
  • That was the issue! I changed the build type as you described and it compiled just fine. Thank you! – Brad Heller Jul 24 '21 at 09:25
  • Ok, good, then I'll post the comment as answer :) – drodri Jul 25 '21 at 22:21

1 Answers1

1

When you do the conan install to install dependencies, you will see the "profile" being used to install binaries, including settings like build_type, compiler.version, etc. something like this:

Configuration:

[settings]
arch=x86_64
arch_build=x86_64
build_type=Release
compiler=Visual Studio
compiler.runtime=MD
compiler.version=16
os=Windows
os_build=Windows

This should match the configuration you are using for building, if building for debug, you should use something like

conan install . -s build_type=Debug

It is also possible to define more profile files (and it is the recommended approach for production).

The important piece is that when doing conan install conan will use the provided or the default profile to define which binaries will be downloaded (if matching binaries exist for that configuration). It is important to provide the same configuration that is going to be used for building your project later, otherwise binary incompatibilities like the above can happen (or other, more subtle incompatibilities, that could also happen at runtime).

As a side note, for Visual Studio multi-configuration, you could use more modern generators like the CMakeDeps one.

drodri
  • 5,157
  • 15
  • 21