Boost cross-compilation and testing (Linux -> Windows)
Hello, we're working on a new target for MinGW compiler, we're intending to have a cross-compiler from Linux Arm64 to Windows Arm64. We want to have Boost library as a benchmark of how complete our C++ compiler is and gradually improve it to support more features. I'm struggling though to get the cross-compilation and subsequent testing working. 1) I'm having troubles to set up cross-building of Boost with MinGW (even standard MinGW from package manager Linux x64 -> Windows x64). I'm getting errors while building Context, Process and Stacktrace modules. (I added to the respective error messages to the end of the email or full logs can be found here: https://github.com/user-attachments/files/17133738/x64_boost_build.log) My build commands: git clone --recursive https://github.com/boostorg/boost.git boost-build cd boost-build git checkout develop git submodule update --init --recursive echo "using gcc : : x86_64-w64-mingw32-g++ ;" > "user-config-x64.jam" ./bootstrap.sh ./b2 --user-config=./user-config-x64.jam --prefix=./boost-x64 --debug-configuration target-os=windows address-model=64 variant=debug install > x64_boost_build.log
From the error messages, it seems like I'm doing something essential wrong as for example Process module tries to build assembler for ELF format and SYSV ABI and not Window's PE format and MS ABI.
2) Subsequently, I didn't have much luck finding resources for cross-testing of
Boost. Currently, I'm building and running tests in Ubuntu 22.04 in WSL on
Windows machine. In general, this approach seems to work decently, Boost itself
and its tests are built on Ubuntu as Windows binaries and when test executables
are run, WSL automatically propagates it to run those executables on underlaying
Windows. But a lot of tests are failing. I'm gradually investigating them and finding
issues like missing dlls because b2 uses LD_LIBRARY_PATH and Windows doesn't
understand it. I'm workarounding these issues but it's a slow process, so I wanted
to ask, is the cross-testing of Boost library supported, are you aware of some
examples where it's being used?
Thank you and kind regards,
Martin
-------------------------------------------------------------------------------
a) Context errors:
(similar also for jump_x86_64_sysv_elf_gas.S and ontop_x86_64_sysv_elf_gas.S)
gcc.compile.asm bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/
target-os-windows/threadapi-win32/threading-multi/visibility-hidden/
asm/make_x86_64_sysv_elf_gas.o
make_x86_64_sysv_elf_gas.S: Assembler messages:
make_x86_64_sysv_elf_gas.S:47: Warning: .type pseudo-op used outside of .def/.endef: ignored.
make_x86_64_sysv_elf_gas.S:47: Error: junk at end of line, first unrecognized character is `m'
/home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:157:
Warning: .size pseudo-op used outside of .def/.endef: ignored.
/home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:157:
Error: junk at end of line, first unrecognized character is `m'
/home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S:160:
Error: junk at end of line, first unrecognized character is `-'
"x86_64-w64-mingw32-g++" -x assembler-with-cpp -m64 -O0 -fno-inline -Wall -g
-fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_CONTEXT_NO_LIB=1
-DBOOST_CONTEXT_SOURCE -D_WIN32_WINNT=0x0601 -I"."
-I"/home/vejby/boost-build/libs/assert/include"
-I"/home/vejby/boost-build/libs/context/include"
-I"/home/vejby/boost-build/libs/core/include"
-I"/home/vejby/boost-build/libs/move/include"
-I"/home/vejby/boost-build/libs/mp11/include"
-I"/home/vejby/boost-build/libs/predef/include"
-I"/home/vejby/boost-build/libs/smart_ptr/include"
-I"/home/vejby/boost-build/libs/throw_exception/include"
-I"/home/vejby/boost-build/libs/type_traits/include" -c -o
"bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/target-os-windows/
threadapi-win32/threading-multi/visibility-hidden/asm/make_x86_64_sysv_elf_gas.o"
"/home/vejby/boost-build/libs/context/src/asm/make_x86_64_sysv_elf_gas.S"
...failed gcc.compile.asm
bin.v2/libs/context/build/gcc-10/debug/x86_64/link-static/target-os-windows/
threadapi-win32/threading-multi/visibility-hidden/asm/make_x86_64_sysv_elf_gas.o...
-------------------------------------------------------------------------------
b) Process errors:
gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/
boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/
threading-multi/visibility-hidden/ext/exe.o
/home/vejby/boost-build/libs/process/src/ext/exe.cpp: In function
‘boost::filesystem::path boost::process::v2::ext::exe
(HANDLE, boost::system::error_code&)’:
/home/vejby/boost-build/libs/process/src/ext/exe.cpp:78:9: error:
‘QueryFullProcessImageNameW’ was not declared in this scope
78 | if (QueryFullProcessImageNameW(proc, 0, buffer, &size))
| ^~~~~~~~~~~~~~~~~~~~~~~~~~
"x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline
-Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1
-DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1
-DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1
-DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1
-DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"."
-I"/home/vejby/boost-build/libs/algorithm/include"
-I"/home/vejby/boost-build/libs/assert/include"
-I"/home/vejby/boost-build/libs/bind/include"
-I"/home/vejby/boost-build/libs/container_hash/include"
-I"/home/vejby/boost-build/libs/core/include"
-I"/home/vejby/boost-build/libs/describe/include"
-I"/home/vejby/boost-build/libs/detail/include"
-I"/home/vejby/boost-build/libs/filesystem/include"
-I"/home/vejby/boost-build/libs/function/include"
-I"/home/vejby/boost-build/libs/function_types/include"
-I"/home/vejby/boost-build/libs/fusion/include"
-I"/home/vejby/boost-build/libs/iterator/include"
-I"/home/vejby/boost-build/libs/move/include"
-I"/home/vejby/boost-build/libs/mp11/include"
-I"/home/vejby/boost-build/libs/optional/include"
-I"/home/vejby/boost-build/libs/predef/include"
-I"/home/vejby/boost-build/libs/process/include"
-I"/home/vejby/boost-build/libs/regex/include"
-I"/home/vejby/boost-build/libs/scope/include"
-I"/home/vejby/boost-build/libs/smart_ptr/include"
-I"/home/vejby/boost-build/libs/system/include"
-I"/home/vejby/boost-build/libs/throw_exception/include"
-I"/home/vejby/boost-build/libs/tuple/include"
-I"/home/vejby/boost-build/libs/type_index/include"
-I"/home/vejby/boost-build/libs/type_traits/include"
-I"/home/vejby/boost-build/libs/unordered/include"
-I"/home/vejby/boost-build/libs/variant2/include"
-I"/home/vejby/boost-build/libs/winapi/include" -c -o
"bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/
link-static/target-os-windows/threadapi-win32/threading-multi/
visibility-hidden/ext/exe.o"
"/home/vejby/boost-build/libs/process/src/ext/exe.cpp"
...failed gcc.compile.c++
bin.v2/libs/process/build/gcc-10/debug/x86_64/boost.process.fs-boost/
link-static/target-os-windows/threadapi-win32/threading-multi/
visibility-hidden/ext/exe.o...
-------------------------------------------------------------------------------
gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/
boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/
threading-multi/visibility-hidden/windows/default_launcher.o
In file included from /home/vejby/boost-build/libs/process/src/windows/
default_launcher.cpp:16:
./boost/process/v2/windows/default_launcher.hpp:220:3: error:
‘STARTUPINFOEXW’ does not name a type; did you mean ‘STARTUPINFOW’?
220 | STARTUPINFOEXW startup_info{{sizeof(STARTUPINFOEXW), nullptr, nullptr, nullptr,
| ^~~~~~~~~~~~~~
| STARTUPINFOW
./boost/process/v2/windows/default_launcher.hpp: In member function
‘boost::process::v2::windows::default_launcher::enable_init
On 9/25/24 20:03, Martin Vejbora via Boost wrote:
I wanted to ask, is the cross-testing of Boost library supported, are you aware of some examples where it's being used?
I don't think we test cross-compilation, and I'm not sure how well-supported it is in Boost.Build. Low-level libraries like Boost.Context may not support cross-compilation because they select implementation based on the platform and toolset, and I'm not sure Boost.Build provides separate features for the host and target systems for these parameters. For example, there are features like <architecture>, <address-model> and <binary-format>, and I'm not sure if those describe the host or the target system and whether there are the other counterparts.
b) Process errors:
gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/ boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/ext/exe.o /home/vejby/boost-build/libs/process/src/ext/exe.cpp: In function ‘boost::filesystem::path boost::process::v2::ext::exe (HANDLE, boost::system::error_code&)’: /home/vejby/boost-build/libs/process/src/ext/exe.cpp:78:9: error: ‘QueryFullProcessImageNameW’ was not declared in this scope 78 | if (QueryFullProcessImageNameW(proc, 0, buffer, &size)) | ^~~~~~~~~~~~~~~~~~~~~~~~~~
"x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"."
-------------------------------------------------------------------------------
gcc.compile.c++ bin.v2/libs/process/build/gcc-10/debug/x86_64/ boost.process.fs-boost/link-static/target-os-windows/threadapi-win32/ threading-multi/visibility-hidden/windows/default_launcher.o In file included from /home/vejby/boost-build/libs/process/src/windows/ default_launcher.cpp:16: ./boost/process/v2/windows/default_launcher.hpp:220:3: error: ‘STARTUPINFOEXW’ does not name a type; did you mean ‘STARTUPINFOW’? 220 | STARTUPINFOEXW startup_info{{sizeof(STARTUPINFOEXW), nullptr, nullptr, nullptr, | ^~~~~~~~~~~~~~ | STARTUPINFOW
"x86_64-w64-mingw32-g++" -fvisibility-inlines-hidden -m64 -O0 -fno-inline -Wall -g -fvisibility=hidden -DBOOST_ALL_NO_LIB=1 -DBOOST_ASIO_NO_DEPRECATED -DBOOST_ATOMIC_STATIC_LINK=1 -DBOOST_FILESYSTEM_NO_LIB=1 -DBOOST_FILESYSTEM_STATIC_LINK=1 -DBOOST_PROCESS_SOURCE=1 -DBOOST_REGEX_NO_LIB=1 -DBOOST_SYSTEM_NO_LIB=1 -DBOOST_SYSTEM_STATIC_LINK=1 -DWIN32_LEAN_AND_MEAN -I"."
These and similar errors may be caused by the missing _WIN32_WINNT define to a sufficiently high target Windows version. AFAIR, MinGW-w64 defaults to some low target Windows version and disables many definitions that appeared in Windows Vista and later. I'm not the maintainer and I don't know whether Boost.Process expects the user to define the macro, but I think it would make sense to define it in Boost.Process, since clearly there is a minimum supported Windows version. You should probably create an issue for Boost.Process: https://github.com/boostorg/process/issues
чт, 26 сент. 2024 г. в 02:58, Andrey Semashev via Boost
On 9/25/24 20:03, Martin Vejbora via Boost wrote:
I wanted to ask, is the cross-testing of Boost library supported, are you aware of some examples where it's being used?
I don't think we test cross-compilation, and I'm not sure how well-supported it is in Boost.Build.
We don't usually test cross-compilation, but for posterity I did test the latest release a little bit. You can see my findings here: https://lists.boost.org/Archives/boost/2024/08/257473.php. I actually tested the exact configuration Martin used: x86_64-w64-mingw32-g++-win32 on Ubuntu.
Low-level libraries like Boost.Context may not support cross-compilation because they select implementation based on the platform and toolset, and I'm not sure Boost.Build provides separate features for the host and target systems for these parameters.
For example, there are features like <architecture>, <address-model> and <binary-format>, and I'm not sure if those describe the host or the target system and whether there are the other counterparts.
By default B2 doesn't do much guessing what your target configuration is (although Boost itself tries at least to guess target architecture and address model). During cross-compilation guessing is actually rarely something anyone wants, so you want to be as explicit as possible. Boost.Config defines several features (this is B2 term for unbound properties, whereas a bound property is called a "property"). To more specifically determine your target configuration. It uses those features to choose assembler sources to use. It also tries to guess defaults for those features, but those defaults are based on your _host_ configuration. When you are cross-compiling, they will very likely be wrong. Which is the case here. So, this is what I used to cross-build Context: # user-config.jam using gcc : 13_w32 : x86_64-w64-mingw32-g++-win32 : : <target-os>windows <address-model>64 <architecture>x86 ; ./b2 install --prefix=build/cross-ms target-os=windows address-model=64 architecture=x86 binary-format=pe abi=ms toolset=gcc-13_w32 --with-context
b) Process errors:
Again, in my experiment during the latest release prep I discovered that Boost.Process likely has a build script bug. But it appears the bug has already been fixed in develop. So, I checked the 1.86 release, and after I changed in libs/process/build/Jamfile if [ os.name ] = NT { lib shell32 ; lib advapi32 ; lib ntdll ; lib user32 ; explicit shell32 advapi32 ntdll user32 ; } to lib shell32 ; lib advapi32 ; lib ntdll ; lib user32 ; explicit shell32 advapi32 ntdll user32 ; I could build Boost.Process locally. On the other hand, your build errors are not build system errors, but compilation errors. As Andrey pointed out, this is because _WIN32_WINNT is not defined or defined to be a value too low for Process. Locally my MinGW defaults it to 0x0A00 (Windows 10). It appears Boost.Process requires at least 0x0600 (Windows Vista), although I couldn't find that requirement in its documentation. Boost.Context also appears to require a minimum version of Windows API: 0x0601 (Windows 7), which I also couldn't find in the docs. Unlike Boost.Process it actually defines that macro for the user, forcefully. If you request a higher value for that macro in your build request, it will be redefined, but the compiler will emit a warning. In the end, I arrived to this invocation: ./b2 install --prefix=build/cross-ms target-os=windows address-model=64 architecture=x86 binary-format=pe abi=ms toolset=gcc-13_w32 define=_WIN32_WINNT=0x0A00 --with-process --with-context
Thank you both! I was able to build most of the modules with your insights. I'll wrap up and share the commands here if someone would want to do the same in the future.
b) Process errors:
Again, in my experiment during the latest release prep I discovered that Boost.Process likely has a build script bug. But it appears the bug has already been fixed in develop. So, I checked the 1.86 release, and after I changed in libs/process/build/Jamfile
Fixing this build script bug was necessary. I switched to develop branch inside of Boost.Process module to get the patched version.
For example, there are features like <architecture>, <address-model> and <binary-format>, and I'm not sure if those describe the host or the target system and whether there are the other counterparts.
During cross-compilation guessing is actually rarely something anyone wants, so you want to be as explicit as possible. It uses those features to choose assembler sources to use. It also tries to guess defaults for those features, but those defaults are based on your _host_ configuration. When you are cross-compiling, they will very likely be wrong. Which is the case here.
Indeed <architecture>, <address-model> and <binary-format> has to be specified, so that the correct assembler code is chosen.
These and similar errors may be caused by the missing _WIN32_WINNT define to a sufficiently high target Windows version. AFAIR, MinGW-w64 defaults to some low target Windows version and disables many definitions that appeared in Windows Vista and later. I'm not the maintainer and I don't know whether Boost.Process expects the user to define the macro, but I think it would make sense to define it in Boost.Process, since clearly there is a minimum supported Windows version. You should probably create an issue for Boost.Process: https://github.com/boostorg/process/issues
As Andrey pointed out, this is because _WIN32_WINNT is not defined or defined to be a value too low for Process. Locally my MinGW defaults it to 0x0A00 (Windows 10). It appears Boost.Process requires at least 0x0600 (Windows Vista), although I couldn't find that requirement in its documentation.
I created an issue in Process module: https://github.com/boostorg/process/issues/403 But for now, I needed to define _WIN32_WINNT in command line as suggested by Andrey and Дмитрий. It seems like MinGW which is default from package manager on Ubuntu 22.04 defaults _WIN32_WINNT to 0x0502 (which is Win XP SP2). I had to define it in my invocation to 0x0601 (Win 7) which seems to be the newest included in my MinGW. So overall I used: # user-config.jam using gcc : 10 : x86_64-w64-mingw32-g++ : : <target-os>windows <address-model>64 <architecture>x86 ; ./b2 install --prefix=./boost-x64 target-os=windows address-model=64 architecture=x86 binary-format=pe abi=ms toolset=gcc-10 define=_WIN32_WINNT=0x0601 This builds successfully all modules except of Stacktrace but that was enough for me, so I didn't investigate it more closely. Instead, I moved to building on ARM64. I'm using our WIP toolchain from https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build and I'm able to build all modules except of json and charconv which use _umul128 which is not available on ARM64, so that's expected. I'm using this: # user-config.jam using gcc : 15 : ~//cross-aarch64-w64-mingw32-msvcrt/bin/aarch64-w64-mingw32-g++ : : <target-os>windows <address-model>64 <architecture>arm ; ./b2 install --prefix=./boost-arm64 target-os=windows address-model=64 architecture=arm binary-format=pe abi=aapcs toolset=gcc-15 define=_WIN32_WINNT=0x0A00
Sorry for corrupted formatting in the previous email, I hope It will be better now. Thank you both! I was able to build most of the modules with your insights. I'll wrap up and share the commands here if someone would want to do the same in the future.
b) Process errors:
Again, in my experiment during the latest release prep I discovered that Boost.Process likely has a build script bug. But it appears the bug has already been fixed in develop. So, I checked the 1.86 release, and after I changed in libs/process/build/Jamfile
Fixing this build script bug was necessary. I switched to develop branch inside of Boost.Process module to get the patched version.
For example, there are features like <architecture>, <address-model> and <binary-format>, and I'm not sure if those describe the host or the target system and whether there are the other counterparts.
During cross-compilation guessing is actually rarely something anyone wants, so you want to be as explicit as possible. It uses those features to choose assembler sources to use. It also tries to guess defaults for those features, but those defaults are based on your _host_ configuration. When you are cross-compiling, they will very likely be wrong. Which is the case here.
Indeed <architecture>, <address-model> and <binary-format> has to be specified, so that the correct assembler code is chosen.
These and similar errors may be caused by the missing _WIN32_WINNT define to a sufficiently high target Windows version. AFAIR, MinGW-w64 defaults to some low target Windows version and disables many definitions that appeared in Windows Vista and later. I'm not the maintainer and I don't know whether Boost.Process expects the user to define the macro, but I think it would make sense to define it in Boost.Process, since clearly there is a minimum supported Windows version. You should probably create an issue for Boost.Process: https://github.com/boostorg/process/issues
As Andrey pointed out, this is because _WIN32_WINNT is not defined or defined to be a value too low for Process. Locally my MinGW defaults it to 0x0A00 (Windows 10). It appears Boost.Process requires at least 0x0600 (Windows Vista), although I couldn't find that requirement in its documentation.
I created an issue in Process module:
https://github.com/boostorg/process/issues/403
But for now, I needed to define _WIN32_WINNT in command
line as suggested by Andrey and Дмитрий. It seems like MinGW
which is default from package manager on Ubuntu 22.04 defaults
_WIN32_WINNT to 0x0502 (which is Win XP SP2). I had to define
it in my invocation to 0x0601 (Win 7) which seems to be the newest
included in my MinGW. So overall I used:
# user-config.jam
using gcc : 10 : x86_64-w64-mingw32-g++ : :
<target-os>windows <address-model>64 <architecture>x86 ;
./b2 install --prefix=./boost-x64 target-os=windows
address-model=64 architecture=x86 binary-format=pe abi=ms
toolset=gcc-10 define=_WIN32_WINNT=0x0601
This builds successfully all modules except of Stacktrace but
that was enough for me, so I didn't investigate it more closely.
Instead, I moved to building on ARM64. I'm using our WIP toolchain
from https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build
and I'm able to build all modules except of json and charconv
which use _umul128 which is not available on ARM64, so that's
expected. I'm using this:
# user-config.jam
using gcc : 15 : ~//cross-aarch64-w64-mingw32-msvcrt/bin/aarch64-w64-mingw32-g++ : :
<target-os>windows <address-model>64 <architecture>arm ;
./b2 install --prefix=./boost-arm64 target-os=windows
address-model=64 architecture=arm binary-format=pe abi=aapcs
toolset=gcc-15 define=_WIN32_WINNT=0x0A00
________________________________
From: Martin Vejbora
b) Process errors:
Again, in my experiment during the latest release prep I discovered that Boost.Process likely has a build script bug. But it appears the bug has already been fixed in develop. So, I checked the 1.86 release, and after I changed in libs/process/build/Jamfile
Fixing this build script bug was necessary. I switched to develop branch inside of Boost.Process module to get the patched version.
For example, there are features like <architecture>, <address-model> and <binary-format>, and I'm not sure if those describe the host or the target system and whether there are the other counterparts.
During cross-compilation guessing is actually rarely something anyone wants, so you want to be as explicit as possible. It uses those features to choose assembler sources to use. It also tries to guess defaults for those features, but those defaults are based on your _host_ configuration. When you are cross-compiling, they will very likely be wrong. Which is the case here.
Indeed <architecture>, <address-model> and <binary-format> has to be specified, so that the correct assembler code is chosen.
These and similar errors may be caused by the missing _WIN32_WINNT define to a sufficiently high target Windows version. AFAIR, MinGW-w64 defaults to some low target Windows version and disables many definitions that appeared in Windows Vista and later. I'm not the maintainer and I don't know whether Boost.Process expects the user to define the macro, but I think it would make sense to define it in Boost.Process, since clearly there is a minimum supported Windows version. You should probably create an issue for Boost.Process: https://github.com/boostorg/process/issues
As Andrey pointed out, this is because _WIN32_WINNT is not defined or defined to be a value too low for Process. Locally my MinGW defaults it to 0x0A00 (Windows 10). It appears Boost.Process requires at least 0x0600 (Windows Vista), although I couldn't find that requirement in its documentation.
I created an issue in Process module: https://github.com/boostorg/process/issues/403 But for now, I needed to define _WIN32_WINNT in command line as suggested by Andrey and Дмитрий. It seems like MinGW which is default from package manager on Ubuntu 22.04 defaults _WIN32_WINNT to 0x0502 (which is Win XP SP2). I had to define it in my invocation to 0x0601 (Win 7) which seems to be the newest included in my MinGW. So overall I used: # user-config.jam using gcc : 10 : x86_64-w64-mingw32-g++ : : <target-os>windows <address-model>64 <architecture>x86 ; ./b2 install --prefix=./boost-x64 target-os=windows address-model=64 architecture=x86 binary-format=pe abi=ms toolset=gcc-10 define=_WIN32_WINNT=0x0601 This builds successfully all modules except of Stacktrace but that was enough for me, so I didn't investigate it more closely. Instead, I moved to building on ARM64. I'm using our WIP toolchain from https://github.com/Windows-on-ARM-Experiments/mingw-woarm64-build and I'm able to build all modules except of json and charconv which use _umul128 which is not available on ARM64, so that's expected. I'm using this: # user-config.jam using gcc : 15 : ~//cross-aarch64-w64-mingw32-msvcrt/bin/aarch64-w64-mingw32-g++ : : <target-os>windows <address-model>64 <architecture>arm ; ./b2 install --prefix=./boost-arm64 target-os=windows address-model=64 architecture=arm binary-format=pe abi=aapcs toolset=gcc-15 define=_WIN32_WINNT=0x0A00
participants (3)
-
Andrey Semashev -
Martin Vejbora -
Дмитрий Архипов