Issue #618 was filed from PR #558 (issue #163) to propose pinning the zlib the DNG benchmark's
reference arm links. The proposal stands and reproduces. One sentence of its justification does
not, and it is the sentence an implementer would use to decide whether the pin is needed at all.
This run is unattended and its contract forbids editing, commenting on, labelling or closing an
existing issue under any authority — including issues it filed itself. So the correction is filed
here rather than applied in place. A human with write access should fold this into #618 and close
this issue. (#617 is the sibling correction for #583 and #584; it is not the right home for this
one, because it is already published and this run may not edit it either.)
The wrong sentence
On this box those are stock zlib 1.3.1 and zlib-ng-compat 2.3.3, and zlibVersion() cannot tell
them apart: zlib-ng's compatibility build answers "1.3.1" exactly as stock zlib does. Only the
path (dladdr + realpath) discriminates.
Executed on the same box:
$ ./zv /usr/lib64/libz.so.1
/usr/lib64/libz.so.1 -> 1.3.1.zlib-ng
$ ./zv <worktree>/target/release/build/libtiff-oracle-*/out/zlib-prefix/lib/libz.so.1.3.1
... -> 1.3.1
(./zv is four lines of C: dlopen the argument, dlsym("zlibVersion"), print what it returns.
strings on the two shared objects agrees.)
The platform build answers 1.3.1.zlib-ng; the stock copy under target/ answers 1.3.1. So
zlibVersion() does separate that particular pair, and #618's own measurement table — three
lines above the claim — is labelled with exactly that split.
What is true instead, and why the proposal is unaffected
Two stock builds of one zlib version are indistinguishable by version string. That is the pair the
loader actually collides in general: the copy some dev oracle's build script leaves under target/
and an installed /usr/lib64/libz.so.1.3.1. Nothing makes the platform's copy a fork — this box
happens to ship a zlib-ng-compatibility build, and a box that ships stock zlib 1.3.1 gives two
resolutions that answer identically. The identification therefore cannot rest on a fork choosing to
rename itself, which is why the harness prints the dladdr path and warns when it lies inside a
build directory.
Everything else in #618 is unchanged: the linkage mechanism (-lz because the SDK includes
<zlib.h> unconditionally), the LD_LIBRARY_PATH resolution through libtiff-oracle's build
script, the measured 1.2–1.3× movement of the reference arm, the 0.94 → 1.23–1.26 ratio swing, the
proposal to pin the benchmark's link while keeping -lz for conformance, and its two caveats.
Where the false form came from
It was not invented in #618. It was carried in a shared contract the run's lanes read before
writing anything, and it propagated unexecuted into four in-repo doc sites, a printed benchmark
epilogue, PR #558's body and this issue before a reviewer ran zlibVersion() against both
libraries. The contract has been corrected at its source. It is recorded here because a claim that
travels through four artefacts without anyone executing it is worth a reader knowing about.
The in-repo sites are corrected on PR #558 (crates/gamut-dng/STATUS.md,
crates/gamut-dng/benches/codec.rs module header and printed epilogue,
tooling/gamut-dng-oracle/src/lib.rs, tooling/gamut-dng-oracle/src/oracle_shim.cpp), including
the worked example, which showed a version of 1.3.1 resolving to a path ending .zlib-ng — a
composite that cannot occur.
Verification
cargo bench -p gamut-dng --bench codec -- --test
prints the resolved library and the build-tree warning; run the same bench binary directly from
target/release/deps/ and it prints the platform's. On this box the two differ in the version
string as well as the path — which is the accident that hid the claim, not evidence for it.
Refs #163, #558, #618.
Issue #618 was filed from PR #558 (issue #163) to propose pinning the zlib the DNG benchmark's
reference arm links. The proposal stands and reproduces. One sentence of its justification does
not, and it is the sentence an implementer would use to decide whether the pin is needed at all.
This run is unattended and its contract forbids editing, commenting on, labelling or closing an
existing issue under any authority — including issues it filed itself. So the correction is filed
here rather than applied in place. A human with write access should fold this into #618 and close
this issue. (#617 is the sibling correction for #583 and #584; it is not the right home for this
one, because it is already published and this run may not edit it either.)
The wrong sentence
Executed on the same box:
(
./zvis four lines of C:dlopenthe argument,dlsym("zlibVersion"), print what it returns.stringson the two shared objects agrees.)The platform build answers
1.3.1.zlib-ng; the stock copy undertarget/answers1.3.1. SozlibVersion()does separate that particular pair, and #618's own measurement table — threelines above the claim — is labelled with exactly that split.
What is true instead, and why the proposal is unaffected
Two stock builds of one zlib version are indistinguishable by version string. That is the pair the
loader actually collides in general: the copy some dev oracle's build script leaves under
target/and an installed
/usr/lib64/libz.so.1.3.1. Nothing makes the platform's copy a fork — this boxhappens to ship a zlib-ng-compatibility build, and a box that ships stock zlib 1.3.1 gives two
resolutions that answer identically. The identification therefore cannot rest on a fork choosing to
rename itself, which is why the harness prints the
dladdrpath and warns when it lies inside abuild directory.
Everything else in #618 is unchanged: the linkage mechanism (
-lzbecause the SDK includes<zlib.h>unconditionally), theLD_LIBRARY_PATHresolution throughlibtiff-oracle's buildscript, the measured 1.2–1.3× movement of the reference arm, the 0.94 → 1.23–1.26 ratio swing, the
proposal to pin the benchmark's link while keeping
-lzfor conformance, and its two caveats.Where the false form came from
It was not invented in #618. It was carried in a shared contract the run's lanes read before
writing anything, and it propagated unexecuted into four in-repo doc sites, a printed benchmark
epilogue, PR #558's body and this issue before a reviewer ran
zlibVersion()against bothlibraries. The contract has been corrected at its source. It is recorded here because a claim that
travels through four artefacts without anyone executing it is worth a reader knowing about.
The in-repo sites are corrected on PR #558 (
crates/gamut-dng/STATUS.md,crates/gamut-dng/benches/codec.rsmodule header and printed epilogue,tooling/gamut-dng-oracle/src/lib.rs,tooling/gamut-dng-oracle/src/oracle_shim.cpp), includingthe worked example, which showed a version of
1.3.1resolving to a path ending.zlib-ng— acomposite that cannot occur.
Verification
prints the resolved library and the build-tree warning; run the same bench binary directly from
target/release/deps/and it prints the platform's. On this box the two differ in the versionstring as well as the path — which is the accident that hid the claim, not evidence for it.
Refs #163, #558, #618.