x86_64-w64-mingw32ucrt triplet to depends/README.md
#33857
This PR is part of the ongoing effort to migrate to the modern UCRT runtime for cross-compiled Windows binaries, including release builds.
For more details about this migration, see:
Can be tested on the following systems:
g++-mingw-w64-ucrt64 package, as documented).ucrt64-gcc-c++ package).Also see related upstream issues:
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/33857.
See the guideline for information on the review process.
| Type | Reviewers |
|---|---|
| ACK | m3dwards, hodlinator |
If your review is incorrectly listed, please copy-paste <!–meta-tag:bot-skip–> into the comment that the bot should ignore.
Reviewers, 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.
Can be tested on the following systems:
- Fedora 42 or 43 (requires the
ucrt64-gcc-c++package).
For example: https://github.com/hebasto/bitcoin-core-nightly/actions/runs/19274168370.
137@@ -137,16 +138,20 @@ The paths are automatically configured and no other options are needed.
138
139 #### For macOS cross compilation
140
141- apt install clang lld llvm zip
142+ sudo apt install clang lld llvm zip
sudo usage.
121@@ -122,7 +122,8 @@ Common `host-platform-triplet`s for cross compilation are:
122
123 - `i686-pc-linux-gnu` for Linux x86 32 bit
124 - `x86_64-pc-linux-gnu` for Linux x86 64 bit
125-- `x86_64-w64-mingw32` for Win64
126+- `x86_64-w64-mingw32` for Windows using MSVCRT
x86_64-w64-mingw32.
It could make sense to ask Ubuntu to import g++-mingw-w64-ucrt64 from Debian, at least for the 26.04 release.
My hope was that one toolchain could be dropped while adding the new one relatively quickly, or even at the same time.
Unrelated, I wonder what all the major benefits of ucrt are. Is it just the x-modifier in fopen calls?
It could make sense to ask Ubuntu to import g++-mingw-w64-ucrt64 from Debian, at least for the 26.04 release.
It appears to be a WIP: https://packages.ubuntu.com/search?keywords=ucrt
Unrelated, I wonder what all the major benefits of ucrt are. Is it just the x-modifier in fopen calls?
From https://learn.microsoft.com/en-us/cpp/porting/upgrade-your-code-to-the-universal-crt:
Many functions were added or updated in the UCRT to improve ISO C99 conformance, and to address code quality and security issues.
This discussion can be continued in #30210.
It could make sense to ask Ubuntu to import g++-mingw-w64-ucrt64 from Debian, at least for the 26.04 release.
It appears to be a WIP: https://packages.ubuntu.com/search?keywords=ucrt
Ah ok, so maybe someone could open a question/request at https://launchpad.net/ubuntu/+source/gcc-mingw-w64/+bugs, so that the progress can be tracked.
Ah ok, so maybe someone could open a question/request at https://launchpad.net/ubuntu/+source/gcc-mingw-w64/+bugs, so that the progress can be tracked.
https://bugs.launchpad.net/ubuntu/+source/gcc-mingw-w64/+bug/2132114
My hope was that one toolchain could be dropped while adding the new one relatively quickly, or even at the same time.
Yea. That was my intention/expectation for any migration.
developers on Ubuntu, for example, may still want to build for x86_64-w64-mingw32.
Are we supporting that, if the CI is removed in #33593 (along with dropping workarounds going forward).
We won’t support that once workarounds are dropped and code become incompatible with MSVCRT. By that point, I don’t anticipate any issues with providing that support.
If we are migrating, should we just do this at this same time as we actually migrate, then we don’t have to worry about both. Are we dropping support for the old runtime at the same time we switch to using the new ones in releases?
Yes, we are going to migrate the Windows release binaries to UCRT.
However, the depends build subsystem has capabilities to build for a wider range of targets than those used in releases. This is well documented in README.md, which refers, for example, to i686-pc-linux-gnu and s390x-linux-gnu.
We are currently in a situation where:
The codebase remains compatible with both MSVCRT and UCRT.
Full UCRT-capable toolchains are not yet available across all major distributions.
For that reason, this PR is focused on adding the ability to build depends for the new target x86_64-w64-mingw32ucrt.
In my view, dropping support for x86_64-w64-mingw32 should be considered separately and at a later stage, once the codebase becomes incompatible with MSVCRT or the toolchain landscape has matured.
In my view, dropping support for x86_64-w64-mingw32 should be considered separately and at a later stage, once the codebase becomes incompatible with MSVCRT or the toolchain landscape has matured.
Shouldn’t it be removed once we remove it from the CI? which, according to the PR description in #33764, will be done once the Guix migration is done:
MSVCRT-related CI jobs should be removed from the CI framework once the migration to UCRT is complete.
Just trying to get a clearer idea of what order things are happening in, and what we are supporting and for how long.
In my view, dropping support for x86_64-w64-mingw32 should be considered separately and at a later stage, once the codebase becomes incompatible with MSVCRT or the toolchain landscape has matured.
Shouldn’t it be removed once we remove it from the CI? which, according to the PR description in #33764, will be done once the Guix migration is done:
Agreed.
MSVCRT-related CI jobs should be removed from the CI framework once the migration to UCRT is complete.
Just trying to get a clearer idea of what order things are happening in, and what we are supporting and for how long.
I don’t think the precise coordination between PRs addressing the subtasks outlined in #30210 is essential.
Not necessarily an issue with this PR but when trying to test on Trixie with make -C depends HOST=x86_64-w64-mingw32ucrt -j9
I get:
0make: Entering directory '/bitcoin/depends'
1Configuring boost...
2-- The CXX compiler identification is GNU 14.0.0
3-- Detecting CXX compiler ABI info
4-- Detecting CXX compiler ABI info - failed
5-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32ucrt-g++
6-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32ucrt-g++ - broken
7CMake Error at /usr/share/cmake-3.31/Modules/CMakeTestCXXCompiler.cmake:73 (message):
8 The C++ compiler
9
10 "/usr/bin/x86_64-w64-mingw32ucrt-g++"
11
12 is not able to compile a simple test program.
13
14 It fails with the following output:
15
16 Change Dir: '/bitcoin/depends/work/build/x86_64-w64-mingw32ucrt/boost/1.88.0-ff7a7d65da7/build/CMakeFiles/CMakeScratch/TryCompile-Oq3Ey2'
17
18 Run Build Command(s): /usr/bin/cmake -E env VERBOSE=1 /usr/bin/gmake -f Makefile cmTC_70991/fast
19 gmake[1]: Entering directory '/bitcoin/depends/work/build/x86_64-w64-mingw32ucrt/boost/1.88.0-ff7a7d65da7/build/CMakeFiles/CMakeScratch/TryCompile-Oq3Ey2'
20 /usr/bin/gmake -f CMakeFiles/cmTC_70991.dir/build.make CMakeFiles/cmTC_70991.dir/build
21 gmake[2]: Entering directory '/bitcoin/depends/work/build/x86_64-w64-mingw32ucrt/boost/1.88.0-ff7a7d65da7/build/CMakeFiles/CMakeScratch/TryCompile-Oq3Ey2'
22 Building CXX object CMakeFiles/cmTC_70991.dir/testCXXCompiler.cxx.obj
23 /usr/bin/x86_64-w64-mingw32ucrt-g++ -I/bitcoin/depends/x86_64-w64-mingw32ucrt/include -O2 -pipe -std=c++20 -o CMakeFiles/cmTC_70991.dir/testCXXCompiler.cxx.obj -c /bitcoin/depends/work/build/x86_64-w64-mingw32ucrt/boost/1.88.0-ff7a7d65da7/build/CMakeFiles/CMakeScratch/TryCompile-Oq3Ey2/testCXXCompiler.cxx
24 Linking CXX executable cmTC_70991.exe
25 /usr/bin/cmake -E cmake_link_script CMakeFiles/cmTC_70991.dir/link.txt --verbose=1
26 /usr/bin/x86_64-w64-mingw32ucrt-ld: /usr/lib/gcc/x86_64-w64-mingw32ucrt/14/libstdc++.dll.a: error adding symbols: archive has no index; run ranlib to add one
27 collect2: error: ld returned 1 exit status
28 /usr/bin/cmake -E rm -f CMakeFiles/cmTC_70991.dir/objects.a
29 /usr/bin/x86_64-w64-mingw32ucrt-ar qc CMakeFiles/cmTC_70991.dir/objects.a [@CMakeFiles](/bitcoin-bitcoin/contributor/cmakefiles/)/cmTC_70991.dir/objects1.rsp
30 /usr/bin/x86_64-w64-mingw32ucrt-g++ -I/bitcoin/depends/x86_64-w64-mingw32ucrt/include -O2 -pipe -std=c++20 -L/bitcoin/depends/x86_64-w64-mingw32ucrt/lib -Wl,--whole-archive CMakeFiles/cmTC_70991.dir/objects.a -Wl,--no-whole-archive -o cmTC_70991.exe -Wl,--out-implib,libcmTC_70991.dll.a -Wl,--major-image-version,0,--minor-image-version,0 [@CMakeFiles](/bitcoin-bitcoin/contributor/cmakefiles/)/cmTC_70991.dir/linkLibs.rsp
31 gmake[2]: *** [CMakeFiles/cmTC_70991.dir/build.make:104: cmTC_70991.exe] Error 1
32 gmake[2]: Leaving directory '/bitcoin/depends/work/build/x86_64-w64-mingw32ucrt/boost/1.88.0-ff7a7d65da7/build/CMakeFiles/CMakeScratch/TryCompile-Oq3Ey2'
33 gmake[1]: *** [Makefile:134: cmTC_70991/fast] Error 2
34 gmake[1]: Leaving directory '/bitcoin/depends/work/build/x86_64-w64-mingw32ucrt/boost/1.88.0-ff7a7d65da7/build/CMakeFiles/CMakeScratch/TryCompile-Oq3Ey2'
35
36
37
38
39
40 CMake will not be able to correctly generate this project.
41Call Stack (most recent call first):
42 CMakeLists.txt:13 (project)
43
44
45-- Configuring incomplete, errors occurred!
46make: *** [funcs.mk:344: /bitcoin/depends/x86_64-w64-mingw32ucrt/.boost_stamp_configured] Error 1
47make: Leaving directory '/bitcoin/depends'
Not necessarily an issue with this PR but when trying to test on Trixie with
make -C depends HOST=x86_64-w64-mingw32ucrt -j9I get: …
Interesting.
I’m unable to reproduce this in a fresh Trixie container using Docker:
0# apt update
1# apt install git cmake curl make patch bison g++ ninja-build pkgconf python3 xz-utils g++-mingw-w64-ucrt64
2# git clone --depth=1 https://github.com/hebasto/bitcoin -b 251111-doc-ucrt && cd bitcoin
3# gmake -C depends -j 16 HOST=x86_64-w64-mingw32ucrt
UPDATE: Have you tried to reinstall g++-mingw-w64-ucrt64?
I’m unable to reproduce this in a fresh Trixie container using Docker
I did almost the same apart from I checked out this PR rather than building from master.
This works on x86 but isn’t working on Apple ARM for me. I don’t think it’s anything wrong with this PR, but it’s a problem with the UCRT MinGW compiler. That being the case, should this hold up this PR?
I’m unable to reproduce this in a fresh Trixie container using Docker
I did almost the same apart from I checked out this PR rather than building from master.
Sorry. I’ve adjusted my comment.
This works on x86 but isn’t working on Apple ARM for me.
I can confirm the issue on aarch64.
This works on x86 but isn’t working on Apple ARM for me.
I can confirm the issue on
aarch64.
See: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1121403.
I can confirm the issue on
aarch64
According to the Debian bug report, seems it’s also an issue on RISC-V.
GCC-based tools already follow the standard naming convention for the
`x86_64-w64-mingw32ucrt` target.
0@@ -1,9 +1,11 @@
1+ifneq (ucrt,$(findstring ucrt,$(host)))
I don’t think this check is strictly necessary as the inner check will fail when $host has ucrt in it anyway.
0root:/bitcoin# host=x86_64-w64-mingw32
1root:/bitcoin# command -v $host-gcc-posix
2/usr/bin/x86_64-w64-mingw32-gcc-posix
3root:/bitcoin# host=x86_64-w64-mingw32ucrt
4root:/bitcoin# command -v $host-gcc-posix
5root:/bitcoin#
ACK ec8eb013a9bfceb324b309f13b8946b05292a993
Ran
env -i HOME="$HOME" PATH="$PATH" USER="$USER" bash -c 'MAKEJOBS="-j$(nproc)" FILE_ENV="./ci/test/00_setup_env_win64.sh" ./ci/test_run_all.sh'
locally and confirmed it successfully generated an executable at
/ci_container_base/ci/scratch/build-x86_64-w64-mingw32ucrt/bin/bitcoind.exe