[boost-log:x64-windows] possible port degradation from 1.75 to 1.78

[ssh4net]

Describe the bug
Installed boost-log:x64-windows generate compilation error in VS:
Error LNK2038 mismatch detected for 'boost_log_abi': value 'v2_mt_nt62' doesn't match value 'v2_mt_nt6' in ****.obj **** ***\ImageUtils.obj 1

Environment

• OS: Windows 10 Pro
• Compiler: VS2019

To Reproduce
Steps to reproduce the behavior:

1. ./vcpkg install boost-log:x64-windows
2. try to compile existing project that use boost-log
3. See error

Expected behavior
v 1.75 do not have this issue.

Additional context
from 1.78 boost changelog:
On Windows, when building the library for Windows 8 or later, the library will use nt62 tag in the version namespace to denote the target OS ABI. For example, the version namespace could be named as v2_mt_nt62. This name will be part of all symbols exported by the library. Use the BOOST_USE_WINAPI_VERSION macro consistenly when building Boost and your code to request the minimum target Windows version.

Sound like boot-log port missed mandatory for correct build macro.

[PhoebeHui]

@ssh4net, thanks for reporting this issue! could you please share the repro code with us, or a project to help us repro this issue quickly?

[ssh4net]

Sorry, can't share code or project. And not skilled too much to make minimal possible from existing code that reproduce this bug.

But my coder gave me temporary fix for issue
compiling project with this option:
-DBOOST_USE_WINAPI_VERSION=BOOST_WINAPI_VERSION_WIN7

looks like this is a bug in Boost itself

[MarcelNehring]

I saw this issue while looking for a solution for what looks like this exact problem.
This isn't really a minimal example but I hope it suffices to analyze the issue further.

Building this code fails for me as soon as I define _WIN32_WINNT to target Windows 8 or later.
As @ssh4net and the boost changelog already mentioned defining BOOST_USE_WINAPI_VERSION to BOOST_WINAPI_VERSION_WIN7 also fixes the linker errors.

// Setting this to 0x0602 (Windows 8) or higher will cause linking to fail.
// It works with 0x0601 (Windows 7).
#define  _WIN32_WINNT   0x0602

// Uncomment this to fix linker errors independent of targeted Windows version.
//#define BOOST_USE_WINAPI_VERSION BOOST_WINAPI_VERSION_WIN7

#include <boost/log/sources/logger.hpp>
#include <boost/log/sources/record_ostream.hpp>
#include <boost/log/sources/global_logger_storage.hpp>
#include <boost/log/sources/severity_logger.hpp>

enum class LogLevel
{
    LEVEL_DEBUG,
    LEVEL_ERROR
};

BOOST_LOG_INLINE_GLOBAL_LOGGER_DEFAULT(MyLogger, boost::log::sources::severity_logger_mt<LogLevel>)

#define LOGGER(lvl) BOOST_LOG_SEV(MyLogger::get(), lvl)

int main()
{
    LOGGER(LogLevel::LEVEL_DEBUG) << "Hello World!\n";
}

[PhoebeHui]

@MarcelNehring, thanks for the example code! it seems Upstream by design issue, relate to boostorg/log#172.

BOOST_USE_WINAPI_VERSION is defined to BOOST_WINAPI_VERSION_WIN7 by default, and _WIN32_WINNT and WINVER are defined in boost-winapi header[1], which value is BOOST_WINAPI_VERSION_WIN7[2], that cause conflicts when user define these two macros in their custom project. Do you have any ideas to handle this case? cc @yurybura @Kojoley @strega-nil-ms @BillyONeal

[1] https://github.com/boostorg/winapi/blob/develop/include/boost/winapi/config.hpp#L214-L219

#if !defined(_WIN32_WINNT)
#define _WIN32_WINNT BOOST_USE_WINAPI_VERSION
#endif
#if !defined(WINVER)
#define WINVER BOOST_USE_WINAPI_VERSION
#endif

[2] https://github.com/boostorg/winapi/blob/develop/include/boost/winapi/config.hpp#L105-L120

#if !defined(BOOST_USE_WINAPI_VERSION)
#if defined(_WIN32_WINNT)
#define BOOST_USE_WINAPI_VERSION _WIN32_WINNT
#elif defined(WINVER)
#define BOOST_USE_WINAPI_VERSION WINVER
#else
// By default use Windows 7 API on compilers that support it and Vista or XP on the others
#if (defined(_MSC_VER) && _MSC_VER < 1500) || defined(BOOST_WINAPI_IS_MINGW)
#define BOOST_USE_WINAPI_VERSION BOOST_WINAPI_VERSION_WINXP
#elif (defined(_MSC_VER) && _MSC_VER < 1600)
#define BOOST_USE_WINAPI_VERSION BOOST_WINAPI_VERSION_WIN6
#else
#define BOOST_USE_WINAPI_VERSION BOOST_WINAPI_VERSION_WIN7
#endif
#endif
#endif

[Kojoley]

Do I understand correctly that you install boost-log via vcpkg, then in your code that uses boost-log you define _WIN32_WINNT to some value (and which differs from one boost-log would guess, or you had supplied to vcpkg explicitly) - you are getting a linkage error?

[MarcelNehring]

@Kojoley yes that is correct.

I have not tried it yet but you could probably install boost-log while setting _WIN32_WINNT to the desired value using VCPKG_CXX_FLAGS in a custom triplet and thus get a matching boost-log version that does not produce linker errors.

[Kojoley]

Obviously vcpkg couldn't know which Windows version you want to target if you haven't tell that to it.
@PhoebeHui maybe a warning could be added when boost-log is installed telling that it will be built using a default _WIN32_WINNT value?

[BillyONeal]

I don't think we need a specific-to-vcpkg answer here. Triplets already let you set _WIN32_WINNT.

[johnco3]

I also have the above linkage issue. Boost-Log frequently has porting issues that could easily be flushed out prior to pushing the port - I remember having to manually patch boost headers a few releases ago when I used to download the binaries & prebuilt headers from the boost.org website. This was prior to making the switch to building boost using vcpkg & triplets - (in my case x64-windows). I thought this would make upgrading to the latest versions of boost (in particular boost-log) a bit easier - unfortunately I was wrong. I was able to work around the issue by setting a common preprocessor setting _WIN32_WINNT=0x0601 for all of my projects - not just the executable that performs the linkage. I would prefer not to force the older Windows 7 API - but there you go. I wish I knew how to make a local git patch to work around this problem - now I have to remember to remove the _WIN32_WINNT=0x0601 at some later date when boost finally gets around to fixing the issue.