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