mirror of
https://github.com/logos-co/logos-protocol.git
synced 2026-08-30 05:21:07 +00:00
Dario Gabriel LipicarandClaude Opus 5
b33c354fd8
PR-7 of the shared-runtime migration. Comment-only: no non-comment line changes,
and checks.tests passes.
This header is the canonical explanation of the one-runtime invariant, and after
the migration it described a scheme that no longer exists. It still said the
resolution was ONE PROVIDER with liblogos_core exporting types it does not own,
and still pointed at logos-basecamp/cmake/LogosSharedFromDll.cmake -- a file
deleted in logos-basecamp#348 and logos-logoscore-cli#98.
Now states where definitions actually live:
liblogos_protocol TokenManager, LogosAPIClient, the StoreRegistry
liblogos_qt_host LogosAPI
and that liblogos_core defines ZERO runtime symbols, importing them like every
other consumer.
RECORDS THE FIX THAT DID NOT WORK, because it looks obvious and someone will try
it again: hand-marking a class list with __declspec(dllexport) is not a smaller
version of the right answer. It exported 116 symbols and the Qt host runtime
still failed to link with ELEVEN undefined references across five classes, plus
free functions nobody had marked. A curated list is correct only until the next
consumer touches a symbol nobody thought of, and the failure lands in a
downstream repo far from the cause. Hence a .def GENERATED from the objects.
STATES THE IN-PROCESS / OUT-OF-PROCESS SPLIT, which is the distinction that
decides who links what and the one most likely to be "simplified" away by
someone tidying up. In-process images link the SHARED libraries; logos_host,
ui-host, module plugins and ui_qml backends keep linking the STATIC archive, and
that is CORRECT rather than a leftover: each runs in its own process, so its own
copy IS the right per-process singleton -- measured, logos_host and ui-host
define ~100 runtime symbols each and are deliberately exempt from the symbol
gates. Staying static also keeps a .lgx self-contained, since a .lgx records an
EMPTY nix closure and a shared library would not travel with it.
Says plainly not to unify the two, and why: it would couple every .lgx to the
exact runtime build it was packaged against, to fix a duplication that is not a
bug in a separate process.
Ends with what asserts any of this, since nothing did for a long time and that
is how nine images came to define the same singleton: symbol gates in
logos-basecamp, logos-logoscore-cli and logos-standalone-app, each shipped with
a negative control that plants a real duplicate and requires rejection.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>