resolvedLibraryPath property

String? get resolvedLibraryPath

The filesystem path libzenoh_dart.so was actually loaded from, or null.

The one value that answers "which library did you actually load?" — the question a consumer asks precisely when a variant mismatch, a stale build or a packaging mistake is the suspect.

Reading this does NOT initialise anything, and that is deliberate. An accessor whose purpose is diagnosing a load problem must not depend on the load succeeding: it would throw at exactly the moment it is most needed, and merely asking would drag a 13 MB library into the address space. It is total and never throws. ⚠️ This diverges on purpose from the internal bindings getter, which does auto-initialise.

null means exactly one of three things, and the third is the one nobody guesses:

  1. nothing has been loaded yet — no zenoh call has been made in this isolate group;
  2. the load failed — see the StateError it threw, which names the paths it probed;
  3. the OS linker resolved the library by soname, so there was never a path to record. This is the normal case on Android (the APK's lib/<abi>/) and on Flutter desktop (RUNPATH=$ORIGIN/lib) — null there is correct and says nothing is wrong.

It reports the variant actually loaded, not the one requested: a consumer diagnosing a variant question gets the truth rather than their own request echoed back.

Implementation

// ignore: unnecessary_library_prefix -- forwards the loader's own getter.
static String? get resolvedLibraryPath => nl.resolvedLibraryPath;