Pick llvm-ar when using clang and present

[uilianries]

Proposed changes

Greetings! 👋

During a few and less intrusive scenario validations using Boost 1.91.0 on Windows x86_64, when trying to cross-build to Android ARMv8, was found a gap in clang-linux.jam when building a static library (Boost.Context, for instance) with toolset=clang (NDK's unified LLVM toolchain, r23+), the archive step fails:

"ar"  rsc "...\libboost_date_time.a" "...\greg_month.o"
CreateProcessA() Windows API failed: 2 - The system cannot find the file specified.

You can observe my full build log (without Conan) here: boost-1.91.0-windows-android.log

The clang-linux.jam falls back to .AR = ar ; from gcc.jam when no <archiver> option or <root>-derived path is configured. It works okay on Linux, where ar is available, but on Windows, users will need to consume from the llvm-ar available in the NDK.

This PR makes clang-linux.jam search for llvm-ar next to the resolved compiler before falling back to the ar default, so Windows to Android scenario (and any other LLVM-only, no-ar toolchain) cross-builds work without requiring an explicit <archiver> option.

I applied this patch directly to boost-1.91.0 for validation. I know it's not same commit as the latest release in b2, but this behavior is still the same in both b2 5.5.1 and that version in boost 1.91.0.

After applying my patch I can build on Windows with success: boost-1.91.0-windows-android-patched.log

Environment

• Host: Windows 10
• Target: Android - NDK 27d
• Architecture: x86-64 -> ARMv8 (Cross-building)
• Boost 1.91.0

Steps to Reproduce

• Download and extract https://archives.boost.io/release/1.91.0/source/boost_1_91_0.tar.bz2
• bootstrap.bat
• Any Android NDK (r23+, unified LLVM toolchain) on a Windows host.
• Create a similar user-config.jam:

using clang : : "C:/Users/uilia/Development/android-ndk-r27d/toolchains/llvm/prebuilt/windows-x86_64/bin/aarch64-linux-android27-clang++.cmd" ;

• b2 install --user-config=user-config.jam toolset=clang link=static target-os=android architecture=arm address-model=64 abi=aapcs binary-format=elf --with-context -j1

• Archiver should fail with "ar isn't found anywhere on PATH"

Types of changes

What types of changes does your code introduce?

Put an x in the boxes that apply

• Bugfix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Code style update (formatting, renaming)
• Refactoring (no functional changes, no api changes)
• Documentation content changes
• Other (please describe):

Checklist

Put an x in the boxes that apply. You can also fill these out after creating the PR. If you're unsure about any of them, don't hesitate to ask. We're here to help! This is simply a reminder of what we are going to look for before merging your code.

• I searched the discussions
• I searched the closed and open issues
• I read the contribution guidelines
• I added myself to the copyright attributions for significant changes
• I checked that tests pass locally with my changes
• I added tests that prove my fix is effective or that my feature works
• I added necessary documentation (if appropriate)

Further comments

If you are okay with this PR. Just let me know how to add a new test in case wanting to cover a regression. Regards!

[uilianries]

Thank you for your quick review! 👏