Re: [EXTERNAL] Re: Boost cross-compilation and testing (Linux -> Windows)

From: Martin Vejbora (mvejbora_at_[hidden])
Date: 2024-10-10 15:49:30

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