error: linking with `cc` failed: exit code: 1

Linux

我们在Linux下尝试编写裸机程序，可能出现这样的链接器错误：

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" […]
  = note: /usr/lib/gcc/../x86_64-linux-gnu/Scrt1.o: In function `_start':
          (.text+0x12): undefined reference to `__libc_csu_fini'
          /usr/lib/gcc/../x86_64-linux-gnu/Scrt1.o: In function `_start':
          (.text+0x19): undefined reference to `__libc_csu_init'
          /usr/lib/gcc/../x86_64-linux-gnu/Scrt1.o: In function `_start':
          (.text+0x25): undefined reference to `__libc_start_main'
          collect2: error: ld returned 1 exit status

这里遇到的问题是，链接器将默认引用C语言运行时的启动流程，或者也被描述为_start函数。它将使用我们在no_std下被排除的C语言标准库实现库libc，因此链接器不能解析相关的引用，得到“undefined reference”问题。为解决这个问题，我们需要告诉链接器，它不应该引用C语言使用的启动流程——我们可以添加-nostartfiles标签来做到这一点。

要通过cargo添加参数到链接器，我们使用cargo rustc命令。这个命令的作用和cargo build相同，但允许开发者向下层的Rust编译器rustc传递参数。另外，rustc提供一个-C link-arg标签，它能够传递所需的参数到链接器。综上所述，我们可以编写下面的命令：

cargo rustc -- -C link-arg=-nostartfiles

这样之后，我们的包应该能成功编译，作为Linux系统下的独立式可执行程序了。这里我们没有显式指定入口点函数的名称，因为链接器将默认使用函数名_start。

Windows

在Windows系统下，可能有不一样的链接器错误：

error: linking with `link.exe` failed: exit code: 1561
  |
  = note: "C:\\Program Files (x86)\\…\\link.exe" […]
  = note: LINK : fatal error LNK1561: entry point must be defined

链接器错误提示“必须定义入口点”，意味着它没有找到入口点。在Windows系统下，默认的入口点函数名由使用的子系统决定[1]。对CONSOLE子系统，链接器将寻找名为mainCRTStartup的函数；而对WINDOWS子系统，它将寻找WinMainCRTStartup。我们的_start函数并非这两个名称——为了使用它，我们可以向链接器传递/ENTRY参数：

cargo rustc -- -C link-arg=/ENTRY:_start

我们也能从这里的参数的格式中看到，Windows系统下的链接器在使用方法上，与Linux下的有较大不同。

运行命令，我们得到了另一个链接器错误：

error: linking with `link.exe` failed: exit code: 1221
  |
  = note: "C:\\Program Files (x86)\\…\\link.exe" […]
  = note: LINK : fatal error LNK1221: a subsystem can't be inferred and must be
          defined

产生这个错误，是由于Windows可执行程序可以使用不同的子系统（subsystem）。对一般的Windows程序，使用的子系统将由入口点的函数名推断而来：如果入口点是main函数，将使用CONSOLE子系统；如果是WinMain函数，则使用WINDOWS子系统。由于我们的_start函数名称与上两者不同，我们需要显式指定使用的子系统：

cargo rustc -- -C link-args="/ENTRY:_start /SUBSYSTEM:console"

这里我们使用CONSOLE子系统，但WINDOWS子系统也是可行的。这里，我们使用复数参数link-args代替多个-C link-arg，因为后者要求把所有参数依次列出，比较占用空间。

使用这行命令后，我们的可执行程序应该能在Windows下运行了。

macOS

如果使用macOS系统开发，我们可能遇到这样的链接器错误：

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" […]
  = note: ld: entry point (_main) undefined. for architecture x86_64
          clang: error: linker command failed with exit code 1 […]

这个错误消息告诉我们，链接器不能找到默认的入口点函数，它被命名为main——出于一些原因，macOS的所有函数名都被加以下划线_前缀。要设置入口点函数到_start，我们传送链接器参数-e：

cargo rustc -- -C link-args="-e __start"

-e参数指定了入口点的名称。由于每个macOS下的函数都有下划线_前缀，我们应该命名入口点函数为__start，而不是_start。

运行这行命令，现在出现了这样的链接器错误：

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" […]
  = note: ld: dynamic main executables must link with libSystem.dylib
          for architecture x86_64
          clang: error: linker command failed with exit code 1 […]

得到这个错误的原因是，macOS并不官方支持静态链接的二进制库[2]，而要求程序默认链接到libSystem库。要链接到静态二进制库，我们把-static标签传送到链接器：

cargo rustc -- -C link-args="-e __start -static"

运行修改后的命令。链接器似乎并不满意，又给我们抛出新的错误：

error: linking with `cc` failed: exit code: 1
  |
  = note: "cc" […]
  = note: ld: library not found for -lcrt0.o
          clang: error: linker command failed with exit code 1 […]

出现这个错误的原因是，macOS上的程序默认链接到crt0（C runtime zero）库。这和Linux系统上遇到的问题相似，我们可以添加一个-nostartfiles链接器参数：

cargo rustc -- -C link-args="-e __start -static -nostartfiles"

现在，我们的程序应该能够在macOS上成功编译了。

统一所有的编译命令

我们的裸机程序已经可以在多个平台上编译，但对每个平台，我们不得不记忆和使用不同的编译命令。为了避免这么做，我们创建.cargo/config文件，为每个平台填写对应的命令：

# in .cargo/config

[target.'cfg(target_os = "linux")']
rustflags = ["-C", "link-arg=-nostartfiles"]

[target.'cfg(target_os = "windows")']
rustflags = ["-C", "link-args=/ENTRY:_start /SUBSYSTEM:console"]

[target.'cfg(target_os = "macos")']
rustflags = ["-C", "link-args=-e __start -static -nostartfiles"]

这里，rustflags参数包含的内容，将被自动添加到每次rustc调用中。我们可以在官方文档[3]中找到更多关于.cargo/config文件的说明。

做完这一步后，我们使用简单的一行指令——

cargo build

——就能在三个不同的平台上编译裸机程序了。

我们应该这么做吗？

虽然通过上文的方式，的确可以面向多个系统编译独立式可执行程序，但这可能不是一个好的途径。这么描述的原因是，我们的可执行程序仍然需要其它准备，比如在_start函数调用前一个加载完毕的栈。不使用C语言运行环境的前提下，这些准备可能并没有全部完成——这可能导致程序运行失败，比如说会抛出臭名昭著的段错误。

如果我们要为给定的操作系统创建最小的二进制程序，可以试着使用libc库并设定#[start]标记。有一篇官方文档[4]给出了较好的建议。

参考

1. ^https://docs.microsoft.com/en-us/cpp/build/reference/entry-entry-point-symbol
2. ^https://developer.apple.com/library/content/qa/qa1118/_index.html
3. ^Configuration: Cargo Reference https://doc.rust-lang.org/cargo/reference/config.html
4. ^No stdlib: The Rust Book https://doc.rust-lang.org/1.16.0/book/no-stdlib.html