From 8a91679b2b291a83a60cf2aa0a0838cc605ee531 Mon Sep 17 00:00:00 2001 From: Julian Noble Date: Tue, 21 Jul 2026 14:09:12 +1000 Subject: [PATCH] goals: record tclkit dynamic-libc insight + TIP 741 temp-cleanup characterization Self-contained-but-loads-binaries (the tclkit model) resolved: tclkitsh binaries are self-contained via an embedded Metakit/zip VFS yet DYNAMICALLY linked to libc - that dynamic libc is what makes dlopen/'load' work; extensions reach Tcl via the stubs table handed through the interp (no host symbol export needed). "Self-contained" and "static libc" are orthogonal. - G-105 (Notes were empty): the dynamic-libc first-linux-target choice is the tclkit model; fully-static-musl 'load' limitation stands; compiled-in alternative is G-058. - G-101 (Notes were empty): the prebuilt tclkit86bi/tclkit-win64-dyn runtimes it replaces are dynamic-libc Metakit kits; loadable binary batteries imply a dynamic-libc runtime; container choice is orthogonal to libc linking. - G-103: temp-copy dll cleanup wart the family runtimes inherit - Tcl core TIP 741 (DRAFT, windows-framed: TclpFinalizeLoad; extract-to-temp preserved vs TIP 709). Requirement (user): test on ALL target platforms (windows, linux/WSL, G-060 guests) that temp-dll/dir accumulation does not happen or is characterized. Applies to G-101's Metakit kits too. - G-060: one-line cross-platform test item pointing at the G-103 requirement. Notes only; no contract changes. goals_lint clean. Assisted-by: harness=claude; primary-model=claude-fable-5; api-location=anthropic.com --- goals/G-060-qemu-test-matrix.md | 4 ++++ goals/G-101-tcl86-kit-container-strategy.md | 17 ++++++++++++++++- goals/G-103-runtime-kit-family.md | 15 +++++++++++++++ goals/G-105-buildsuite-cross-target.md | 16 +++++++++++++++- 4 files changed, 50 insertions(+), 2 deletions(-) diff --git a/goals/G-060-qemu-test-matrix.md b/goals/G-060-qemu-test-matrix.md index 01462ce3..cffd9b55 100644 --- a/goals/G-060-qemu-test-matrix.md +++ b/goals/G-060-qemu-test-matrix.md @@ -62,3 +62,7 @@ direction rather than a new ad-hoc location. - Performance expectations should stay modest (emulated arm will be slow); the matrix is for correctness verification, not speed benchmarking. - Archived-goal references in this file: G-059 achieved 2026-07-11 (goals/archive/G-059-wsl-test-driving.md). +- 2026-07-21: concrete cross-platform test item for this matrix - temp-DLL/dir + cleanup after loading binary batteries out of a kit's VFS (Tcl core TIP 741, + windows-framed): per guest, verify extracted temp copies do not accumulate, or + characterize the flaw. Detail + requirement: G-103 Notes. diff --git a/goals/G-101-tcl86-kit-container-strategy.md b/goals/G-101-tcl86-kit-container-strategy.md index 9fc786d1..67e560d6 100644 --- a/goals/G-101-tcl86-kit-container-strategy.md +++ b/goals/G-101-tcl86-kit-container-strategy.md @@ -40,4 +40,19 @@ wrap), and only worth activating once G-099/G-100 land. ## Notes -(none yet) +- 2026-07-21: the prebuilt runtimes this goal replaces (tclkit86bi.exe, + tclkit-win64-dyn.exe) are Metakit tclkits - self-contained (Tcl + VFS + embedded) yet DYNAMICALLY linked to libc. That dynamic libc is what lets them + 'load' binary extensions (OS dlopen/LoadLibrary + Tcl's stubs table, with the + extension copied out of the mk4vfs to a temp dir first; the host does NOT need + to export Tcl symbols - stubs hand the table to the extension via the interp). + Consequence for the container choice: "loadable binary batteries" implies a + DYNAMIC-libc runtime - a fully-static-libc 8.6 kit would hit the same 'load' + limitation G-105 records for linux (the compiled-in static-packages + alternative is G-058). The container question (metakit/cookfs/zipvfs) is + orthogonal to the libc-linking question; keep them separate at activation. +- 2026-07-21: temp-copy cleanup applies here too - Metakit/starkit 'load' copies + the extension out of the VFS to a temp dir (same as zipfs), and cleanup of + those copies is a known wart (Tcl core TIP 741, windows-framed). This goal's + "loading binary dlls from or via the container" acceptance should characterize + that cleanup per platform - TIP 741 detail + requirement in G-103 Notes. diff --git a/goals/G-103-runtime-kit-family.md b/goals/G-103-runtime-kit-family.md index 5219fd93..2477e244 100644 --- a/goals/G-103-runtime-kit-family.md +++ b/goals/G-103-runtime-kit-family.md @@ -195,3 +195,18 @@ contract the sequencing note promises G-101. the aim across this arc is to validate the general build/test/kit PROCESSES as far as practical, not to rush a publicly releasable product - so a battery whose backend build is heavy must not block the family scaffolding. +- 2026-07-21: the copy-to-temp dll loading these kits rely on (Thread/Tk et al + loaded out of the attached zip - the "open at activation" bullet in Context) + has a known cleanup wart: extracted temp DLLs/dirs are not removed on exit and + accumulate per run. Tcl core TIP 741 (Ashok P. Nadkarni, DRAFT - "Cleanup of + temporary Windows DLL's loaded from zipfs archives") proposes a + TclpFinalizeLoad finalizer that on windows spawns cmd.exe/timeout.exe to delete + the dir after a delay (no-op elsewhere); it PRESERVES the extract-to-temp model + (vs TIP 709's alternative of loading without temp extraction) and 9.0 tracks + the dir in a dllDirectoryName global. TIP 741 frames it windows-specific, but + REQUIREMENT (user 2026-07-21): test on ALL our target platforms (windows + native; linux/WSL per G-105; the G-060 guests) that temp-dll/dir accumulation + either does not happen or is characterized as a known flaw - the family + runtimes are the direct consumers (they load batteries this way). Applies + equally to G-101's Metakit 8.6 kits (same copy-to-temp). + Ref: https://core.tcl-lang.org/tips/doc/trunk/tip/741.md diff --git a/goals/G-105-buildsuite-cross-target.md b/goals/G-105-buildsuite-cross-target.md index a12e3877..2f5c5a98 100644 --- a/goals/G-105-buildsuite-cross-target.md +++ b/goals/G-105-buildsuite-cross-target.md @@ -39,4 +39,18 @@ dimension), G-102 (achieved 2026-07-21 - driver shape settled; target becomes a ## Notes -(none yet) +- 2026-07-21: this goal's dynamic-libc choice for the first linux target has a + working existence proof - standard linux tclkitsh binaries are self-contained + (Tcl core + script library embedded in a Metakit/zip VFS) yet DYNAMICALLY + linked to libc, which is exactly why they can 'load' binary extensions. + Self-contained and static-libc are orthogonal (tclkit gets the first from the + embedded VFS, not by static-linking libc), so the fully-static-musl 'load' + limitation stands and dynamic (glibc-stub-dynamic with a version floor, or + musl-dynamic) is the tclkit model. Compiled-in batteries ('load {} ', no + dlopen) are G-058's alternative. Don't re-litigate at activation. +- 2026-07-21: per-platform temp-file cleanup is part of verifying dynamic-loaded + batteries here - a shared lib loaded from a kit's VFS is copied to a temp dir + first (dlopen/LoadLibrary need a real file) and cleanup of those copies is a + known wart (Tcl core TIP 741, windows-framed). Test on linux/WSL (and the + G-060 guests) that it does not accumulate, or characterize it. TIP 741 detail + + the cross-platform requirement: G-103 Notes.