Skip to content

Fix cross-build ABI default to use deduced target architecture#334

Open
uilianries wants to merge 1 commit into
boostorg:developfrom
uilianries:fix/target-os-elf
Open

Fix cross-build ABI default to use deduced target architecture#334
uilianries wants to merge 1 commit into
boostorg:developfrom
uilianries:fix/target-os-elf

Conversation

@uilianries

Copy link
Copy Markdown

Greetings! 👋

Conan.io maintainer here! We have kept Boost since version 1.6x and the current Conan recipe is super complex to maintain. We have been investigating some tweaks to simplify it.

The Context documentation still points to being explicit about b2 properties like abi, address-model and binary-format, but when considering using Conan, we can pre-configure all compiler flags needed, even when cross-building, so we could bypass b2 in most cases.

In most cases, even when cross-building, we indeed only need to set target-os property and it will work, but Boost Context is different: it uses some conditions to pick the correct assembly file. However, the current implementation derives default ABI from the host CPU platform (os.platform), not from the deduced target . Passing target-os does not correct this for macOS/Linux targets, which breaks cross-building cases, for instance, building from Mac M1 (aarch64) to x86_64. It's possible to see a mismatch when trying to build without explicit abi in b2:

error: No best alternative for .../build/asm_sources with aapcs ... x86 ... mach-o ...

No assembly is compiled: The libboost_context links only fcontext.cpp and fails with undefined _make_fcontext, _jump_fcontext, _ontop_fcontext.

This is a result of picking the system ABI aapcs, as I'm running on a Mac M1, but we actually wanted sysv. You can see the full build log with the error: boost-1.91.0-osx-x86_64-clang21-release-shared.log


This PR makes b2 derive Context’s ABI from deduced target <architecture> (with host fallbacks for native builds), instead of always using the host CPU platform for ARM/MIPS: fixing cross-compiles like ARM Mac to x86_64 macOS without passing abi=sysv on the command line.

With these changes, Context picks the expected and correct files: make_x86_64_sysv_macho_gas.S, jump_x86_64_sysv_macho_gas.S, ontop_x86_64_sysv_macho_gas.S and links libboost_context, due its correct ABI deduction based on the archtecture which is listed in the compile flags, like -arch x86_64.

These changes were applied in Boost 1.91.0 to check, and it's working when cross-building from Mac M1 to Mac x86_64. Check the full build log: boost-1.91.0-osx-x86_64-clang21-release-shared-patched.log

Steps to Reproduce

export CXXFLAGS="-arch x86_64 --target=x86_64-apple-darwin"
export LDFLAGS="-arch x86_64 --target=x86_64-apple-darwin"

b2 install --prefix=/tmp/boost-install toolset=clang link=shared target-os=darwin --with-context -j10
  • My user-config.jam looks like:
import os ;
local cflags = [ os.environ CFLAGS ] ;
local cxxflags = [ os.environ CXXFLAGS ] ;
local ldflags = [ os.environ LDFLAGS ] ;
using clang :  : [ os.environ CXX ] : <compileflags>$(cflags) <cxxflags>$(cxxflags) <linkflags>$(ldflags) ;

All those variables are filled by Conan, but you can set them via environment variables as suggested.


This follows the same idea as boostorg/interprocess#35 (prefer target properties over host), but for Context the critical change is tying ABI to deduced , not to target-os on Darwin.

The CMake build in Context already gets this right: it sets ABI from CMAKE_SYSTEM_PROCESSOR (the cross-compile target), so x86_64 to sysv and the correct *_x86_64_sysv_macho_* asm files are chosen automatically.

Related to #69 and #139.

Regards!

Signed-off-by: Uilian Ries <uilianries@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant