Every Ceres solve in the project selects a dense linear solver explicitly --
DENSE_QR in PostRefine, RingOptimizer and StillsPartialityRefine,
DENSE_NORMAL_CHOLESKY in XtalOptimizer, DENSE_SCHUR in GeometryRefiner -- and
none of the seven Solver::Options sites sets dense_linear_algebra_library_type,
which defaults to EIGEN. ceres::Covariance, the other SuiteSparse consumer, is
never instantiated. So no sparse factorization and no LAPACK call is reachable.
Measured rather than argued: an LD_PRELOAD shim exporting dgeqrf_, dpotrf_,
dtrtrs_, spotrf_ and METIS_NodeND, each aborting on entry, let a full mx run
(1800 frames, index -> refine -> integrate -> scale -> merge) finish with every
counter at zero.
The change is a no-op on results. Baseline and modified binaries produce
byte-identical run.mtz, run.hkl and run.cif on a rotation dataset at -N 1, and
two baseline runs give that same signature, so the comparison is meaningful.
Only the DATE= stamp in the report differs.
What it buys is six fewer shared libraries: libopenblas and libmetis, plus
libgfortran, libquadmath, libgomp and libz behind them. rugnux links its own
zlib statically -- zero undefined zlib symbols before and after -- so the
dynamic libz only ever arrived through OpenBLAS.
It also makes the build reproducible across hosts. SUITESPARSE defaults ON and
self-disables only when its probe fails, so a machine where SuiteSparse_DIR is
not found already compiled CERES_NO_SUITESPARSE while one carrying the
SuiteSparse CMake config would not have. Pinning it removes that divergence,
and shortens what a cross-compiled aarch64 build has to supply.
EIGENSPARSE stays ON, so a sparse solver remains available if one is ever
selected, without an external library.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SQjneRUssfhi1k9rq8Ts3h
leonarski_fandClaude Opus 5
86b7e07131