lld问题包需包含：目标文件（.o）、显式链接的静态库（.a）、完整sysroot的usr/lib和lib目录、完整命令行（repro.sh）、lld/clang版本信息（versions.txt），并用-wl,--verbose和-wl,--trace-symbol等参数开启诊断输出以确保可复现。
LLD 本身不提供“生成问题包”的内置命令，但可通过组合 lld 的诊断输出 + 环境快照 + 输入文件归档，构造出可复现的最小链接问题包。 关键不是打包工具，而是确保别人拿到后能原样复现 lld 报错——尤其是符号未定义、库路径失效、目标格式冲突这类典型问题。
怎么让 lld 输出足够诊断的详细信息
只靠 lld 默认错误（比如 undefined reference to 'foo'）往往不够定位。必须打开符号解析和搜索路径的“透视模式”：
- 加
-Wl,--verbose：打印所有输入文件、库搜索路径、尝试打开的每个.a/.so文件名，以及是否成功打开 - 加
-Wl,--trace-symbol=xxx（多次）：跟踪特定符号的定义/引用来源，确认它到底来自哪个.o或.a - 加
-v（传给clang）：看最终调用的lld命令行是否含--sysroot、-L、-l，避免前端参数被静默丢弃 - 若报
cannot find -lc，必须同时加-Wl,--verbose和-Wl,--allow-multiple-definition（临时绕过，只为确认路径）
哪些文件必须打包进问题包
漏掉任意一项，接收方大概率无法复现。不要依赖“系统有对应 sysroot”这种假设：
-
main.o、utils.o等直接参与链接的目标文件（不是源码，是编译后的.o） - 所有显式链接的静态库：
libfoo.a、libc.a（哪怕来自sysroot，也得拷出来） - 完整
sysroot的usr/lib和lib目录（或至少其中被-L引用的子路径） - 实际执行的完整命令行（例如
clang -target aarch64-linux-gnu -fuse-ld=lld -L... -lc ...），保存为repro.sh -
lld --version和clang --version输出，写入versions.txt
为什么 --sysroot 单独打包还不够
lld 不像 GNU ld 那样自动从 --sysroot=/path 推导 /path/usr/lib；它只认显式 -L。所以即使你传了 --sysroot，问题包里仍必须包含：
- 对应
--sysroot路径下的usr/lib内容（尤其libc.a、libm.a） - 明确写出的
-L/path/to/sysroot/usr/lib在repro.sh中，不能只写--sysroot=... - 若用
llvm-mingw工具链，需额外打包其lib/gcc/...下的libgcc.a，因为lld-link不自动搜这个路径
交叉链接时最容易漏的 Windows / macOS 差异点
同一份 clang 命令，在 Linux 上调 lld，在 Windows 上可能静默调 link.exe，导致问题包在对方机器上根本跑不起来：
- Windows 下必须验证
repro.sh中-fuse-ld=lld是否触发了lld-link.exe：运行时加-v，末行应出现lld-link.exe而非link.exe - macOS 下
-fuse-ld=lld可能被忽略（当前 clang 对 Mach-O 交叉支持弱），此时需改用-fuse-ld=ld64.lld并确认存在该二进制 - 所有路径分隔符统一用正斜杠
/，避免 Windows 批处理中反斜杠转义问题
真正卡住复现的，往往不是 lld 本身，而是 sysroot 结构不一致、-L 路径没对齐、或者目标平台隐式切换了链接器。打包时多花三十秒检查 -Wl,--verbose 输出里的实际搜索路径，比事后反复追问“你用的是哪个版本的 llvm-mingw”高效得多。
