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

From: Дмитрий Архипов (grisumbras_at_[hidden])
Date: 2024-09-26 10:35:10

чт, 26 сент. 2024 г. в 02:58, Andrey Semashev via Boost <boost_at_[hidden]>:
>
> 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