pack.binfmt: a Mach-O reader for needed_names (#630 §4)

`needed_names` returned "not implemented" for Mach-O; `elf_needed` and
`pe_needed` already read a dependency list without executing anything.
Mach-O gets the same treatment:

- `detail::macho_thin_needed` walks a thin object's load commands:
  `LC_LOAD_DYLIB`, `LC_LOAD_WEAK_DYLIB`, `LC_REEXPORT_DYLIB` and
  `LC_LOAD_UPWARD_DYLIB` contribute names, `LC_RPATH` contributes search
  entries, in load-command order. Both widths (`mach_header`/
  `mach_header_64`) and both endiannesses (the CIGAM magics) are handled.
- `detail::macho_needed` / the exported `macho_needed(path, arch)` add the
  FAT (universal) case: a slice is selected by `cputype` against the
  caller's `arch` (mcpp's canonical spelling), defaulting to the first
  slice when none is given -- which is what `needed_names` does, since it
  has no triple to pass. `FAT_MAGIC` and `FAT_MAGIC_64` are both handled;
  FAT headers are always big-endian on disk regardless of a slice's own
  endianness.
- `needed_names` completes for Mach-O by delegating to `macho_needed`, and
  `is_system_lib` gains a Mach-O row: `/usr/lib/` and `/System/Library/`
  are the operating system's, case-sensitively (`@rpath/...` is a search,
  not a root, so it is never system).
- `resolve_macho_names` is a pure resolver: `@executable_path`,
  `@loader_path` and `@rpath/<x>` (tried against every rpath entry, in
  order, with the same two substitutions) resolve to the first path that
  exists; a name that resolves nowhere is reported as `unresolved`, not
  dropped.

NOT wired into `pack::run`'s Mach-O closure step. Bundling a resolved
dylib beside the program and rewriting its `LC_RPATH` needs a load-command
editor -- a load command has no free space to grow a longer path into --
and the record (§4.2) designs that editor after resolution is measured on
a real macOS build, not before. `pack::run`'s Mach-O branch still reports
"not-walked" (see the sibling #630 §3 commit); this reader and resolver
are exposed for that measurement and for whoever wires them in next.

Tests: unit fixtures built in-process (a tiny Mach-O/fat-Mach-O byte
writer, no external tools, same shape the ELF/PE fixtures already use) --
a thin arm64 object with two `LC_LOAD_DYLIB`, one `LC_LOAD_WEAK_DYLIB` and
two `LC_RPATH`; a fat x86_64+arm64 object whose slices carry different
names, asserting the wrong slice is never read; a big-endian-magic thin
object; the wrong-arch request on a thin file (ignored, as documented);
`is_system_lib`'s Mach-O row; and the resolver's rpath-order and
unresolved-reporting behavior.

Docs: docs/10-pack-and-release.md and the zh mirror note that the closure
is read now, and narrow the "planned" gap to bundling + the `LC_RPATH`
rewrite.

Author: speak-agent

docs/10-pack-and-release.md

@@ -482,6 +482,19 @@ Linux either.
 A `kind = "lib"` / `"shared"` target packs normally on macOS — a library package
 never runs the artifact. This restriction is only for programs.
 
+The dependency closure can now be **read** rather than run — `mcpp.pack.binfmt`
+walks a Mach-O's load commands (`LC_LOAD_DYLIB` and its weak/re-export/upward
+siblings for names, `LC_RPATH` for search entries) the same way it already
+reads a PE's import table, and resolves `@executable_path`, `@loader_path` and
+`@rpath` the way `dyld` would, without loading anything. `mcpp pack` does not
+call it yet: bundling a resolved dylib beside the program needs an editor for
+`LC_RPATH` (a load command has no free space to grow into), and that editor is
+designed once resolution is measured on a real macOS build, not before. Until
+then a Mach-O program still stages without its closure — see [Producing a
+distributable](30-build-mcpp.md#producing-a-distributable-pack_format--stage_dir-20269111)
+for what a dispatched format (`.app`, `.ipa`) can already do with a tree that
+has a program and no closure.
+
 ## Configuration
 
 Packaging behavior is configured via the `[pack]` section in `mcpp.toml`. The
@@ -513,11 +526,12 @@ The `static` mode additionally requires a musl toolchain configured under
 
 ## Planned Support
 
-macOS **program** bundling (the Mach-O dependency closure, via `otool -L` /
-`LC_LOAD_DYLIB`, and `install_name_tool` for relocation) is still on the
-roadmap; until it lands `mcpp pack <program>` refuses on that format rather than
-producing something that only looks like a bundle. Windows DLL bundling beyond
-the current `.zip` is also on the roadmap.
+macOS **program** bundling is still on the roadmap. The closure is read now
+(`mcpp.pack.binfmt`'s Mach-O load-command walk — no `otool` needed), but
+bundling a resolved dylib beside the program and rewriting `LC_RPATH` for it
+is not; until that lands `mcpp pack <program>` still refuses on that format
+rather than producing something that only looks like a bundle. Windows DLL
+bundling beyond the current `.zip` is also on the roadmap.
 
 Distribution formats such as `.deb`, `.rpm`, AppImage and `.msi` are **not** on
 this list, and that is a decision rather than an omission: they live in

docs/zh/10-pack-and-release.md

@@ -408,6 +408,17 @@ mcpp pack --target x86_64-windows-gnu     # 在 Linux 宿主上
 `kind = "lib"` / `"shared"` 目标在 macOS 上照常打包 —— 库打包从不运行产物。
 这条限制只针对程序。
 
+依赖闭包现在可以被**读出来**而不必运行了 —— `mcpp.pack.binfmt` 走一遍 Mach-O 的
+load command(`LC_LOAD_DYLIB` 及其 weak/re-export/upward 三个变体给出名字,
+`LC_RPATH` 给出搜索项),读法与它读 PE 导入表一样;并按 `dyld` 的规则解析
+`@executable_path`、`@loader_path`、`@rpath`,全程不加载任何东西。`mcpp pack`
+还没有调用它:把解析到的 dylib 拷到程序旁边、再重写它的 `LC_RPATH`,需要一个
+load command 编辑器(一条 load command 里没有空间可以塞进更长的路径),这个编辑器
+要等在真实的 macOS 构建上量过解析结果之后才设计,而不是先设计。在那之前,Mach-O
+程序仍然是"暂存但没有闭包"——一个被分发出去的格式(`.app`、`.ipa`)已经能拿这样一棵
+"有程序、没闭包"的树做什么,见
+[产出可分发物](30-build-mcpp.md#产出可分发物pack_format-与-stage_dir20269111)。
+
 ## 配置项
 
 打包行为通过 `mcpp.toml` 中的 `[pack]` 节配置,常用字段如下:
@@ -435,10 +446,11 @@ force_bundle = ["libfoo.so"]        # 即使命中 PEP 600 名单也强制打包
 
 ## 待支持
 
-macOS **程序** bundling(Mach-O 依赖闭包,走 `otool -L` / `LC_LOAD_DYLIB`,
-重定位走 `install_name_tool`)仍在规划中;在它落地之前,`mcpp pack <程序>`
-会在该格式上拒绝,而不是产出一个只是看起来像 bundle 的东西。当前 `.zip`
-之外的 Windows DLL 分发,同样在规划中。
+macOS **程序** bundling 仍在规划中。闭包现在已经能读出来了(`mcpp.pack.binfmt`
+走一遍 Mach-O 的 load command,不需要 `otool`),但把解析到的 dylib 拷到程序旁边、
+再重写它的 `LC_RPATH` 还没做;在这落地之前,`mcpp pack <程序>` 仍会在该格式上拒绝,
+而不是产出一个只是看起来像 bundle 的东西。当前 `.zip` 之外的 Windows DLL 分发,
+同样在规划中。
 
 `.deb`、`.rpm`、AppImage、`.msi` 这些分发格式**不在**这份清单上,而这是一个决定而不是
 一处遗漏:它们住在包里,经 `--format <name>` 到达用户,理由见上一节。`[pack]` 的内建