build: the Windows DLL carries its own runtime

[A13xB0]

Fixes the root cause of MeshBench#632: no emulated board can boot on Windows, because the chip model cannot be loaded.

What is wrong

build_shared linked the runtime dynamically on every platform. On Linux and macOS that is correct — libstdc++ is part of the base system and a plugin is better off sharing the host's copy. On Windows it produces a DLL that only loads inside an MSYS2 environment, and nothing that opens it has one.

Both emulators open this library at run time on an ordinary machine — QEMU through LoadLibrary, Renode through LoadLibraryW behind a P/Invoke — and there it fails:

qemu-system-xtensa.exe: sx1262: cannot load the chip model at
...\libvirtualsx1262.dll: The specified module could not be found.

The message names us rather than the dependency we are missing, which is why it reads as a corrupt or absent library. Downstream in MeshBench it surfaces three steps later still, as firmware started but never connected within 40s — a radio that never answers, because the model behind it was never loaded.

Why the artefact is not at fault, and neither is MeshBench's pipeline

Worth stating, because both were suspected first. release.yml stages exactly what build.sh produces, and MeshBench's package.yml ships exactly what it unpacks. Nothing is dropped along the way. I rebuilt v1.3.0's source locally with the unmodified flags and got a DLL with imports identical to the shipped one, so the released file is faithfully what this repo asked for. The build asked for the wrong thing.

Why not ship the runtime instead

The obvious first try, and it does not work — recorded here so nobody spends the afternoon on it. Windows resolves a dynamically loaded DLL's imports from the loading process's directory, not from the directory of the DLL being loaded. I put libstdc++-6.dll, libgcc_s_seh-1.dll and libwinpthread-1.dll next to libvirtualsx1262.dll in a real MeshBench install and the load failed identically. A copy would have to live beside every host that opens us — QEMU's bin, wherever Renode is unpacked — and be kept in step with the toolchain that built us.

-static rather than -static-libstdc++: the latter alone leaves libwinpthread-1.dll behind it, because libstdc++'s threading support pulls it in.

The change

One line of build flags, scoped to the platform that needs it, plus a guard.

	imports
before	KERNEL32.dll, msvcrt.dll, libstdc++-6.dll
after	KERNEL32.dll, msvcrt.dll

Both remaining ones are on every supported Windows. The DLL goes from 112 kB to 666 kB, which is the whole cost.

check_shared_imports fails the build on any import beyond those two. This bug looked like a green build, passing tests, an artefact of the right size and a library nothing could open — so the build saying what its own product depends on is the one thing that would have caught it. Tested in both directions, since a check nothing tests can quietly stop checking:

$ sh ./build.sh shared            # with the fix
built build/libvirtualsx1262.dll
checked build/libvirtualsx1262.dll: nothing imported beyond kernel32 and msvcrt

$ sh ./build-unfixed.sh shared    # SHARED_RUNTIME forced back to ""
built build/libvirtualsx1262.dll
build.sh: the DLL imports something that will not be on the target:
  libstdc++-6.dll
  a host opening it gets "The specified module could not be found",
  naming this DLL rather than the one above.
exit=1

Verification

On Windows 10 Home 22H2 (19045), MSYS2 MINGW64 gcc 16.1.0:

• STRICT=1 ./build.sh — full build and both test binaries, 0 failures.
• Built this DLL, dropped it in place of the shipped v1.3.0 one in a real MeshBench v0.0.8 install, cleared the probe cache, and ran the board probe that could not get past boot:

board.probe Generic_E22_sx1262
  before   boot  failed   firmware started but never connected within 40s
  after    boot  passed   attached and answering

The node then pins its board image properly (firmware_board: "Heltec_v3", which stayed empty while the boot was failing) and board.screen reports a real 128x64 SSD1306 rather than refusing.

After this merges

MeshBench needs a release of this repo to pin: CHIPMODEL_RELEASE in packaging/emulator-pins.env is v1.3.0 today. Cutting v1.3.1 and bumping that pin is what actually closes MeshBench#632 — this PR only makes the artefact correct.

Not addressed here: the same -static question for the Linux .so and macOS .dylib. I left both dynamic deliberately, but if a host is ever expected to load us somewhere without a system libstdc++, that is the conversation to have.

🤖 Generated with Claude Code

https://claude.ai/code/session_01RSb8bN9gtL72cXAxtyTbAG

[A13xB0]

CI: everything passes including windows / mingw, and the new guard ran there on your own runner rather than only on my machine:

built build/libvirtualsx1262.a
built build/libvirtualsx1262.dll
checked build/libvirtualsx1262.dll: nothing imported beyond kernel32 and msvcrt

consumers are up to date fails, and I do not think this PR can make it pass.

::warning::MeshBench/meshcore-native pins 0debbb9125bb, 2 commits behind:
           build: the Windows DLL carries its own runtime

That is the check working as written: meshcore-native pins this repository as a submodule at what is currently main, and any commit here puts it behind. The pin can only move to a commit that exists, so on a pull_request the consumer is behind by construction — the PR head is a merge commit nothing could have pinned yet. The job already reasons about this for pushes:

if [ "pull_request" = push ]; then
  echo "advisory on a push: the pin cannot have moved to this commit yet"
  exit 0
fi
exit 1

The same argument applies more strongly to a pull request than to a push, so as it stands the job goes red on every PR to this repository regardless of what the PR does — a check that cannot pass is one people learn to scroll past, which is the opposite of what it is for. Two options, neither of which belongs in this PR:

1. Make it advisory on pull_request too, and keep it hard on push to main — where a lagging pin is a real, fixable state.
2. Keep it hard on PRs but compare the consumer's pin against the PR's base rather than its head, so it only fails when the consumer was already behind before this change.

The follow-up this is correctly reminding us about is real either way: after this merges, MeshBench/meshcore-native needs its vendor/virtual-sx1262 submodule moved to the new commit, or it keeps building the old chip model. And separately, MeshBench pins a release rather than a commit — CHIPMODEL_RELEASE=v1.3.0 in packaging/emulator-pins.env — so closing MeshBench#632 needs a v1.3.1 cut here and that pin bumped. Happy to do both once this lands, if you want them.