Add windows support#231
Conversation
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline and AI policy for information on the review process. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. LLM Linter (✨ experimental)Possible typos and grammar issues:
2026-07-17 13:45:25 |
|
We have miners using Stratum V2 that are on Windows and would like to see Windows IPC support landing, is there any estimate when they can expect this to materialize? We have a dozen of users who can help with testing if that's a blocker. |
|
@pavlenex testing would definitely be useful. I guess for that to work we'd need a stack of pull requests: this one here in libmultiprocess, one in Bitcoin Core that enables IPC support in the Windows Guix build, and then an SRI pull request that uses it. Testers would then have download (or build themselves) the custom bitcoin core and SRI binaries. I've added Windows support to my v32 wish list: bitcoin/bitcoin#33777 No guarantees obviously. |
|
I'll try to get this PR ready for review this week, split up into smaller commits and with ci passing. From there as Sjors mentioned there is a lot more work to do: more code changes in bitcoin/bitcoin#32387 that need to be made in bitcoin core, enabling IPC into windows builds in bitcoin core, enabling it in windows CI jobs with pycapnp, adding client support, probably adding a windows CI job to this repository. v32 sounds like a good target though and it is very useful to know there is demand for this feature, because it hasn't been a priority so far |
|
PR is split up into commits now and should be reviewable. CI is not passing but failures look like IWYU errors. I also opened bitcoin/bitcoin#35084 with corresponding bitcoin core changes. Windows support for bitcoin core can be tested with bitcoin/bitcoin#32387 which combines both PRs and enables IPC by default in windows builds. Rebased 2975fac -> cb16d2e ( Updated cb16d2e -> e563c96 ( Updated e563c96 -> d9fcac6 ( Added 1 commits d9fcac6 -> a1748e2 ( Updated a1748e2 -> 18fc188 ( Updated 18fc188 -> 7fd5ec4 ( |
e563c96 to
d9fcac6
Compare
|
How realistic is it to add a Windows CI job here? (can be cross-compiled) |
The lifecycle test repeatedly constructs and destroys TPTester to exercise IPC EventLoop teardown. On Windows it hangs intermittently in std::thread::join during teardown of libmultiprocess thread-local state. This is a known libmultiprocess Windows issue, not specific to sv2-tp: bitcoin-core/libmultiprocess#231 bitcoin/bitcoin#32387 The fix lives upstream and rewrites the EventLoop wakeup primitive (raw fd -> KJ stream) and adds shutdownWrite() in ~Connection. Until that lands and is backported into our libmultiprocess subtree, gate this particular test off on _WIN32. The other sv2 unit tests run normally on Windows; only the explicit teardown loop is affected. Assisted-by: GitHub Copilot Assisted-by: Anthropic Claude Opus 4
The template_provider_tests `client_tests`, `fee_timer_blocking_test` and `new_tip_bypasses_fee_timer_test` cases each construct and tear down a TPTester. Like the lifecycle test skipped in the previous commit, that teardown deadlocks intermittently on Windows in std::thread::join during libmultiprocess thread-local state cleanup. This is a known libmultiprocess Windows issue, not specific to sv2-tp: bitcoin-core/libmultiprocess#231 bitcoin/bitcoin#32387 Gate the three TPTester-using cases off on _WIN32 with a TODO. The non-IPC test `block_reserved_weight_floor` continues to run on Windows. Assisted-by: GitHub Copilot Assisted-by: Anthropic Claude Opus 4
The sv2 template_provider_tests pass on Windows; only TPTester teardown intermittently deadlocks in std::thread::join during libmultiprocess thread-local cleanup. This is a known libmultiprocess Windows issue, not specific to sv2-tp: bitcoin-core/libmultiprocess#231 bitcoin/bitcoin#32387 Instead of skipping the cases, exercise them normally and intentionally leak the TPTester so its destructor never runs. The OS reclaims the remaining loop thread and IPC state at process exit. A MAKE_TPTESTER helper macro keeps the tests source-compatible across platforms; on non-Windows it is just a stack-allocated TPTester as before. The lifecycle test in sv2_tester_lifecycle_tests is left skipped on Windows because its whole purpose is to exercise repeated construction and destruction of TPTester; leaking would defeat it. Assisted-by: GitHub Copilot Assisted-by: Anthropic Claude Opus 4
I think this does need a windows CI job to exist in order to be merged, otherwise windows support is very likely to break with future changes, so thanks for opening #272. I think it may also make sense to split this PR up to separate the commits which are needed to support windows but don't actually add any windows code, from the one commit which actually does add windows code. |
Yes it would be good to land those changes to keep this PR focussed. |
18fc188 to
7fd5ec4
Compare
The lifecycle test repeatedly constructs and destroys TPTester to exercise IPC EventLoop teardown. On Windows it hangs intermittently in std::thread::join during teardown of libmultiprocess thread-local state. This is a known libmultiprocess Windows issue, not specific to sv2-tp: bitcoin-core/libmultiprocess#231 bitcoin/bitcoin#32387 The fix lives upstream and rewrites the EventLoop wakeup primitive (raw fd -> KJ stream) and adds shutdownWrite() in ~Connection. Until that lands and is backported into our libmultiprocess subtree, gate this particular test off on _WIN32. The other sv2 unit tests run normally on Windows; only the explicit teardown loop is affected. Assisted-by: GitHub Copilot Assisted-by: Anthropic Claude Opus 4
The lifecycle test repeatedly constructs and destroys TPTester to exercise IPC EventLoop teardown. On Windows it hangs intermittently in std::thread::join during teardown of libmultiprocess thread-local state. This is a known libmultiprocess Windows issue, not specific to sv2-tp: bitcoin-core/libmultiprocess#231 bitcoin/bitcoin#32387 The fix lives upstream and rewrites the EventLoop wakeup primitive (raw fd -> KJ stream) and adds shutdownWrite() in ~Connection. Until that lands and is backported into our libmultiprocess subtree, gate this particular test off on _WIN32. The other sv2 unit tests run normally on Windows; only the explicit teardown loop is affected. Assisted-by: GitHub Copilot Assisted-by: Anthropic Claude Opus 4
Tearing down a TPTester (and with it the IPC EventLoop / per-thread state) intermittently deadlocks on Windows in std::thread::join during libmultiprocess thread-local cleanup. The fix lives upstream and rewrites the EventLoop wakeup primitive (raw fd -> KJ stream) and adds shutdownWrite() in ~Connection. Until that lands and is backported into our libmultiprocess subtree, paper over it in the test harness so the Windows CI job stays useful: - TPTesterHandle now heap-allocates and intentionally leaks the tester on Windows; the OS reclaims the remaining loop thread and IPC state at process exit. This only disables test cleanup, not the tests themselves. Non-Windows builds continue to own the tester by value. - sv2_tester_lifecycle_tests is gated off on _WIN32, since its whole purpose is to exercise repeated TPTester construction and destruction; leaking would defeat the test. - src/test/main.cpp installs a Windows-only Boost global fixture whose destructor runs at module teardown (after every test case has completed and Boost has tallied results). It flushes stdout/stderr and calls _exit() with 0 or 1 based on the Boost results, bypassing static destructors entirely so the leaked threads cannot fault and turn a green run into exit code 139. - lint-includes.py: allowlist boost/test/results_collector.hpp, required by the new fixture. References: bitcoin-core/libmultiprocess#231 bitcoin/bitcoin#32387 Assisted-by: GitHub Copilot Assisted-by: Anthropic Claude Opus 4 Assisted-by: Anthropic Claude Opus 4.7
| using Stream = kj::Own<kj::AsyncIoStream>; | ||
|
|
||
| #ifdef WIN32 | ||
| using ProcessId = uintptr_t; |
There was a problem hiding this comment.
Out of curiosity, any reason ProcessId is uintptr_t rather than HANDLE on Windows? Would remove the reinterpret_casts
There was a problem hiding this comment.
re: #231 (comment)
Out of curiosity, any reason ProcessId is uintptr_t rather than HANDLE on Windows? Would remove the reinterpret_casts
Good question, I think you are right it could be good to use HANDLE instead. Probably original motivation for using uintptr_t was to avoid needing to pull in win32 headers for all code using mp/util.h, but maybe that bridge has already been crossed with inclusion of winsock2.h as per your other comment #231 (comment), so this should be revisited. Could also go the other direction and drop winsock2.h since it looks like it is only needed for INVALID_SOCKET definition.
Another potentially confusing about this is that process handles and process ids (as returned by functions like GetCurrentProcessId) are actually different things on windows. Handles are more useful for controlling and waiting for processes, but process ids are more globally unique and useful in other contexts.
Will look into alternatives here and try to add a clarifying comment at least.
|
Tested mingw cross-build and native MSVC build Environment: Arch Linux (kernel 6.19), CMake 4.3.2, mingw-w64 GCC 15.2.0, Cap'n Proto 1.2.0, target Windows 11 (x64). MSVC side: MSBuild 18.5.4 mingw cross (x86_64-w64-mingw32) worked for me with one small tweak. <winsock2.h> in util.h pulls winsock2.h -> ole2.h -> objbase.h -> rpc.h, which #defines interface as struct and breaks the build: #ifdef WIN32
+#ifndef WIN32_LEAN_AND_MEAN
+#define WIN32_LEAN_AND_MEAN
+#endif
#include <winsock2.h>
#endifWith that, build succeeds, examples run, and tests pass on Windows 11 10.0.26100 MSVC native: same interface-as-struct macro pollution and more errors shows up but to make it work it seems it's not one line fix: MSVC build logC:\Users\vinic\libmultiprocess>cmake --build build -j 1 MSBuild version 18.5.4+cb4e32d21 for .NET Frameworkutil.cpp C:\Users\vinic\libmultiprocess\src\mp\util.cpp(262,5): warning C4996: 'WSADuplicateSocketA': Use WSADuplicateSocketW() C:\Users\vinic\libmultiprocess\src\mp\gen.cpp(80,66): error C2332: 'struct': missing tag name [C:\Users\vinic\libmultip C:\Users\vinic\libmultiprocess\src\mp\gen.cpp(414,36): error C2144: syntax error: '' should be preceded by C:\Users\vinic\libmultiprocess\src\mp\gen.cpp(419,92): error C2065: 'method_interface': undeclared identifier [C:\Users C:\capnproto\install\include\capnp\capability.h(88,40): error C2838: 'IPrintDialogServices': illegal qualified name in C:\capnproto\install\include\capnp\capability.h(88,40): error C2275: 'IPrintDialogServices': expected an expression ins C:\capnproto\install\include\capnp\capability.h(88,40): error C2440: 'initializing': cannot convert from 'IPrintDialogS C:\capnproto\install\include\capnp\capability.h(913,32): error C2838: 'IPrintDialogServices': illegal qualified name in C:\capnproto\install\include\capnp\capability.h(913,32): error C2275: 'IPrintDialogServices': expected an expression in C:\capnproto\install\include\capnp\capability.h(913,32): error C2975: 'k': invalid template argument for 'capnp::_::Poi C:\capnproto\install\include\capnp\capability.h(940,22): error C2838: 'IPrintDialogServices': illegal qualified name in C:\capnproto\install\include\capnp\capability.h(940,22): error C2275: 'IPrintDialogServices': expected an expression in C:\capnproto\install\include\capnp\capability.h(940,22): error C2975: 'k': invalid template argument for 'capnp::List', C:\capnproto\install\include\capnp\capability.h(940,8): error C2953: 'capnp::List<T,capnp::Kind::PRIMITIVE>': class tem C:\capnproto\install\include\capnp\capability.h(1285,43): error C2838: 'IPrintDialogServices': illegal qualified name i C:\capnproto\install\include\capnp\capability.h(1285,43): error C2275: 'IPrintDialogServices': expected an expression i C:\capnproto\install\include\capnp\capability.h(1285,43): error C2975: 'unnamed-parameter': invalid template argument f C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(57,5): error C2838: 'IPrintDialogServices': illegal quali C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(57,5): error C2275: 'IPrintDialogServices': expected an e C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(57,5): error C2440: 'initializing': cannot convert from ' C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(106,5): error C2838: 'IPrintDialogServices': illegal qual C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(106,5): error C2275: 'IPrintDialogServices': expected an C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(106,5): error C2440: 'initializing': cannot convert from C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(755,53): error C2039: 'get': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(755,53): error C3861: 'get': identifier not found [C:\Use C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(759,53): error C2039: 'get': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(759,53): error C2672: 'get': no matching overloaded funct C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(766,46): error C2039: 'set': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(766,46): error C3861: 'set': identifier not found [C:\Use C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(770,46): error C2039: 'set': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(770,46): error C3861: 'set': identifier not found [C:\Use C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(775,46): error C2039: 'adopt': is not a member of 'capnp: C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(775,46): error C3861: 'adopt': identifier not found [C:\U C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(779,53): error C2039: 'disown': is not a member of 'capnp C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(779,53): error C3861: 'disown': identifier not found [C: C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(852,53): error C2039: 'get': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(852,53): error C3861: 'get': identifier not found [C:\Use C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(856,53): error C2039: 'get': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(856,53): error C2672: 'get': no matching overloaded funct C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(863,46): error C2039: 'set': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(863,46): error C3861: 'set': identifier not found [C:\Use C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(867,46): error C2039: 'set': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(867,46): error C3861: 'set': identifier not found [C:\Use C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(872,46): error C2039: 'adopt': is not a member of 'capnp: C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(872,46): error C3861: 'adopt': identifier not found [C:\U C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(876,53): error C2039: 'disown': is not a member of 'capnp C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(876,53): error C3861: 'disown': identifier not found [C: C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(891,53): error C2039: 'get': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(891,53): error C3861: 'get': identifier not found [C:\Use C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(895,53): error C2039: 'get': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(895,53): error C2672: 'get': no matching overloaded funct C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(902,46): error C2039: 'set': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(902,46): error C3861: 'set': identifier not found [C:\Use C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(906,46): error C2039: 'set': is not a member of 'capnp::_ C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(906,46): error C3861: 'set': identifier not found [C:\Use C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(911,46): error C2039: 'adopt': is not a member of 'capnp: C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(911,46): error C3861: 'adopt': identifier not found [C:\U C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(915,53): error C2039: 'disown': is not a member of 'capnp C:\Users\vinic\libmultiprocess\build\include\mp\proxy.capnp.h(915,53): error C3861: 'disown': identifier not found [C: C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(724,60): error C2039: 'get': is not a member of 'capnp::::Poin C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(724,60): error C3861: 'get': identifier not found [C:\Users\vin C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(728,60): error C2039: 'get': is not a member of 'capnp::::Poin C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(728,60): error C2672: 'get': no matching overloaded function fo C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(735,53): error C2039: 'set': is not a member of 'capnp::::Poin C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(735,53): error C3861: 'set': identifier not found [C:\Users\vin C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(739,53): error C2039: 'set': is not a member of 'capnp::::Poin C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(739,53): error C3861: 'set': identifier not found [C:\Users\vin C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(744,53): error C2039: 'adopt': is not a member of 'capnp::::Po C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(744,53): error C3861: 'adopt': identifier not found [C:\Users\v C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(748,60): error C2039: 'disown': is not a member of 'capnp::::P C:\capnproto\install\include\capnp\rpc-twoparty.capnp.h(748,60): error C3861: 'disown': identifier not found [C:\Users |
ryanofsky
left a comment
ryanofsky
left a comment
There was a problem hiding this comment.
Thanks for the review! Will follow up and look into ProcessId and winsock2.h issues
| using Stream = kj::Own<kj::AsyncIoStream>; | ||
|
|
||
| #ifdef WIN32 | ||
| using ProcessId = uintptr_t; |
There was a problem hiding this comment.
re: #231 (comment)
Out of curiosity, any reason ProcessId is uintptr_t rather than HANDLE on Windows? Would remove the reinterpret_casts
Good question, I think you are right it could be good to use HANDLE instead. Probably original motivation for using uintptr_t was to avoid needing to pull in win32 headers for all code using mp/util.h, but maybe that bridge has already been crossed with inclusion of winsock2.h as per your other comment #231 (comment), so this should be revisited. Could also go the other direction and drop winsock2.h since it looks like it is only needed for INVALID_SOCKET definition.
Another potentially confusing about this is that process handles and process ids (as returned by functions like GetCurrentProcessId) are actually different things on windows. Handles are more useful for controlling and waiting for processes, but process ids are more globally unique and useful in other contexts.
Will look into alternatives here and try to add a clarifying comment at least.
1b0f605 doc: Remove trailing whitespace (Ryan Ofsky) d8f8ca3 ipc: Wrap mpgen main() in try-catch to print errors (Ryan Ofsky) fbe5a14 ci: Check out bitcoin/bitcoin PR #35084 instead of master (Ryan Ofsky) 39d3690 types: Replace SFINAE with requires clauses to avoid MSVC C2039 error (Ryan Ofsky) ba68520 proxy, refactor: Fix C4305 truncation warning in Accessor on MSVC (Ryan Ofsky) 1d81d47 util, refactor: Fix PtrOrValue constructor for move-only types on MSVC (Ryan Ofsky) b883fe1 proxy: Fix shutdownWrite() exception handling on macOS with dynamic libraries (Ryan Ofsky) 0012411 proxy: Call shutdownWrite() in Connection destructor (Ryan Ofsky) 38312ad proxy, refactor: Change ConnectStream and ServeStream to accept stream objects (Ryan Ofsky) e96d5d7 proxy, refactor: Replace EventLoop wakeup fd integers with KJ stream objects (Ryan Ofsky) db4f9a3 cmake: Bump minimum required Cap'n Proto version to 0.9 (Ryan Ofsky) 652934f util, refactor: Add SocketPair() and use it in SpawnProcess (Ryan Ofsky) 1c6ef7a util, refactor: Do not fork() and exec() separately (Ryan Ofsky) 1389cf3 util, refactor: Add SpawnConnectInfo type alias and use it (Ryan Ofsky) c7ca1f0 util, refactor: Add SocketId type alias and use it (Ryan Ofsky) be46a35 util, refactor: Add ProcessId type alias and use it (Ryan Ofsky) 91a78db doc: Bump version 13 > 14 (Ryan Ofsky) Pull request description: This PR implements API changes and fixes needed to allow libmultiprocess to work on nonunix platforms. These changes were originally part of #231, which adds windows support, but were split out to allow windows and nonwindows changes to be reviewed separately. ACKs for top commit: Sjors: ACK 1b0f605 ViniciusCestarii: ACK 1b0f605 I like that these changes make the code more readable too, require clauses and KJ Stream abstractions are nice Tree-SHA512: 3f9e92487b29734f5681f797786a317c708c6df3e5242189729955f3a797e944a8db1d2af2863b570928582b1a202ee761ca7c9758744e80840fa16bc0d188e2
Add Windows-specific code to support building and running on Windows: - util.h: Guard ProcessId/SocketId/SocketError type aliases with WIN32 ifdefs so they use SOCKET/uintptr_t on Windows and int on Unix. Add winsock2.h include on Windows. - util.cpp: Guard Unix-specific system headers with WIN32 ifdefs. Add Windows-specific includes (windows.h, winsock2.h). Guard MaxFd() with #ifndef WIN32. Add GetCurrentThreadId() branch in ThreadName(). Add win32Socketpair() forward-declare. Add Windows branch in SocketPair() using win32Socketpair(). Add CommandLineFromArgv() helper needed to construct CreateProcess command lines. Add Windows branch in SpawnProcess() using named pipes and WSADuplicateSocket to pass socket to child. Add Windows branch in StartSpawned() reading socket from named pipe. Add Windows branch in WaitProcess() using WaitForSingleObject/GetExitCodeProcess. - proxy.cpp: Add SocketOutputStream class on Windows (analogous to FdOutputStream but using SOCKET/send()). Add Windows branch in EventLoop constructor to create m_post_writer using SocketOutputStream.
Remove POSIX and pthread calls from util.cpp to avoid relying on MinGW's POSIX compatibility layer. This lets code be compiled with MSVC.
- shell.nix: add `windows` parameter that selects pkgs.pkgsCross.mingwW64
as the cross target; also change crossPkgs default from import<nixpkgs>{}
to null (cleaner API). When windows=true, add native pkgs.capnproto to
nativeBuildInputs so capnp/capnpc-c++ are in PATH for cmake code generation,
and add wine64Packages.staging so ctest can run mptest.exe via wine.
Change llvmBase to always use pkgs (native) instead of crossPkgs.
- ci/configs/windows.bash: new config that cross-compiles with mingw,
sets CMAKE_SYSTEM_NAME=Windows, CMAKE_FIND_ROOT_PATH_MODE_PROGRAM=NEVER
(so cmake finds native capnp from PATH), CMAKE_CROSSCOMPILING_EMULATOR=wine
(so ctest runs mptest.exe via wine), and sets MPGEN_PRE_BUILD=1.
- ci/scripts/ci.sh: add MPGEN_PRE_BUILD support: when set, build native mpgen
in $CI_DIR-native before the main cross build, then inject
-DMPGEN_EXECUTABLE into CMAKE_ARGS. This is needed because cmake's
add_custom_command does not use CMAKE_CROSSCOMPILING_EMULATOR, so the
cross-compiled mpgen.exe cannot be used as a code generator directly.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
|
This PR is rebased after the #274 merge, so should be ready for review now. It does look like fixes will be needed for CI, though, and I'm working on that. Note my goal with this PR is just to add a basic level of windows support so libmultiprocess cross-compiles with mingw and spawn and listen tests run in wine. More followups will probably be needed after this to fix any problems that arise with MSVC support or enabling IPC in windows builds for Bitcoin core. The full PR targeting all of that is bitcoin/bitcoin#32387 and has some unresolved issues still. The downstream PR bitcoin/bitcoin#35084 updating Bitcoin core to use the newer libmultiprocess API is also ready for review and can be reviewed in parallel to this. Rebased 7fd5ec4 -> 259f010 ( |
5 participants
Add support for running on windows. These changes make the libmultiprocess API more generic, using stream types instead of file descriptors. All features are supported, including spawning processes with socket connections to the parent process. These changes were originally made in bitcoin/bitcoin#32387