链接
注意:本节更多地从编译器的角度而不是语言的角度进行描述。
编译器支持各种方法来静态和动态地将包链接在一起。本节将探讨将包链接在一起的各种方法,有关原生库的更多信息可以在本书的 FFI 部分中找到。
在一次编译过程中,编译器可以通过使用命令行标志或 crate_type
属性生成多个工件。如果指定了一个或多个命令行标志,则所有 crate_type
属性都将被忽略,而只构建命令行指定的工件。
-
--crate-type=bin
、#![crate_type = "bin"]
- 将生成一个可运行的可执行文件。这要求在包中有一个main
函数,该函数将在程序开始执行时运行。这将链接所有 Rust 和原生依赖项,生成一个可分发的二进制文件。这是默认的包类型。 -
--crate-type=lib
、#![crate_type = "lib"]
- 将生成一个 Rust 库。这是一个关于究竟生成什么的模糊概念,因为库可以以多种形式体现。此通用lib
选项的目的是生成“编译器推荐”的库样式。输出库始终可由 rustc 使用,但实际的库类型可能会不时更改。其余的输出类型都是不同风格的库,lib
类型可以看作是其中之一的别名(但实际的类型是由编译器定义的)。 -
--crate-type=dylib
、#![crate_type = "dylib"]
- 将生成一个动态 Rust 库。这与lib
输出类型不同,因为它强制生成动态库。生成的动态库可以用作其他库和/或可执行文件的依赖项。此输出类型将在 Linux 上创建*.so
文件,在 macOS 上创建*.dylib
文件,在 Windows 上创建*.dll
文件。 -
--crate-type=staticlib
、#![crate_type = "staticlib"]
- 将生成一个静态系统库。这与其他库输出不同,因为编译器永远不会尝试链接到staticlib
输出。此输出类型的目的是创建一个静态库,其中包含所有本地包代码以及所有上游依赖项。此输出类型将在 Linux、macOS 和 Windows (MinGW) 上创建*.a
文件,在 Windows (MSVC) 上创建*.lib
文件。建议在将 Rust 代码链接到现有的非 Rust 应用程序等情况下使用此格式,因为它不会对其他 Rust 代码具有动态依赖性。 -
--crate-type=cdylib
、#![crate_type = "cdylib"]
- 将生成一个动态系统库。这用于编译要从其他语言加载的动态库。此输出类型将在 Linux 上创建*.so
文件,在 macOS 上创建*.dylib
文件,在 Windows 上创建*.dll
文件。 -
--crate-type=rlib
、#![crate_type = "rlib"]
- 将生成一个“Rust 库”文件。这用作中间工件,可以被认为是“静态 Rust 库”。与staticlib
文件不同,这些rlib
文件在未来的链接中由编译器解释。这实质上意味着rustc
将在rlib
文件中查找元数据,就像它在动态库中查找元数据一样。这种输出形式用于生成静态链接的可执行文件以及staticlib
输出。 -
--crate-type=proc-macro
、#![crate_type = "proc-macro"]
- 生成的输出未指定,但如果为其提供-L
路径,则编译器会将输出工件识别为宏,并且可以为程序加载它。使用此包类型编译的包必须仅导出过程宏。编译器将自动设置proc_macro
配置选项。包始终使用编译器本身构建时使用的目标进行编译。例如,如果您在使用x86_64
CPU 的 Linux 上执行编译器,则目标将是x86_64-unknown-linux-gnu
,即使该包是为不同目标构建的另一个包的依赖项也是如此。
请注意,这些输出是可堆叠的,因为如果指定了多个输出,则编译器将在无需重新编译的情况下生成每种形式的输出。但是,这只适用于由相同方法指定的输出。如果只指定了 crate_type
属性,则将构建所有属性,但如果指定了一个或多个 --crate-type
命令行标志,则只构建这些输出。
对于所有这些不同类型的输出,如果包 A 依赖于包 B,则编译器可以在整个系统中以各种不同的形式找到 B。但是,编译器只查找 rlib
格式和动态库格式。对于这两种依赖库选项,编译器必须在某个时候在这两种格式之间做出选择。考虑到这一点,编译器在确定将使用哪种格式的依赖项时遵循以下规则
-
如果正在生成静态库,则所有上游依赖项都必须以
rlib
格式提供。此要求源于无法将动态库转换为静态格式的原因。请注意,不可能将原生动态依赖项链接到静态库,在这种情况下,将打印有关所有未链接的原生动态依赖项的警告。
-
如果正在生成
rlib
文件,则对上游依赖项可用的格式没有任何限制。 只需所有上游依赖项都可用于从中读取元数据。原因是
rlib
文件不包含任何上游依赖项。 所有rlib
文件都包含libstd.rlib
的副本效率不高! -
如果正在生成可执行文件并且未指定
-C prefer-dynamic
标志,则首先尝试以rlib
格式查找依赖项。 如果某些依赖项在 rlib 格式中不可用,则尝试动态链接(见下文)。 -
如果正在生成动态链接库或正在动态链接的可执行文件,则编译器将尝试协调 rlib 或 dylib 格式的可用依赖项以创建最终产品。
编译器的一个主要目标是确保库在任何工件中都不会出现多次。 例如,如果动态库 B 和 C 都静态链接到库 A,则 crate 不能同时链接到 B 和 C,因为会有两个 A 的副本。编译器允许混合使用 rlib 和 dylib 格式,但必须满足此限制。
编译器目前没有实现任何提示库应该链接什么格式的方法。 动态链接时,编译器将尝试最大化动态依赖项,同时仍然允许通过 rlib 链接一些依赖项。
对于大多数情况,如果动态链接,建议将所有库都作为 dylib 提供。 对于其他情况,如果编译器无法确定要链接每个库的格式,它将发出警告。
通常,--crate-type=bin
或 --crate-type=lib
应该足以满足所有编译需求,如果需要对 crate 的输出格式进行更精细的控制,则可以使用其他选项。
静态和动态 C 运行时
标准库通常努力为目标适当地支持静态链接和动态链接的 C 运行时。 例如,x86_64-pc-windows-msvc
和 x86_64-unknown-linux-musl
目标通常同时提供两种运行时,用户可以选择他们想要的。 编译器中的所有目标都有一种链接到 C 运行时的默认模式。 通常,默认情况下目标是动态链接的,但也有一些例外默认是静态的,例如
arm-unknown-linux-musleabi
arm-unknown-linux-musleabihf
armv7-unknown-linux-musleabihf
i686-unknown-linux-musl
x86_64-unknown-linux-musl
C 运行时的链接配置为尊重 crt-static
目标特性。 这些目标特性通常通过编译器本身的标志从命令行配置。 例如,要启用静态运行时,您将执行
rustc -C target-feature=+crt-static foo.rs
而要动态链接到 C 运行时,您将执行
rustc -C target-feature=-crt-static foo.rs
不支持在 C 运行时的链接之间切换的目标将忽略此标志。 建议在编译器成功后检查生成的二进制文件,以确保它按预期链接。
Crates 还可以了解 C 运行时的链接方式。 例如,MSVC 上的代码需要根据链接的运行时使用不同的方式编译(例如,使用 /MT
或 /MD
)。 这目前通过 cfg
属性 target_feature
选项 导出
#![allow(unused)] fn main() { #[cfg(target_feature = "crt-static")] fn foo() { println!("the C runtime should be statically linked"); } #[cfg(not(target_feature = "crt-static"))] fn foo() { println!("the C runtime should be dynamically linked"); } }
另请注意,Cargo 构建脚本可以通过 环境变量 了解此功能。 在构建脚本中,您可以通过以下方式检测链接
use std::env; fn main() { let linkage = env::var("CARGO_CFG_TARGET_FEATURE").unwrap_or(String::new()); if linkage.contains("crt-static") { println!("the C runtime will be statically linked"); } else { println!("the C runtime will be dynamically linked"); } }
要在本地使用此功能,您通常会使用 RUSTFLAGS
环境变量通过 Cargo 指定编译器的标志。 例如,要在 MSVC 上编译静态链接的二进制文件,您将执行
RUSTFLAGS='-C target-feature=+crt-static' cargo build --target x86_64-pc-windows-msvc