[fix] clang-linux - generate Windows import libraries when linking shared libraries

[uilianries]

Proposed changes

Hello all! 👋

When building a shared library with toolset=clang (routed to clang-linux) and target-os=windows, plus MSYS2 clang/mingw64 toolchain, the linker only ever produces the .dll. No import libraries are produced, so nothing else can link against it:

clang-linux.link.dll bin.v2\libs\atomic\...\boost_atomic.dll

However, the same source built with toolset=gcc on the same MSYS2 host, which correctly produces both:

gcc.link.dll bin.v2\libs\atomic\...\boost_atomic.dll bin.v2\libs\atomic\...\libboost_atomic.dll.a

I used Boost 1.92.0 to validate the case, but https://github.com/bfgroup/b2 main branch keeps the same behavior for this part.

You can see my full build logs here with these explained scenarios:

• Windows + MSYS2 + GCC + Shared: boost-1.92.0-windows-msys2-gcc-shared.log
• Windows + MSYS2 + Clang + Shared: boost-1.92.0-windows-msys2-clang-shared.log

I only observe such a problem with shared, for static, it works fine.

---

Doing a quick check in clang-linux.jam, I can see:

toolset.inherit-generators clang-linux
    <toolset>clang <toolset-clang:platform>linux : gcc
  : gcc.mingw.link gcc.mingw.link.dll gcc.cygwin.link gcc.cygwin.link.dll ;

The clang-linux clones its generators from gcc, but this line excludes gcc.mingw.link and gcc.mingw.link.dll, which are conditioned on <target-os>windows and declare IMPORT_LIB as an output.
Still, both clang-linux.link and clang-linux.link.dll support producing an import library. Only the generator that would request the second output was missing.

This PR removes gcc.mingw.link and gcc.mingw.link.dll from this exclusion list (I didn't test/consider Cygwin), so giving back the possibility of producing import libraries.

After applying this patch directly in Boost 1.92.0 source and rebuilding Boost.Atomic with the same setup, both files are produced as expected. Please see my full build log: boost-1.92.0-windows-msys2-clang-shared-patched.log

I also updated is_implib_expected() (it no longer excludes clang/clang-linux on target-os=windows) and mocks to expect --out-implib and link the exe against the import lib instead of the raw .dll.

Steps to Reproduce

On Windows, with MSYS2 clang/mingw64 listed on PATH:

set "PATH=C:\msys64\mingw64\bin;%PATH%"
wget https://archives.boost.io/release/1.92.0/source/boost_1_92_0.zip
unzip boost_1_92_0.zip
cd boost_1_92_0/
bootstrap.bat
echo using clang : : clang++.exe ; > user-config.jam
b2 --with-atomic toolset=clang target-os=windows link=shared threading=multi --user-config=user-config.jam --prefix=C:\tmp\boost-prefix install
dir C:\tmp\boost-prefix
dir C:\tmp\boost-prefix

Environment

B2: 5.5.3 (OS=NT, jobs=12)
OS: Windows 10
Compiler: clang version 20.1.3 - Target: x86_64-w64-windows-gnu - Thread model: posix

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

I noted this logic is present in clang-linux.jam for ages (2010), not sure if there was a limitation in the past, but for Boost 1.92.0 seems to be working in this scenario with MSYS2 + Clang.

[uilianries]

Appveyor failed due to a timeout, not because of this patch.