Skip to content

chore(tot): L-7b-ii monolithic libtotapi_mono.so PoC#202

Merged
k-yoshimi merged 2 commits into
developfrom
chore/l7b-ii-monolithic-poc
May 14, 2026
Merged

chore(tot): L-7b-ii monolithic libtotapi_mono.so PoC#202
k-yoshimi merged 2 commits into
developfrom
chore/l7b-ii-monolithic-poc

Conversation

@k-yoshimi
Copy link
Copy Markdown
Owner

@k-yoshimi k-yoshimi commented May 14, 2026

Summary

Time-boxed PoC adding a libtotapi_mono.so Makefile target that links eq + tr + fp + ti + wrx PIC objects into ONE shared image with a SINGLE canonical BPSD broker. Foundation work toward activating the ('eq','tr') BPSD coupling rule deferred in L-7b-ii §0.

Follow-up: #201

Background

Independent Codex review identified that the L-7b-ii spec §0's premise — "libtotapi.so co-links eq + tr + bpsd into one image" — is incorrect for the actually shipped artifact:

$ otool -L tot/libtotapi.so | grep api
    @rpath/libeqapi.so
    @rpath/libtrapi.so
    @rpath/libfpapi.so
    @rpath/libtiapi.so
    @rpath/libwrxapi.so

$ nm tot/libtotapi.so | grep '_bpsd_.*_MOD_.*x_init_flag'
(empty — libtotapi.so carries no bpsd storage of its own)

So today's libtotapi.so has the same per-.so BPSD isolation that TotPipeline would, just hidden by the test fixtures not exercising the broker round-trip. The Codex recommendation was to build a true monolithic image. This PoC validates that.

What works (verified)

  • Build: make -C tot libtotapi_mono.so succeeds on macOS arm64.
  • BPSD dedup: nm libtotapi_mono.so | grep '_bpsd_.*_MOD_.*x_init_flag' | sort -u shows exactly 8 unique symbols (one per bpsd module type), not 5×8.
  • No per-module .so deps: otool -L libtotapi_mono.so shows only libgfortran, libquadmath, libSystem.
  • C ABI surface preserved: 6 tot_* exports present (init / run / get_state / set_param / set_param_str / finalize).
  • Default libtotapi.so path untouched: zero risk of regression in existing equivalence tests.
  • libtotapi_mono_inspect target hard-fails if bpsd dedup ever drifts (count != 8).

What's deferred

libtotapi_mono.so is not yet dlopen-loadable through Python ctypes — ~30 graphics symbols unique to specific per-module <mod>_graphics_stubs.o files (_getkgt_, _getkrt_, _contX_, _r2w2b_, _text_, _move_, ...) stay undefined at dlopen time. The mono build keeps only ONE per-module stub set (fp's, broadest non-conflicting) to avoid duplicate-symbol link errors, but no single set covers all modules' unique symbols.

The fix is a unified tot/tot_graphics_stubs_mono.f90 consolidating the ~60-symbol union. Tracked at #201.

Reviewer trail

  • In-house code reviewer: SHA e82e1179 → 2 MED + 3 LOW (wildcard parse-time, follow-up issue not filed, clean target). All addressed in amend 53c4978a. Delta re-review: approve, ship.
  • Codex rescue: SHA e82e1179 → "hold" citing wildcard blocker + spec §0 phrasing + inspect count check. All technical blockers addressed in amend 53c4978a. Delta re-review: resolved. (Note: Codex's time-boxing concern was a user-level scope decision, not a technical blocker.)

Test plan

  • make -C tot libtotapi_mono.so builds cleanly
  • make -C tot libtotapi_mono_inspect shows 8 unique bpsd storage symbols + no per-module .so deps + all 6 tot_* exports
  • Default libtotapi.so path unchanged (make -C tot libtotapi.so still works)
  • Sanity-guard fires if PIC obj/pic/ trees are absent (added in amend after reviewer feedback)
  • Equivalence test against mono: deferred to follow-up (graphics stubs gap)
  • Layer-C BPSD smoke test: deferred to follow-up

🤖 Generated with Claude Code


Note

Medium Risk
Build-system changes introduce a new shared-library link path that co-links many module PIC objects and changes PIC cleanup; risk is mainly around linker/ABI/regression in alternative build workflows, though the default libtotapi.so path remains unchanged.

Overview
Adds an opt-in monolithic shared library target, libtotapi_mono.so, that co-links eq/tr/fp/ti/wrx PIC objects into a single image with a single deduplicated BPSD object set (enabling future cross-module BPSD broker coupling in one runtime).

Updates tot/Makefile to build/inspect the mono artifact (guards against empty wildcards, omits duplicate graphics stubs, sets distinct install_name/soname, and adds libtotapi_mono_inspect), and extends clean_pic to remove libtotapi_mono.so.

Adds a new spec note, 2026-05-14-l7b-ii-monolithic-poc-findings.md, documenting that current libtotapi.so is not monolithic, what the PoC proves, and the remaining blocker (unified graphics stubs for dlopen/equivalence tests).

Reviewed by Cursor Bugbot for commit 1825307. Bugbot is set up for automated code reviews on this repo. Configure here.

Adds the `libtotapi_mono.so` Makefile target as a time-boxed PoC
toward activating the ('eq','tr') BPSD coupling rule deferred in
L-7b-ii §0. The mono target links all per-module PIC objects
(eq + tr + fp + ti + wrx) into ONE shared library with a SINGLE
canonical bpsd PIC set, instead of the default per-module
libXXapi.so architecture where each module carries a private bpsd
storage copy.

What works:
- Build succeeds on macOS arm64 (gfortran 15.x)
- `nm` confirms BPSD storage symbols dedupe to exactly 1 set
  (not 5 like in the per-module .so chain): one each of
  __bpsd_device_MOD_bpsd_devicex_init_flag, __bpsd_equ1d, ...
- `otool -L` confirms NO @rpath/libeqapi.so / libtrapi.so / etc.
  runtime dependencies — only system libs (libgfortran,
  libquadmath, libSystem)
- All 6 tot_* C ABI exports present (tot_init / tot_run /
  tot_get_state / tot_set_param / tot_set_param_str / tot_finalize)

What's deferred:
- 1e-10 equivalence test against libtotapi_mono.so via Python
  ctypes: dlopen fails on ~30 graphics symbols (_getkgt_,
  _getkrt_, _contX_, _r2w2b_, _text_, _move_, ...) that are
  unique to specific per-module <mod>_graphics_stubs.o files.
  fp_graphics_stubs.o (kept by the mono build) is the broadest
  non-conflicting set but doesn't cover all 5 modules' unique
  symbols. Resolving this needs a unified
  `tot/tot_graphics_stubs_mono.f90` consolidating the symbol union,
  tracked as a follow-up.

Codex independent review revealed that the spec's prior premise
(libtotapi.so co-links eq+tr+bpsd into one image) is incorrect
for the actual shipped artifact — verified via otool/nm. The mono
PoC validates that a true monolithic image IS achievable through
Makefile-only changes, without restructuring any Fortran source.
The L-7b-ii spec §0 amendment paragraph in the findings doc records
this for future readers.

Files:
- tot/Makefile: +120 lines — libtotapi_mono.so target + variables
  for per-module PIC object globs, single bpsd set, transitive
  PIC archives (dp, ob, adf11, adpost). Default libtotapi.so
  target unchanged.
- docs/superpowers/specs/2026-05-14-l7b-ii-monolithic-poc-findings.md:
  full investigation log + verification snippets + proposed
  L-7b-ii spec §0 amendment + follow-up plan.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@k-yoshimi
Copy link
Copy Markdown
Owner Author

@cursor review

Comment thread tot/Makefile Outdated
Bugbot LOW finding on PR #202: mono_pic_prereqs was .PHONY, which
makes it never up-to-date in GNU Make. Listing a .PHONY target as a
regular (not order-only) prerequisite of the real-file target
libtotapi_mono.so forced unconditional re-link on every invocation
even when nothing had changed.

Fix mirrors the existing libtotapi.so prereq pattern (tot/Makefile:530):
list $(LIBS_PIC_SO) directly as real-file prerequisites. This gives
us both:
  1. side-effect we need: building each per-module .so populates its
     obj/pic/ tree with the PIC objects libtotapi_mono.so actually links;
  2. Make's standard mtime-based incremental rebuild: libtotapi_mono.so
     only re-links when a per-module .so is newer.

Verified locally:
  $ make -C tot libtotapi_mono.so   # builds + links
  $ make -C tot libtotapi_mono.so   # "is up to date" — no re-link
  $ make -C tot libtotapi_mono_inspect
  ... OK: 8 unique bpsd storage symbols (one per bpsd module type)

Also drops the now-unused .PHONY mono_pic_prereqs definition and
updates the comment block referencing it.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@k-yoshimi
Copy link
Copy Markdown
Owner Author

@cursor review

Copy link
Copy Markdown

@cursor cursor Bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

Reviewed by Cursor Bugbot for commit 1825307. Configure here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant