sx/issues/0130-library-decl-nested-namespace-dropped.md

RESOLVED — 0130: #library declared behind two aliased imports is dropped — no -l flag, no JIT dlopen

RESOLVED (2026-06-12). Root cause as filed: extractLibraries and extractFrameworks (src/main.zig) walked the merged root's decls plus exactly ONE namespace_decl level, while aliased imports nest namespaces arbitrarily deep — a #library/#framework two or more aliases down never reached the AOT link args or the JIT dlopen loop. Both walks are now recursive over namespace_decl children (same seen-set dedup as before). Regression test: examples/1617-modules-library-nested-namespace.sx (+ its module dir) — main → b :: #import → c :: #import where c.sx declares #library "pcap"; libpcap is NOT in the compiler process's loaded images (unlike libz/libbz2/libsqlite3, which CoreServices/LLVM pull in and which mask the bug under sx run), so the pre-fix JIT fails symbol materialization and the pre-fix AOT link dies with undefined _pcap_lib_version. Gates: zig build test 426/426, tests/run_examples.sh 605/605, distribution repo make test 21/21 at its HEAD plus a successful make build of its P5.2 branch state (dist.sx → ops → db → sqlite, the original failing chain).

Symptom

A #library declaration in a module that is reached through TWO (or more) levels of aliased #import never makes it into the build's library list: sx build emits no -l<name> on the link line (link fails with Undefined symbols for every #foreign fn of that library), and sx run skips the dlopen of that library (the JIT then resolves the foreign symbols only if some already-loaded image happens to export them).

• Observed: main → b :: #import "b.sx" → c :: #import "c.sx" where c.sx declares zlib :: #library "z" → link line ends -lc (no -lz), ld: symbol(s) not found: _zlibVersion.
• Expected: every #library reachable through the import graph is linked (AOT) / dlopened (JIT), regardless of import depth or aliasing.
• Control: aliasing c.sx DIRECTLY from main (one namespace level) produces -lz and links fine. A plain (unaliased) #import of c.sx from a module that main aliases also works — the merged decls sit at one namespace level.

Reproduction

Three files in one directory; build a.sx.

// c.sx — declares the library + a foreign fn
#import "modules/std.sx";

zlib :: #library "z";
zlibVersion :: () -> ?cstring #foreign zlib "zlibVersion";

zver :: () -> string {
    p := zlibVersion();
    if p == null { return ""; }
    return from_cstring(p!);
}

// b.sx — first namespace level
#import "modules/std.sx";
c :: #import "c.sx";

ver_via_b :: () -> string { return c.zver(); }

// a.sx — main; c.sx's library now sits two namespace levels deep
#import "modules/std.sx";
b :: #import "b.sx";

main :: () -> i32 {
    print("zlib {}\n", b.ver_via_b());
    return 0;
}

$ sx build -o a a.sx
Undefined symbols for architecture arm64:
  "_zlibVersion", referenced from: ...
error: linking failed

Replacing a.sx's import with c :: #import "c.sx" (and calling c.zver() directly) links and prints the zlib version — same code, one namespace level less.

Found in the distribution repo the first time a product chain nested the SQLite bindings two aliases deep: dist.sx → ops :: #import "release/ops.sx" → db :: #import "../repo/db.sx" → #import "../db/sqlite.sx" loses -lsqlite3 even though the bindings compile fine (the foreign wrappers ARE in main.o; only the link flag is gone).

Investigation prompt

In /Users/agra/projects/sx: extractLibraries (src/main.zig, ~line 877) walks root.data.root.decls and exactly ONE level of namespace_decl children. Aliased imports lower to nested namespace_decl nodes, so a #library (or, same pattern, #framework — see extractFrameworks right below it, ~line 904) sitting two or more namespace levels deep is never collected. Both consumers are affected: the AOT link args (link(...) in src/target.zig receives this list) and the JIT dlopen loop (src/main.zig ~line 274). Fix: make the walk recursive over namespace_decl (a small explicit stack or recursive helper over ns.decls), dedup as today via the seen set; apply the same to extractFrameworks. Verify with the three-file libz repro from issues/0130-library-decl-nested-namespace-dropped.md: sx build must emit -lz and link, sx run must dlopen libz; add an examples/ regression mirroring the repro (one library decl behind two aliased imports) that fails on pre-fix master. Then re-run the distribution repo's make test (which now links SQLite through dist.sx's ops→db→sqlite chain) to confirm the original failure is gone.