(参考链接：https://zhuanlan.zhihu.com/p/69393545)
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上成功编译了。