чт, 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