Fix cross-build ABI default to use deduced target architecture#334
Open
uilianries wants to merge 1 commit into
Open
Fix cross-build ABI default to use deduced target architecture#334uilianries wants to merge 1 commit into
uilianries wants to merge 1 commit into
Conversation
Signed-off-by: Uilian Ries <uilianries@gmail.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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-modelandbinary-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-osproperty 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 explicitabiin b2:No assembly is compiled: The
libboost_contextlinks onlyfcontext.cppand 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 passingabi=sysvon 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.Sand 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
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!