Skip to content

Conversation

@ebluo
Copy link

@ebluo ebluo commented Sep 6, 2022

No description provided.

@gaussianrecurrence
Copy link

I think the issue you are facing for Windows compilation is the same as faced while trying to upgrade to Boost 1.79.0 in this PR #967
So, after looking into it, turns out, @moleske was in the right path, the issue has to do with _WIN32_WINNT and some issue with Boost&MSVC.
Thing is boost_log was being compiled with _WIN32_WINNT=0x0600, even if your compilation target is >=0x0A00 (Windows 10, Windows 2016, Windows 2017, Windows 2019), and on the other side, geode-native modules using boost_log had _WIN32_WINNT defined as 0x06020000 (which is a mistake btw, as, _WIN32_WINNT should fit in 16 bits, being 8 first for the major version and the 8 remaining for the minor version), causing boost_log to use boost::log::v2s_mt_nt62 namespace, but since boost_log was compiled with _WIN32_WINNT=0x0600, the only available symbols in libboost_log.lib are the ones pointing to boost::log::v2s_mt_nt6 namespace.

I've tested the fix with GH actions and seems to be working: Nordix@0aa3d70#diff-3971f6cd87e6fed8494466300f14922d1869759f063ffc6170da0542d386180c

In order to ensure that boost_log was compiled with _WIN32_WINNT it's needed to define BOOST_USE_WINAPI_VERSION=0x0602
And also, right now, we haven't seen any issue because of having set _WIN32_WINNT to the wrong value to the Boost lib interface, but it'd be good to have it set to the right value, _WIN32_WINNT=0x0602

- Add macro to fix linker errors.
@ebluo ebluo force-pushed the feature/GEODE-10416 branch from b2af24a to 80da89f Compare September 23, 2022 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants