1.82.0: WinXP: Filesystem links to AcquireSRWLockExclusive

[schorsch1976]

Yes, i know. Its config and not filesystem.

I compiled boost 1.82.0 for Windows XP with MSVC 2019. It could not get it running on Win XP SP3 as the symbol AcquireSRWLockExclusive was missing. Then i checked boost-1.81.0 and it worked as expected. I bisected boost filesystem between 1.82.0 and 1.81.0 and found no good candidate as all other was still on 1.82.0. Then i bisected atomic and config between these two boost versions. I found 56e7a0e49ddb070f63e0943660f7dc6d00f2508c as the first bad commit.

56e7a0e49ddb070f63e0943660f7dc6d00f2508c is the first bad commit
commit 56e7a0e49ddb070f63e0943660f7dc6d00f2508c
Author: Peter Dimov <pdimov@gmail.com>
Date:   Wed Nov 9 02:14:43 2022 +0200

    Add macro BOOST_MSSTL_VERSION

 include/boost/config/stdlib/dinkumware.hpp | 30 ++++++++++++++++++++++++++++++
 test/config_info.cpp                       |  1 +
 2 files changed, 31 insertions(+)

commit 56e7a0e49ddb070f63e0943660f7dc6d00f2508c (HEAD, refs/bisect/bad)
Author: Peter Dimov <pdimov@gmail.com>
Date:   Wed Nov 9 02:14:43 2022 +0200

    Add macro BOOST_MSSTL_VERSION

commit 7b1f52c85eea58425d0b416f2eda03bbe47d27f1 (refs/bisect/good-7b1f52c85eea58425d0b416f2eda03bbe47d27f1)

But it does not fiddle with AcquireSRWLockExclusive, it fiddles with MSSTL.

When i do
git revert 56e7a0e49ddb070f63e0943660f7dc6d00f2508c
and recompile boost::filesystem it works again as expected.

I compiled it this way

SET ARCH=architecture=x86
SET INST=instruction-set=core2 

rem BOOST_WINAPI_VERSION_WINXP
SET WINAPI=0x501
SET JOBS=-j16

SET VCVARS32="C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars32.bat"
SET VCVARS64="C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\VC\Auxiliary\Build\vcvars64.bat"

.\b2 headers

rmdir /S /Q bin.v2 stage

rem call %VCVARS32%
b2 define=BOOST_USE_WINAPI_VERSION=%WINAPI% %ARCH% %INST% %JOBS% cxxstd=17 --toolset=msvc-14.2 address-model=32 variant=release debug-symbols=on filesystem

[schorsch1976]

I also tried something like that but it didn`t help

#if defined(_MSVC_STL_VERSION) && BOOST_USE_WINAPI_VERSION > 0x0501 // VS2017 (14.1) and above
#  define BOOST_MSSTL_VERSION _MSVC_STL_VERSION

#elif defined(_MSVC_STL_VERSION) && BOOST_USE_WINAPI_VERSION <= 0x0501 // VS2017 (on WinXP)
#  define BOOST_MSSTL_VERSION 140

[schorsch1976]

// BOOST_MSSTL_VERSION: as _MSVC_STL_VERSION, but for earlier releases as well
#if BOOST_USE_WINAPI_VERSION > BOOST_WINAPI_VERSION_WINXP
#if defined(_MSVC_STL_VERSION) // VS2017 (14.1) and above
#  define BOOST_MSSTL_VERSION _MSVC_STL_VERSION

#elif defined(_CPPLIB_VER) && _CPPLIB_VER >= 650 // VS2015 (14.0)
#  define BOOST_MSSTL_VERSION 140

#elif defined(_CPPLIB_VER) && _CPPLIB_VER >= 610 // VS2013 (12.0)
#  define BOOST_MSSTL_VERSION 120

#elif defined(_CPPLIB_VER) && _CPPLIB_VER >= 540 // VS2012 (11.0)
#  define BOOST_MSSTL_VERSION 110

#elif defined(_CPPLIB_VER) && _CPPLIB_VER >= 520 // VS2010 (10.0)
#  define BOOST_MSSTL_VERSION 100

#elif defined(_CPPLIB_VER) && _CPPLIB_VER >= 505 // VS2008SP1 (9.0)
#  define BOOST_MSSTL_VERSION 91

#elif defined(_CPPLIB_VER) && _CPPLIB_VER >= 503 // VS2008 (also 9.0)
#  define BOOST_MSSTL_VERSION 90

#elif defined(_CPPLIB_VER) && _CPPLIB_VER >= 405 // VS2005 (8.0)
#  define BOOST_MSSTL_VERSION 80

#endif
#endif

This helped but is it the right solution?

[jzmaddock]

I'm not sure what the right fix is or where it should go, but IMO it shouldn't be here, BOOST_MSSTL_VERSION should completely unrelated to the WinAPI version in effect. @pdimov ?

[pdimov]

BOOST_MSSTL_VERSION is the version of the standard library, it's not related to the Windows SDK in use.

[pdimov]

The problem here is probably #111.

[pdimov]

Basically, the issue is that while the v140_xp toolset defines the macro _USING_V110_SDK71_, which tells the MS STL to not try to use SRWLOCK, the v141_xp toolset does not, and you have to define it yourself.

[schorsch1976]

With the v140_xp toolset SRWLOCK will never be available as its target is WinXP. So: Should _USING_V110_SDK71_ not be defined by the config?

[jzmaddock]

It shouldn't be defined by us if that's what you're asking: it should really be defined by your toolset when you target XP, or failing that by yourself on the command line. Which is to say defines which control the behaviour of the Windows SDK are none of our business, and Boost should expect them to be set in a sane way, which apparently is not the case here?

[schorsch1976]

I build boost filesystem 1.82.0 with this commandline but it was not fixed. Still there.

b2 define=_USING_V110_SDK71_ define=BOOST_USE_WINAPI_VERSION=0x501 architecture=x86 instruction-set=core2 -j16 cxxstd=17 --toolset=msvc-14.2 address-model=32 variant=release debug-symbols=on filesystem

Any suggestion how to fix compilation for Windows XP without reverting that patch?

[pdimov]

The problem here is that msvc-14.2 (VS2019) no longer supports XP (there's no vc142_xp toolset and the MS STL no longer has the XP workarounds), so the _USING_V110_SDK71_ macro doesn't do anything. It works with toolset=msvc-14.1.

But I'll look into fixing this on the System side.

[pdimov]

This commit will fix the compilation with msvc-14.2 under Windows XP using the command line above (except filesystem should probably be --with-filesystem): a57c568

I'm still not quite sure whether msvc-14.2 can reliably be used to target XP, because that's (officially) unsupported; but if this works for you, I'll incorporate it after your confirmation.

[schorsch1976]

@pdimov That fixed my issue!

About the toolset issue: What confused me: In visual studio there is a special toolset v141_xp. It is distinct from v141.
https://learn.microsoft.com/en-us/cpp/build/configuring-programs-for-windows-xp?view=msvc-170
That is not available in boost. Add that toolset to boost.build? Maybe that would be better?

[pdimov]

But you are compiling with toolset=msvc-14.2, which is VS2019 (v142), not v141 (VS2017, toolset=msvc-14.1.)