Haiku 上 Cargo 启动 rustc 缺 libroot.so：检查 LIBRARY_PATH

Haiku 系统中，直接启动的 Rust 工具链能运行，进入原本没有 LIBRARY_PATH 的会话后执行 cargo build，rustc 却以状态码 3 退出，并提示找不到 libroot.so 等系统库。先比较启动 Cargo 前后的库搜索环境，别急着把系统库复制到 target。

这里的具体条件是从源码构建的 Cargo 1.99.0、x86_64-unknown-haiku，运行于 Haiku 衍生系统 RenkuOS hrev60072。它不能推广为 Linux 的库路径问题，也不能仅凭相同退出码认定其他 Haiku 发行环境都有同一原因。

未设置与只包含构建目录，含义不同

Cargo 为子进程补充动态库搜索目录。正式 Cargo 0.100.0 的 Haiku 分支使用 LIBRARY_PATH，把构建输出路径与启动时已有的变量内容合并；若原变量不存在，就没有已有目录可追加。它的默认目录补充逻辑只对 macOS 单独处理，没有对应的 Haiku 分支。

Haiku r1beta5 的运行时加载器及当前主分支都有一条相应规则：普通加载路径下，若 LIBRARY_PATH 存在，直接使用它；只有变量未设置，才返回包含应用本地库目录及系统库目录的默认列表。安全模式另有处理，不能套用普通会话的判断。

因此，Cargo 添加构建目录后，原来依赖“变量未设置”取得的系统默认目录可能不再参与搜索。上述衍生系统还需要核对自身实际加载器与目录布局；上游源码不能证明它完全没有其他定制。

给当前构建进程保留可信系统目录

先检查 libroot.so 是否确实位于该系统认可的库目录、架构是否匹配，以及会话中的变量究竟未设置、为空，还是已有明确内容。库本身缺失或架构不符时，改搜索路径不能修复安装。

若原变量确实未设置，且已确认当前系统使用下面两个可信目录，可在一次构建的进程环境中明确带上它们：

env LIBRARY_PATH='/boot/system/non-packaged/lib:/boot/system/lib' cargo build

这条示例会执行项目构建及其构建脚本，不是只读检查。目录必须按当前系统核实，不能加入下载目录、可被其他用户写入的目录或空路径项。若项目还需要应用本地库目录，应按其实际发布布局保留，不能把这两个系统目录当作完整的通用默认列表。

原 LIBRARY_PATH 已有内容时，应保留经审查的原顺序与项目目录，再补上确实缺失的系统路径，不要照抄示例覆盖它。优先把调整限制在该构建入口，确认有效后再评估是否纳入 CI 或会话配置；无需改全机动态加载器配置，也不要把变量换成 Linux 常用的 LD_LIBRARY_PATH。

分别验证编译、测试与运行

先确认 Cargo 启动的编译器不再因缺少系统库退出，再检查原构建是否成功。项目需要测试或 cargo run 时，应分别从原入口验证；测试二进制可能位于不同的构建子目录，编译器能启动不能证明这些运行阶段也都正确。

保存工具链版本、会话环境差异与第一条加载器错误。取消临时调整后应能恢复原环境；后续替换 Cargo 或系统镜像时，重新比较实际库搜索路径，不以一次构建成功推断所有 Haiku 平台或所有子进程都已恢复。