python-aaronia 0.7.1__tar.gz → 0.7.3__tar.gz

{python_aaronia-0.7.1 → python_aaronia-0.7.3}/CHANGELOG.md

@@ -4,26 +4,49 @@ All notable changes to this project will be documented in this file.
 
 ## [Unreleased]
 
-## [v0.7.1] - 2026-08-12
+## [v0.7.3] - 2026-08-12
+
+### Fixed
+- The Windows leg of the new module load check could not run: vcpkg's
+  SoapySDR port ships no `SoapySDRUtil`, so the check failed rather
+  than verifying anything, and 0.7.2 published no release archives.
+  Where the tool is absent the packaged DLL is now loaded directly,
+  which still catches a module whose dependencies do not resolve away
+  from the build machine.
+
+## [v0.7.2] - 2026-08-12
 
 ### Fixed
 - **The published macOS SoapySDR module would not load, on any Mac.**
   `dlopen` failed with "symbol not found in flat namespace" for a Rust
-  vtable entry. CMake links module targets on macOS with
-  `-undefined dynamic_lookup`, and the Apple linker emitted a
-  flat-namespace bind for a symbol it had already localised into the
-  same image. The module now resolves its symbols at link time, so this
-  is a build failure rather than something a user meets on first run.
-  Every 0.5.x, 0.6.x and 0.7.0 macOS archive is affected; the Linux and
-  Windows modules are not.
-- **The packaged module's load check ran on Linux only**, which is why
-  the above shipped. It now runs on all three platforms at release
-  time, and CI builds and checks the plugin on macOS as well as Linux.
+  vtable entry that the linker had itself defined and localised in the
+  same image. SoapySDR's installed CMake export lists `-flat_namespace`
+  in the imported target's interface, so it reached the end of every
+  module's link line and forced flat-namespace binding; the module
+  links directly against libSoapySDR and does not need it. Removing it
+  takes the module from 5670 flat-namespace binds to none, so the
+  failure cannot recur rather than depending on a linker version — some
+  hit the defect and some did not, which is why local builds worked.
+  Every 0.5.x, 0.6.x, 0.7.0 and 0.7.1 macOS archive is affected; the
+  Linux and Windows modules are not.
+- **The packaged module's load check ran on Linux only**, which is how
+  the above shipped for as long as it did. It now runs on all three
+  platforms at release time, and CI builds and checks the plugin on
+  macOS as well as Linux. Both check the reported text: `--check` exits
+  0 even when the driver failed to load.
 
 ### Documentation
 - The Linux module needs glibc 2.38 or later, so it does not load on
   Ubuntu 22.04 or Debian 12. Said so in the plugin README.
 
+## [v0.7.1] - 2026-08-12
+
+An incomplete fix for the macOS module, superseded by 0.7.2. Like
+0.7.2, it reached crates.io and PyPI but published no release archives,
+because the new load check refused to ship a macOS module that would
+not open. Its crate and wheels are sound and identical in content to
+0.7.3.
+
 ## [v0.7.0] - 2026-08-12
 
 ### Added

{python_aaronia-0.7.1 → python_aaronia-0.7.3}/Cargo.lock

@@ -3027,7 +3027,7 @@ dependencies = [
 
 [[package]]
 name = "python-aaronia"
-version = "0.7.1"
+version = "0.7.3"
 dependencies = [
  "arrow",
  "num-complex",
@@ -3556,7 +3556,7 @@ checksum = "94143f37725109f92c262ed2cf5e59bce7498c01bcc1502d7b9afe439a4e9f49"
 
 [[package]]
 name = "sdr-aaronia-rs"
-version = "0.7.1"
+version = "0.7.3"
 dependencies = [
  "anyhow",
  "bitflags 2.13.1",

{python_aaronia-0.7.1 → python_aaronia-0.7.3}/Cargo.toml

@@ -2,7 +2,7 @@
 name = "sdr-aaronia-rs"
 description = "Unified Rust interface for Aaronia Spectran Spectrum Analyzers / SDRs, featuring Python bindings, a SoapySDR plugin, HTTP streaming, and native SDK support."
 license = "GPL-3.0-or-later"
-version = "0.7.1"
+version = "0.7.3"
 edition = "2024"
 repository = "https://github.com/isaacbentley/sdr-aaronia-rs"
 readme = "README.md"

{python_aaronia-0.7.1 → python_aaronia-0.7.3}/PKG-INFO

@@ -1,6 +1,6 @@
 Metadata-Version: 2.4
 Name: python-aaronia
-Version: 0.7.1
+Version: 0.7.3
 Classifier: Programming Language :: Rust
 Classifier: Programming Language :: Python :: Implementation :: CPython
 Classifier: License :: OSI Approved :: GNU General Public License v3 or later (GPLv3+)

{python_aaronia-0.7.1 → python_aaronia-0.7.3}/packaging/homebrew/soapy-aaronia.rb

@@ -12,7 +12,7 @@
 class SoapyAaronia < Formula
   desc "SoapySDR plugin for Aaronia SPECTRAN V6 spectrum analyzers"
   homepage "https://github.com/isaacbentley/sdr-aaronia-rs"
-  version "0.7.1"
+  version "0.7.3"
   license "GPL-3.0-or-later"
 
   # Prebuilt modules: the plugin statically links its Rust core, so there

{python_aaronia-0.7.1 → python_aaronia-0.7.3}/python-aaronia/Cargo.toml

@@ -1,6 +1,6 @@
 [package]
 name = "python-aaronia"
-version = "0.7.1"
+version = "0.7.3"
 edition = "2024"
 description = "Python bindings for sdr-aaronia-rs (Aaronia SPECTRAN V6 SDR source)"
 license = "GPL-3.0-or-later"

{python_aaronia-0.7.1 → python_aaronia-0.7.3}/soapy-aaronia/CMakeLists.txt

@@ -15,22 +15,31 @@ set(CMAKE_CXX_STANDARD_REQUIRED ON)
 
 find_package(SoapySDR "0.7" REQUIRED)
 
-# CMake links MODULE targets on macOS with `-undefined dynamic_lookup`,
-# which tells the linker to leave unresolved symbols for load time. The
-# Apple linker then emitted a flat-namespace bind for a Rust vtable
-# entry it had already localised into the same image, and dyld could
-# not find it — so every published macOS module failed to load with
-# "symbol not found in flat namespace", while the same source built
-# with a newer Xcode was fine. Resolving at link time makes that a
-# build failure instead of something a user discovers.
+# SoapySDR's installed CMake export lists `-flat_namespace` in the
+# imported target's INTERFACE_LINK_LIBRARIES, so it lands at the end of
+# every module's link line and forces flat-namespace symbol binding.
+# That is how a module could end up with a dangling bind: the linker
+# defined a Rust vtable symbol, localised it into this image, and still
+# emitted a flat-namespace bind for it, which dyld could not resolve —
+# so `dlopen` failed with "symbol not found in flat namespace" and the
+# published macOS module never loaded. The module links directly
+# against libSoapySDR, so two-level binding resolves those symbols
+# without it.
 #
-# SoapySDR's own module macro does the same for GNU toolchains
-# (`-Wl,--no-undefined`) and for the stated reason; it just never
-# covered Apple.
-# CMake has spelled this flag both ways across versions
-# (`-undefined dynamic_lookup` and `-Wl,-undefined,dynamic_lookup`), and
-# recent versions omit it entirely, so match both and tolerate neither
-# being present.
+# Also drop `-undefined dynamic_lookup`, which CMake has spelled both
+# ways across versions and recent versions omit entirely: a module that
+# fails to load is worse than one that fails to link, which is the
+# reason SoapySDR's own macro passes `-Wl,--no-undefined` for GNU
+# toolchains.
+if (APPLE AND TARGET SoapySDR)
+    get_target_property(_soapy_iface SoapySDR INTERFACE_LINK_LIBRARIES)
+    if (_soapy_iface)
+        list(REMOVE_ITEM _soapy_iface "-flat_namespace")
+        set_target_properties(SoapySDR PROPERTIES
+            INTERFACE_LINK_LIBRARIES "${_soapy_iface}")
+    endif()
+endif()
+
 if (APPLE)
     string(REGEX REPLACE "(-Wl,)?-undefined[ ,]dynamic_lookup" ""
         CMAKE_SHARED_MODULE_CREATE_CXX_FLAGS
@@ -84,6 +93,11 @@ if (APPLE)
     # Belt and braces with the flag removal above: whichever `-undefined`
     # the generator emits, this one comes last and wins.
     target_link_options(aaroniaSupport PRIVATE "LINKER:-undefined,error")
+
+    # `-flat_namespace` is stripped above, so the linker cannot emit a
+    # flat-namespace bind for a symbol it defined here. The module load
+    # check in CI is what proves that, on the toolchain that shipped the
+    # broken module.
 endif()
 
 # System libraries required by the statically-linked Rust runtime