Prefer target-os when detecting the default binary-format

[uilianries]

Greetings! 👋

Companion fix to #334, which fixeds <abi> default to derive
from the deduced target architecture instead of the host CPU, the <binary-format>
has the same class of problem: its default is derived purely from the host
[ os.name ], never from the deduced target, and passing target-os does not
correct it.

This breaks cross-OS builds - for instance building from a macOS or Windows
host to Android/Linux. Instead of a b2 "No best alternative" message, the
wrong-but-existing <toolset>clang alternative is picked anyway and fails at
the assembler/linker stage, e.g.:

ld.lld: error: bin.v2/libs/context/.../asm/make_arm64_aapcs_macho_gas.o: unknown file type> ld.lld: error: bin.v2/libs/context/.../asm/jump_arm64_aapcs_macho_gas.o: unknown file type
ld.lld: error: bin.v2/libs/context/.../asm/ontop_arm64_aapcs_macho_gas.o: unknown file type
clang++: error: linker command failed with exit code 1

You can check the full build log with the error, cross-building from Mac M1 to Android here boost-1.91.0-darwin-android.log

This happens because binary-format defaulted to mach-o on a macOS host
(or pe on a Windows host) regardless of target-os=android, so Context
picked make_arm64_aapcs_macho_gas.S / *_pe_armclang.S instead of the
ELF variant expected by the Android NDK's clang.

---

This PR makes b2 derive Context's binary-format from the deduced
<target-os>, but preserves the current implementation as fallback for native builds.

With this change, Context picks the expected and correct files like
make_arm64_aapcs_elf_gas.S and jump_arm64_aapcs_elf_gas.S. The built libboost_context.so is a valid ELF shared object for the target:

$ file libboost_context.so
libboost_context.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped

You can check the same build as before, but using this proposed patch. It builds Boost Context with success now: boost-1.91.0-darwin-android-patched.log

Steps to Reproduce

• Download Boost 1.91.0: https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2
• Build using b2 with the Android NDK's clang, e.g.:

export CXX=".../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++"
export CXXFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
export LDFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
b2 install --prefix=/tmp/boost-install --user-config=user-config.jam toolset=clang target-os=android architecture=arm address-model=64 abi=aapcs --with-context

• user-config.jam:

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) ;

On my local machine, I'm using /Users/uilian/Library/Android/sdk/ndk/30.0.15729638/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++, just to let you know. My NDK is installed via Android Studio to avoid any mistakes.

Let me know if you need more information about this case or about this proposal. Regards!

[olk]

ty

[uilianries]

@olk Thank you for reviewing! 👋

[uilianries]

Greetings! 👋

Companion fix to #334, which fixeds <abi> default to derive
from the deduced target architecture instead of the host CPU, the <binary-format>
has the same class of problem: its default is derived purely from the host
[ os.name ], never from the deduced target, and passing target-os does not
correct it.

This breaks cross-OS builds - for instance building from a macOS or Windows
host to Android/Linux. Instead of a b2 "No best alternative" message, the
wrong-but-existing <toolset>clang alternative is picked anyway and fails at
the assembler/linker stage, e.g.:

ld.lld: error: bin.v2/libs/context/.../asm/make_arm64_aapcs_macho_gas.o: unknown file type> ld.lld: error: bin.v2/libs/context/.../asm/jump_arm64_aapcs_macho_gas.o: unknown file type
ld.lld: error: bin.v2/libs/context/.../asm/ontop_arm64_aapcs_macho_gas.o: unknown file type
clang++: error: linker command failed with exit code 1

You can check the full build log with the error, cross-building from Mac M1 to Android here boost-1.91.0-darwin-android.log

This happens because binary-format defaulted to mach-o on a macOS host
(or pe on a Windows host) regardless of target-os=android, so Context
picked make_arm64_aapcs_macho_gas.S / *_pe_armclang.S instead of the
ELF variant expected by the Android NDK's clang.

---

This PR makes b2 derive Context's binary-format from the deduced
<target-os>, but preserves the current implementation as fallback for native builds.

With this change, Context picks the expected and correct files like
make_arm64_aapcs_elf_gas.S and jump_arm64_aapcs_elf_gas.S. The built libboost_context.so is a valid ELF shared object for the target:

$ file libboost_context.so
libboost_context.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped

You can check the same build as before, but using this proposed patch. It builds Boost Context with success now: boost-1.91.0-darwin-android-patched.log

Steps to Reproduce

• Download Boost 1.91.0: https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2
• Build using b2 with the Android NDK's clang, e.g.:

export CXX=".../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++"
export CXXFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
export LDFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
b2 install --prefix=/tmp/boost-install --user-config=user-config.jam toolset=clang target-os=android architecture=arm address-model=64 abi=aapcs --with-context

• user-config.jam:

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) ;

On my local machine, I'm using /Users/uilian/Library/Android/sdk/ndk/30.0.15729638/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++, just to let you know. My NDK is installed via Android Studio to avoid any mistakes.

Let me know if you need more information about this case or about this proposal. Regards!

[olk]

ty

[uilianries]

@olk Thank you for reviewing! 👋

[uilianries]

Greetings! 👋

Companion fix to #334, which fixeds <abi> default to derive
from the deduced target architecture instead of the host CPU, the <binary-format>
has the same class of problem: its default is derived purely from the host
[ os.name ], never from the deduced target, and passing target-os does not
correct it.

This breaks cross-OS builds - for instance building from a macOS or Windows
host to Android/Linux. Instead of a b2 "No best alternative" message, the
wrong-but-existing <toolset>clang alternative is picked anyway and fails at
the assembler/linker stage, e.g.:

ld.lld: error: bin.v2/libs/context/.../asm/make_arm64_aapcs_macho_gas.o: unknown file type> ld.lld: error: bin.v2/libs/context/.../asm/jump_arm64_aapcs_macho_gas.o: unknown file type
ld.lld: error: bin.v2/libs/context/.../asm/ontop_arm64_aapcs_macho_gas.o: unknown file type
clang++: error: linker command failed with exit code 1

You can check the full build log with the error, cross-building from Mac M1 to Android here boost-1.91.0-darwin-android.log

This happens because binary-format defaulted to mach-o on a macOS host
(or pe on a Windows host) regardless of target-os=android, so Context
picked make_arm64_aapcs_macho_gas.S / *_pe_armclang.S instead of the
ELF variant expected by the Android NDK's clang.

---

This PR makes b2 derive Context's binary-format from the deduced
<target-os>, but preserves the current implementation as fallback for native builds.

With this change, Context picks the expected and correct files like
make_arm64_aapcs_elf_gas.S and jump_arm64_aapcs_elf_gas.S. The built libboost_context.so is a valid ELF shared object for the target:

$ file libboost_context.so
libboost_context.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped

You can check the same build as before, but using this proposed patch. It builds Boost Context with success now: boost-1.91.0-darwin-android-patched.log

Steps to Reproduce

• Download Boost 1.91.0: https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2
• Build using b2 with the Android NDK's clang, e.g.:

export CXX=".../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++"
export CXXFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
export LDFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
b2 install --prefix=/tmp/boost-install --user-config=user-config.jam toolset=clang target-os=android architecture=arm address-model=64 abi=aapcs --with-context

• user-config.jam:

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) ;

On my local machine, I'm using /Users/uilian/Library/Android/sdk/ndk/30.0.15729638/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++, just to let you know. My NDK is installed via Android Studio to avoid any mistakes.

Let me know if you need more information about this case or about this proposal. Regards!

[olk]

ty

[uilianries]

@olk Thank you for reviewing! 👋

[uilianries]

Greetings! 👋

Companion fix to #334, which fixeds <abi> default to derive
from the deduced target architecture instead of the host CPU, the <binary-format>
has the same class of problem: its default is derived purely from the host
[ os.name ], never from the deduced target, and passing target-os does not
correct it.

This breaks cross-OS builds - for instance building from a macOS or Windows
host to Android/Linux. Instead of a b2 "No best alternative" message, the
wrong-but-existing <toolset>clang alternative is picked anyway and fails at
the assembler/linker stage, e.g.:

ld.lld: error: bin.v2/libs/context/.../asm/make_arm64_aapcs_macho_gas.o: unknown file type> ld.lld: error: bin.v2/libs/context/.../asm/jump_arm64_aapcs_macho_gas.o: unknown file type
ld.lld: error: bin.v2/libs/context/.../asm/ontop_arm64_aapcs_macho_gas.o: unknown file type
clang++: error: linker command failed with exit code 1

You can check the full build log with the error, cross-building from Mac M1 to Android here boost-1.91.0-darwin-android.log

This happens because binary-format defaulted to mach-o on a macOS host
(or pe on a Windows host) regardless of target-os=android, so Context
picked make_arm64_aapcs_macho_gas.S / *_pe_armclang.S instead of the
ELF variant expected by the Android NDK's clang.

---

This PR makes b2 derive Context's binary-format from the deduced
<target-os>, but preserves the current implementation as fallback for native builds.

With this change, Context picks the expected and correct files like
make_arm64_aapcs_elf_gas.S and jump_arm64_aapcs_elf_gas.S. The built libboost_context.so is a valid ELF shared object for the target:

$ file libboost_context.so
libboost_context.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped

You can check the same build as before, but using this proposed patch. It builds Boost Context with success now: boost-1.91.0-darwin-android-patched.log

Steps to Reproduce

• Download Boost 1.91.0: https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2
• Build using b2 with the Android NDK's clang, e.g.:

export CXX=".../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++"
export CXXFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
export LDFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
b2 install --prefix=/tmp/boost-install --user-config=user-config.jam toolset=clang target-os=android architecture=arm address-model=64 abi=aapcs --with-context

• user-config.jam:

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) ;

On my local machine, I'm using /Users/uilian/Library/Android/sdk/ndk/30.0.15729638/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++, just to let you know. My NDK is installed via Android Studio to avoid any mistakes.

Let me know if you need more information about this case or about this proposal. Regards!

[olk]

ty

[uilianries]

@olk Thank you for reviewing! 👋

[uilianries]

Greetings! 👋

Companion fix to #334, which fixeds <abi> default to derive
from the deduced target architecture instead of the host CPU, the <binary-format>
has the same class of problem: its default is derived purely from the host
[ os.name ], never from the deduced target, and passing target-os does not
correct it.

This breaks cross-OS builds - for instance building from a macOS or Windows
host to Android/Linux. Instead of a b2 "No best alternative" message, the
wrong-but-existing <toolset>clang alternative is picked anyway and fails at
the assembler/linker stage, e.g.:

ld.lld: error: bin.v2/libs/context/.../asm/make_arm64_aapcs_macho_gas.o: unknown file type> ld.lld: error: bin.v2/libs/context/.../asm/jump_arm64_aapcs_macho_gas.o: unknown file type
ld.lld: error: bin.v2/libs/context/.../asm/ontop_arm64_aapcs_macho_gas.o: unknown file type
clang++: error: linker command failed with exit code 1

You can check the full build log with the error, cross-building from Mac M1 to Android here boost-1.91.0-darwin-android.log

This happens because binary-format defaulted to mach-o on a macOS host
(or pe on a Windows host) regardless of target-os=android, so Context
picked make_arm64_aapcs_macho_gas.S / *_pe_armclang.S instead of the
ELF variant expected by the Android NDK's clang.

---

This PR makes b2 derive Context's binary-format from the deduced
<target-os>, but preserves the current implementation as fallback for native builds.

With this change, Context picks the expected and correct files like
make_arm64_aapcs_elf_gas.S and jump_arm64_aapcs_elf_gas.S. The built libboost_context.so is a valid ELF shared object for the target:

$ file libboost_context.so
libboost_context.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped

You can check the same build as before, but using this proposed patch. It builds Boost Context with success now: boost-1.91.0-darwin-android-patched.log

Steps to Reproduce

• Download Boost 1.91.0: https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2
• Build using b2 with the Android NDK's clang, e.g.:

export CXX=".../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++"
export CXXFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
export LDFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
b2 install --prefix=/tmp/boost-install --user-config=user-config.jam toolset=clang target-os=android architecture=arm address-model=64 abi=aapcs --with-context

• user-config.jam:

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) ;

On my local machine, I'm using /Users/uilian/Library/Android/sdk/ndk/30.0.15729638/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++, just to let you know. My NDK is installed via Android Studio to avoid any mistakes.

Let me know if you need more information about this case or about this proposal. Regards!

[olk]

ty

[uilianries]

@olk Thank you for reviewing! 👋

[uilianries]

Greetings! 👋

Companion fix to #334, which fixeds <abi> default to derive
from the deduced target architecture instead of the host CPU, the <binary-format>
has the same class of problem: its default is derived purely from the host
[ os.name ], never from the deduced target, and passing target-os does not
correct it.

This breaks cross-OS builds - for instance building from a macOS or Windows
host to Android/Linux. Instead of a b2 "No best alternative" message, the
wrong-but-existing <toolset>clang alternative is picked anyway and fails at
the assembler/linker stage, e.g.:

ld.lld: error: bin.v2/libs/context/.../asm/make_arm64_aapcs_macho_gas.o: unknown file type> ld.lld: error: bin.v2/libs/context/.../asm/jump_arm64_aapcs_macho_gas.o: unknown file type
ld.lld: error: bin.v2/libs/context/.../asm/ontop_arm64_aapcs_macho_gas.o: unknown file type
clang++: error: linker command failed with exit code 1

You can check the full build log with the error, cross-building from Mac M1 to Android here boost-1.91.0-darwin-android.log

This happens because binary-format defaulted to mach-o on a macOS host
(or pe on a Windows host) regardless of target-os=android, so Context
picked make_arm64_aapcs_macho_gas.S / *_pe_armclang.S instead of the
ELF variant expected by the Android NDK's clang.

---

This PR makes b2 derive Context's binary-format from the deduced
<target-os>, but preserves the current implementation as fallback for native builds.

With this change, Context picks the expected and correct files like
make_arm64_aapcs_elf_gas.S and jump_arm64_aapcs_elf_gas.S. The built libboost_context.so is a valid ELF shared object for the target:

$ file libboost_context.so
libboost_context.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped

You can check the same build as before, but using this proposed patch. It builds Boost Context with success now: boost-1.91.0-darwin-android-patched.log

Steps to Reproduce

• Download Boost 1.91.0: https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2
• Build using b2 with the Android NDK's clang, e.g.:

export CXX=".../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++"
export CXXFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
export LDFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
b2 install --prefix=/tmp/boost-install --user-config=user-config.jam toolset=clang target-os=android architecture=arm address-model=64 abi=aapcs --with-context

• user-config.jam:

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) ;

On my local machine, I'm using /Users/uilian/Library/Android/sdk/ndk/30.0.15729638/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++, just to let you know. My NDK is installed via Android Studio to avoid any mistakes.

Let me know if you need more information about this case or about this proposal. Regards!

[olk]

ty

[uilianries]

@olk Thank you for reviewing! 👋

[uilianries]

Greetings! 👋

Companion fix to #334, which fixeds <abi> default to derive
from the deduced target architecture instead of the host CPU, the <binary-format>
has the same class of problem: its default is derived purely from the host
[ os.name ], never from the deduced target, and passing target-os does not
correct it.

This breaks cross-OS builds - for instance building from a macOS or Windows
host to Android/Linux. Instead of a b2 "No best alternative" message, the
wrong-but-existing <toolset>clang alternative is picked anyway and fails at
the assembler/linker stage, e.g.:

ld.lld: error: bin.v2/libs/context/.../asm/make_arm64_aapcs_macho_gas.o: unknown file type> ld.lld: error: bin.v2/libs/context/.../asm/jump_arm64_aapcs_macho_gas.o: unknown file type
ld.lld: error: bin.v2/libs/context/.../asm/ontop_arm64_aapcs_macho_gas.o: unknown file type
clang++: error: linker command failed with exit code 1

You can check the full build log with the error, cross-building from Mac M1 to Android here boost-1.91.0-darwin-android.log

This happens because binary-format defaulted to mach-o on a macOS host
(or pe on a Windows host) regardless of target-os=android, so Context
picked make_arm64_aapcs_macho_gas.S / *_pe_armclang.S instead of the
ELF variant expected by the Android NDK's clang.

---

This PR makes b2 derive Context's binary-format from the deduced
<target-os>, but preserves the current implementation as fallback for native builds.

With this change, Context picks the expected and correct files like
make_arm64_aapcs_elf_gas.S and jump_arm64_aapcs_elf_gas.S. The built libboost_context.so is a valid ELF shared object for the target:

$ file libboost_context.so
libboost_context.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped

You can check the same build as before, but using this proposed patch. It builds Boost Context with success now: boost-1.91.0-darwin-android-patched.log

Steps to Reproduce

• Download Boost 1.91.0: https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2
• Build using b2 with the Android NDK's clang, e.g.:

export CXX=".../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++"
export CXXFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
export LDFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
b2 install --prefix=/tmp/boost-install --user-config=user-config.jam toolset=clang target-os=android architecture=arm address-model=64 abi=aapcs --with-context

• user-config.jam:

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) ;

On my local machine, I'm using /Users/uilian/Library/Android/sdk/ndk/30.0.15729638/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++, just to let you know. My NDK is installed via Android Studio to avoid any mistakes.

Let me know if you need more information about this case or about this proposal. Regards!

[olk]

ty

[uilianries]

@olk Thank you for reviewing! 👋

[uilianries]

Greetings! 👋

Companion fix to #334, which fixeds <abi> default to derive
from the deduced target architecture instead of the host CPU, the <binary-format>
has the same class of problem: its default is derived purely from the host
[ os.name ], never from the deduced target, and passing target-os does not
correct it.

This breaks cross-OS builds - for instance building from a macOS or Windows
host to Android/Linux. Instead of a b2 "No best alternative" message, the
wrong-but-existing <toolset>clang alternative is picked anyway and fails at
the assembler/linker stage, e.g.:

ld.lld: error: bin.v2/libs/context/.../asm/make_arm64_aapcs_macho_gas.o: unknown file type> ld.lld: error: bin.v2/libs/context/.../asm/jump_arm64_aapcs_macho_gas.o: unknown file type
ld.lld: error: bin.v2/libs/context/.../asm/ontop_arm64_aapcs_macho_gas.o: unknown file type
clang++: error: linker command failed with exit code 1

You can check the full build log with the error, cross-building from Mac M1 to Android here boost-1.91.0-darwin-android.log

This happens because binary-format defaulted to mach-o on a macOS host
(or pe on a Windows host) regardless of target-os=android, so Context
picked make_arm64_aapcs_macho_gas.S / *_pe_armclang.S instead of the
ELF variant expected by the Android NDK's clang.

---

This PR makes b2 derive Context's binary-format from the deduced
<target-os>, but preserves the current implementation as fallback for native builds.

With this change, Context picks the expected and correct files like
make_arm64_aapcs_elf_gas.S and jump_arm64_aapcs_elf_gas.S. The built libboost_context.so is a valid ELF shared object for the target:

$ file libboost_context.so
libboost_context.so: ELF 64-bit LSB shared object, ARM aarch64, version 1 (SYSV), dynamically linked, not stripped

You can check the same build as before, but using this proposed patch. It builds Boost Context with success now: boost-1.91.0-darwin-android-patched.log

Steps to Reproduce

• Download Boost 1.91.0: https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2
• Build using b2 with the Android NDK's clang, e.g.:

export CXX=".../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++"
export CXXFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
export LDFLAGS="--sysroot=.../ndk/<version>/toolchains/llvm/prebuilt/darwin-x86_64/sysroot"
b2 install --prefix=/tmp/boost-install --user-config=user-config.jam toolset=clang target-os=android architecture=arm address-model=64 abi=aapcs --with-context

• user-config.jam:

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) ;

On my local machine, I'm using /Users/uilian/Library/Android/sdk/ndk/30.0.15729638/toolchains/llvm/prebuilt/darwin-x86_64/bin/aarch64-linux-android21-clang++, just to let you know. My NDK is installed via Android Studio to avoid any mistakes.

Let me know if you need more information about this case or about this proposal. Regards!

[olk]

ty

[uilianries]

@olk Thank you for reviewing! 👋