Closed schorsch1976 closed 1 year ago
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
// 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?
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 ?
BOOST_MSSTL_VERSION is the version of the standard library, it's not related to the Windows SDK in use.
The problem here is probably https://github.com/boostorg/system/issues/111.
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.
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?
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?
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?
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.
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
): https://github.com/boostorg/system/commit/a57c5683243ceacc58ee5e3bdc806f189df44dac
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.
@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?
But you are compiling with toolset=msvc-14.2
, which is VS2019 (v142), not v141 (VS2017, toolset=msvc-14.1
.)
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.
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