Rust build.rs静态链接库时无法找到C++标准库问题

在-sys crate中本地编译上游C/C++库、静态链接规避用户预装依赖的思路是Rust生态的通用实践，收益明确，但需要明确不同依赖的链接策略边界：

• 自编译的上游目标库libfoo非常适合静态链接：可以彻底规避不同发行版源中libfoo版本碎片化、缺失开发包的问题，大幅降低用户的使用门槛，跨发行版兼容性提升明显。
• 系统级基础运行时库禁止静态链接：包括glibc、libstdc++、libgcc_s、libpthread、libm、动态链接器ld-linux在内的组件，和当前系统的C/C运行时、内核版本强绑定，静态链接会引发大量难以排查的问题：比如C异常跨二进制边界崩溃、内存分配/释放接口不匹配、glibc的NSS模块加载失败、系统调用兼容性异常等。这类库是所有Linux发行版默认预装的基础组件，直接动态链接即可，没有打包的必要。
• 第三方非系统基础依赖（如示例中的libjpeg）可按需选择链接方式：如果是发行版普遍预装、ABI稳定的版本（比如libjpeg.so.8是兼容度极高的旧稳定版），直接动态链接系统版本即可；如果需要绑定特定功能版本、不想要求用户额外安装开发包，也可以将其一并从源码编译后静态链接，这类没有和系统运行时强绑定的库静态链接不会有兼容性问题。

静态链接libfoo.a时出现C++符号找不到是正常现象：和动态链接不同，静态库不会自动携带自身依赖的链接信息，需要手动按依赖顺序声明所有需要链接的下游库。
首先澄清几个常见误区：

• println!("cargo:rustc-link-lib=static=stdc++") 语法本身合法，但生效前提是系统中存在libstdc++.a静态归档文件。你当前只能找到libstdc++.so.6，说明没有安装对应C运行时的静态开发包，而且如前所述，静态链接libstdc本身就不推荐，直接动态链接即可。
• cargo:rustc-link-lib的库查找逻辑和gcc完全一致，优先查找无版本后缀的开发软链接（比如libstdc++.so通常是发行版开发包提供的、指向当前系统默认libstdc++版本so的软链接），普通用户环境中只有带版本号的运行时so、没有无版本软链接是正常的。不要直接链接带版本号的so文件，这种写法会硬编码绑定特定小版本，跨发行版甚至同发行版不同小版本升级后都可能出现兼容问题。

正确的build.rs链接配置参考如下，注意链接顺序：静态库必须放在它所依赖的库之前：

// 先声明本地编译库存放的搜索路径
println!("cargo:rustc-link-search=native={}", lib_out_path);
// 静态链接自行编译的libfoo
println!("cargo:rustc-link-lib=static=foo");
// 按依赖顺序声明需要动态链接的系统库，必须包含libstdc++，否则C++符号无法解析
println!("cargo:rustc-link-lib=dylib=stdc++");
println!("cargo:rustc-link-lib=dylib=gcc_s");
println!("cargo:rustc-link-lib=dylib=pthread");
println!("cargo:rustc-link-lib=dylib=jpeg");
println!("cargo:rustc-link-lib=dylib=m");
println!("cargo:rustc-link-lib=dylib=c");

配置时注意几个细节：

• 声明系统库链接时不需要加版本号，链接器会自动查找系统中ABI兼容的最新版本，运行时也会自动匹配系统自带的对应库文件，兼容性远好于硬编码版本号。
• 如果编译时提示找不到libstdc++.so，说明用户环境缺少C开发包（比如Debian/Ubuntu系需要装build-essential/libstdc++-dev，RHEL/Fedora系需要装gcc-c++），这是Linux下编译C/C代码的标准基础依赖，提示用户安装即可，接受度远高于要求用户单独安装libfoo的开发包。
• 如果目标是构建完全无系统依赖的静态二进制，不要静态链接系统自带的glibc和libstdc++，换用musl工具链搭配libc++编译即可，这种方案适合独立分发的可执行文件，不适合作为通用-sys crate的默认配置。

• 编译上游库以及你选择静态链接的第三方依赖（比如libjpeg）时，一定要加-fPIC编译参数，否则静态链接到Rust生成的库文件时会触发重定位相关的编译错误。
• 如果选择静态链接第三方依赖，不要把对应so文件放到输出目录，否则运行时会优先查找本地so，反而容易出现依赖缺失问题。
• 编译完成后可以用ldd检查最终生成的crate产物依赖，确认所有非系统库都已静态嵌入，系统依赖都指向系统默认路径，没有找不到的依赖项。

内容的提问来源于stack exchange，提问作者phip1611