多Crate Rust项目打包为.deb包的依赖问题咨询

项目概况 #

需打包为.deb的Rust项目包含：

• 核心库 crate：core_lib
• 依赖核心库的库：pam_lib
• 依赖核心库的二进制程序：cli_binary

核心库core-lib的Cargo.toml配置：

[package]
name = "core-lib"
version = "0.1.0"
edition = "2021"

[lib]
crate-type = ["dylib"]

[dependencies]
...

二进制程序cli-binary的Cargo.toml配置：

[package]
name = "cli-binary"
version = "0.1.0"
edition = "2021"

[dependencies]
core-lib = { path = "../../Rust core/core-lib" }
...

问题1：动态链接路径的规范配置 #

尝试两种方案均遇阻：

• 指定rpath编译：用cargo rustc -r -- -C link-args='-Wl,-rpath,/usr/lib/x86_64-linux-gnu/mylib'指定共享库路径，打包后lintian报custom-library-search-path错误。
• ldconfig配置方案：计划在/etc/ld.so.conf.d/新增配置文件指向目标路径，postinst脚本执行sudo ldconfig更新，但不确定是否符合Debian规范。

解决方案 #

1. 优先使用系统标准库路径
   Debian默认系统库路径为/usr/lib/x86_64-linux-gnu/，直接将core_lib安装到该路径，无需额外rpath或ldconfig配置，可直接规避lintian报错，完全符合系统规范。

2. 自定义路径的规范做法
   若必须使用自定义路径：

• 在/etc/ld.so.conf.d/下创建mylib.conf文件，内容为自定义路径/usr/lib/x86_64-linux-gnu/mylib。
• postinst脚本中执行ldconfig（deb脚本以root权限运行，无需sudo）；postrm脚本删除该.conf文件后，同样执行ldconfig刷新缓存。这种方式是Debian系统级库路径配置的标准流程，完全合规。

问题2：核心库重复编译与符号不匹配 #

编译pam_lib或cli_binary时，都会在target/release生成core_lib，但不同编译产出的libcore_lib.so无法互换；单独编译core_lib后，二进制运行时出现unknown symbol错误，且不想重复复制库文件。

解决方案 #

1. 统一核心库的编译与安装流程

• 单独编译core_lib（--release模式），注意Rust编译dylib默认生成带哈希后缀的文件名（如libcore_lib-xxxxxx.so），可通过cargo rustc -- -C link-args='-Wl,-soname,libcore_lib.so.0'指定soname，打包时创建对应软链接（libcore_lib.so -> libcore_lib.so.0）。
• 将编译好的core_lib安装到系统标准路径，确保pam_lib和cli_binary编译时链接到系统路径下的库，而非本地target目录的临时版本。

2. 用Cargo Workspace统一管理依赖
   创建项目根目录的Cargo.toml作为workspace配置：

[workspace]
members = [
    "core-lib",
    "pam-lib",
    "cli-binary"
]

通过workspace，Cargo会统一管理核心库的编译，避免重复生成不同版本的core_lib，确保所有依赖项使用同一版本的核心库。

3. 保证编译配置一致性

• 所有crates使用相同的Rust版本、edition配置，编译时统一使用--release模式，避免因编译参数差异导致符号不匹配。
• 用nm -D libcore_lib.so查看核心库的导出符号，对比二进制程序的未定义符号（nm -D cli_binary | grep U），确认缺失符号是否存在于核心库中。

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