From 77015e473a55eaec329ae059406febec113377aa Mon Sep 17 00:00:00 2001 From: Alex B <142788550+A13xB0@users.noreply.github.com> Date: Sun, 6 Sep 2026 19:29:32 +0100 Subject: [PATCH] package: pin the chip model at v1.3.1, which Windows can open v1.3.0's Windows DLL imported libstdc++-6.dll. That exists inside the MSYS2 environment it was built in and almost nowhere else, so on any ordinary Windows machine neither emulator could open the chip model: qemu-system-xtensa.exe: sx1262: cannot load the chip model at ...\libvirtualsx1262.dll: The specified module could not be found. which names the DLL rather than the dependency behind it. Renode reaches the same library through LoadLibraryW and failed the same way, so this was every emulated board on Windows, ESP32 and nRF52 alike. It surfaced three steps downstream as "firmware started but never connected within 40s" - a radio that never answers, because the model behind it never loaded. Nothing was lost in packaging: the release staged what build.sh produced and we shipped what we unpacked. The build asked for a dynamic runtime on a platform that has none. MeshBench/virtual-sx1262#1 links it statically; v1.3.1 is that build, same ABI and same model, and imports only kernel32 and msvcrt. Verified against the published artefact rather than a local build: the v1.3.1 windows tarball dropped into a v0.0.8 install, probe cache cleared. board.probe Generic_E22_sx1262 v1.3.0 boot failed firmware started but never connected within 40s v1.3.1 boot passed attached and answering The Windows tarball grows from 28 kB to 143 kB, which is the static runtime and the whole cost of the fix. The catalogue's digests and sizes move with the pin, as the rule at the top of emulator-pins.env requires. Closes #632. Co-Authored-By: Claude Opus 5 Claude-Session: https://claude.ai/code/session_01RSb8bN9gtL72cXAxtyTbAG --- internal/app/resource/toolchaincatalogue.go | 16 ++++++++-------- packaging/emulator-pins.env | 9 ++++++++- 2 files changed, 16 insertions(+), 9 deletions(-) diff --git a/internal/app/resource/toolchaincatalogue.go b/internal/app/resource/toolchaincatalogue.go index 3eb26f1a..add67adb 100644 --- a/internal/app/resource/toolchaincatalogue.go +++ b/internal/app/resource/toolchaincatalogue.go @@ -23,7 +23,7 @@ package resource const ( qemuBase = "https://github.com/MeshBench/qemu/releases/download/v9.2.2-meshbench-sx1262-14/" renodeBase = "https://github.com/MeshBench/renode/releases/download/meshbench-20260904-e7196ef/" - chipBase = "https://github.com/MeshBench/virtual-sx1262/releases/download/v1.3.0/" + chipBase = "https://github.com/MeshBench/virtual-sx1262/releases/download/v1.3.1/" ) // qemuArm64LinuxIsUntried is the one platform the fork builds and this does not @@ -52,7 +52,7 @@ const qemuArm64LinuxIsUntried = "the fork publishes an aarch64 Linux build and " // before it clocks the next. var toolReleases = []toolRelease{{ Name: "virtual-sx1262", - Version: "v1.3.0", + Version: "v1.3.1", MCU: "", Why: "the SX1262 itself, which both emulators load and a native node links; " + "every emulated node needs it, ESP32 or nRF52", @@ -60,22 +60,22 @@ var toolReleases = []toolRelease{{ Assets: map[string]toolAsset{ "linux/amd64": { URL: chipBase + "virtual-sx1262-linux-amd64.tar.gz", - SHA256: "33f4453c39bfa1b8f0f4706efb387e7f9588217eabc2713887b7fdf9974d9155", - Bytes: 26340, Kind: tarGzip, Magic: elfAMD64, + SHA256: "7e04041afd4f0b2e063566042c136b6255e7adf6da27e19c02a8ac6737ee0fa0", + Bytes: 26335, Kind: tarGzip, Magic: elfAMD64, Root: "virtual-sx1262-linux-amd64", Binary: "virtual-sx1262-linux-amd64/lib/libvirtualsx1262.so", }, "darwin/arm64": { URL: chipBase + "virtual-sx1262-macos-arm64.tar.gz", - SHA256: "362ed99e8b3b434cc738045531818c8de8e6465f1a05cb057fb7199605f59b6a", - Bytes: 19118, Kind: tarGzip, Magic: machARM64, + SHA256: "167e471ba64416cace0296e5b2c40dabbe1ed80f523e200cc96890f5f96c0fbc", + Bytes: 19119, Kind: tarGzip, Magic: machARM64, Root: "virtual-sx1262-macos-arm64", Binary: "virtual-sx1262-macos-arm64/lib/libvirtualsx1262.dylib", }, "windows/amd64": { URL: chipBase + "virtual-sx1262-windows-amd64.tar.gz", - SHA256: "176b29626adb66af3c069b242560b1666c68afb3f25d9e63c26e64572ca85fcf", - Bytes: 28685, Kind: tarGzip, Magic: peAMD64, + SHA256: "90621299f0e2e85720900a7b75ebcdfd8fd7fe2db89432cdb9ff4505ff9ac67d", + Bytes: 146549, Kind: tarGzip, Magic: peAMD64, Root: "virtual-sx1262-windows-amd64", Binary: "virtual-sx1262-windows-amd64/lib/libvirtualsx1262.dll", }, diff --git a/packaging/emulator-pins.env b/packaging/emulator-pins.env index e47f3fbc..0d872a13 100644 --- a/packaging/emulator-pins.env +++ b/packaging/emulator-pins.env @@ -70,7 +70,14 @@ RENODE_ASSET_WINDOWS_AMD64=meshbench-renode-1.16.1.windows-portable.zip # needs, refuses one that cannot serve it, and the number in the tag is the one # it is refusing against. This is ABI 1.3, the version with the byte-at-a-time # SPI path, which is the only one an emulator can use. -CHIPMODEL_RELEASE=v1.3.0 +# +# v1.3.1 is the same ABI and the same model; what changed is how the Windows +# library is linked. v1.3.0's DLL imported libstdc++-6.dll, which exists inside +# MSYS2 and almost nowhere else, so QEMU and Renode both failed to open it on +# any ordinary Windows machine and every emulated board there died as a radio +# that never answered. It is statically linked now and imports only kernel32 +# and msvcrt. MeshBench#632, fixed by MeshBench/virtual-sx1262#1. +CHIPMODEL_RELEASE=v1.3.1 CHIPMODEL_ASSET_LINUX_AMD64=virtual-sx1262-linux-amd64.tar.gz CHIPMODEL_ASSET_DARWIN_ARM64=virtual-sx1262-macos-arm64.tar.gz CHIPMODEL_ASSET_WINDOWS_AMD64=virtual-sx1262-windows-amd64.tar.gz