rust - 如何解决为什么 cargo/rustc 链接在 rust 标准库符号中，即使使用了 no_std？

Question

我正在尝试创建一个嵌入友好的可执行文件(占用空间小，不依赖于 Rust 标准库)，它使用一个已经支持 no_std 构建的库 (wasmi)。 Rust 的新手，我只是将指令拼凑在一起，但它的要点似乎是 follow the steps .

对于可执行文件:

#![no_std]
#![no_main]

use core::panic::PanicInfo;

/// This function is called on panic.
#[panic_handler]
fn panic(_info: &PanicInfo) -> ! {
    loop {}
}

#[no_mangle]
pub extern "C" fn _start(_argc: isize, _argv: *const *const u8) -> ! {
    interpret(_argc, _argv);
    loop {}
}

也就是:

• 包含#![no_std]
• 定义我们的入口(不是 main 因为我们没有运行时会调用它)
• 并定义一个 panic 处理程序，因为 Rust std lib 不包括在内，无法为我们定义它。

我用来编译的 Cargo 文件如下所示:

[package]
 name = "driver"
 version = "0.1.0"
 edition = "2018"

[dependencies.wasmi]
 path = "../../github_dev/wasmi" 
 features = ["core"]
 default-features = false
 test=false
 bench=false

 [profile.release]
 panic = "abort"
 lto = true
 incremental=false
 debug=true
 opt-level = "z"
 test=false
 bench=false

并生成一个非常小的二进制文件，它排除了任何标准库符号(使用 nm 进行检查)并按预期运行。

当我实际尝试调用 wasmi 库中的函数时出现问题。它是通过 features=core 行使用 no_std 构建的。对 release/deps/libwasmi-*.rlib 中的文件执行 nm 显示没有标准库符号。但是，当使用此命令进行链接时:

rustc --release --verbose -- -C link-arg=-nostartfiles

它导致:

   Compiling driver v0.1.0 (/home/my_home/wasmi_embed/driver)
     Running rustc --edition=2018 --crate-name driver src/main.rs --color always --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C link-arg=-nostartfiles -C metadata=957eda2e590447ba -C extra-filename=-957eda2e590447ba --out-dir /home/my_home/wasmi_embed/driver/target/release/deps -L dependency=/home/my_home/wasmi_embed/driver/target/release/deps --extern libc=/home/my_home/wasmi_embed/driver/target/release/deps/liblibc-f7fb773c7b059a14.rlib --extern wasmi=/home/my_home/wasmi_embed/driver/target/release/deps/libwasmi-534aef1926b4eb6c.rlib

然后发生错误:

error[E0152]: duplicate lang item found: panic_impl.
  --> src/main.rs:31:1
   |
31 | / pub extern fn panic(_info: &PanicInfo) -> ! {
32 | |     loop {}
33 | | }
   | |_^
   |
   = note: first defined in crate `std`.

Rust 似乎正在尝试链接标准库支持以至少支持 panic 处理，但我不知道为什么。

我想了解原因并了解如何预防。

如果我删除 panic_impl 属性，那么我的可执行文件会编译，但它包含许多我试图阻止的标准库符号。

我看到的示例符号是:

my_home@my_puter:~/wasmi_embed/driver/target/release$ nm --demangle -A -a -B -s --line-number test_2018 2>/dev/null | grep std
driver:00000000000264c0 t rust_begin_unwind  /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:311
driver:00000000000264a0 t rust_oom   /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/alloc.rs:203
driver:000000000001f490 t rust_panic /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:524
driver:0000000000025aa0 t _$LT$std..panicking..continue_panic_fmt..PanicPayload$LT$$u27$a$GT$$u20$as$u20$core..panic..BoxMeUp$GT$::get::he4f810e299a2e0b4    /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:372
driver:00000000000259a0 t _$LT$std..panicking..continue_panic_fmt..PanicPayload$LT$$u27$a$GT$$u20$as$u20$core..panic..BoxMeUp$GT$::box_me_up::hd8430725259668a8     /rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/panicking.rs:367
driver:0000000000021520 t _$LT$std..sys_common..process..DefaultEnvKey$u20$as$u20$core..borrow..Borrow$LT$std..ffi..os_str..OsStr$GT$$GT$::borrow::hbacd0cd7d7fbf1c1/rustc/8e2063d02062ee9f088274690a97826333847e17//src/libstd/sys_common/process.rs:27
driver:0000000000021570 t _$LT$std..error..$LT$impl$u20$core..convert..From$LT$alloc..string..String$GT$$u20$for$u20$alloc..boxed..Box$LT$$LP$dyn$u20$std..error..Err
... plus more

上述符号在dep目录下的任何rlib文件中都找不到，包括libwasmi，在不调用libwasmi代码时在驱动程序可执行文件中也找不到。

我读过 a similar issue (因此 Cargo.toml 中的 test=false 和 bench=false)但这并没有帮助。我尝试仅使用 rustc 使用不同的命令(不包括 Cargo)进行构建，但错误是相同的。我曾尝试将 wasmi 编译为静态库 (ar) 并将其链接进来，但作为 Rust 的新手，我花了很多时间尝试将其链接进来，但它并没有发生。

Answer 1

我在 Rust 论坛寻求帮助后解决了这个问题。 enter link description here .具体来说，无法确定是什么导致 rust std lib 被链接到我的可执行文件中......是 crate 问题还是 cargo 问题还是 rustc 问题还是链接器问题。我不知道问题出在哪里，但基于提交的类似错误，我认为以某种方式编译了一个 crate 以引入意外的 std lib。结果是错误 enter link description here即使错误消息相同，也不相关。我没有遇到来自不同类型依赖项(开发依赖项和构建依赖项)的意外传播的问题。我尝试了所有这些技术来查明是什么引入了 std lib:

1. 我尝试使用 cargo tree 来列出依赖项以列出所有 crate依赖项:

   wasmi v0.4.3 (/home/jlb6740/github_dev/wasmi)
   ├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder)
   ├── hashbrown v0.1.8 (/home/jlb6740/github_dev/hashbrown)
   │ ├── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
   │ └── scopeguard v0.3.3 (/home/jlb6740/github_dev/scopeguard)
   ├── libm v0.1.2
   ├── memory_units v0.3.0
   └── parity-wasm v0.31.0 (/home/jlb6740/github_dev/parity-wasm)
   └── byteorder v1.3.1 (/home/jlb6740/github_dev/byteorder) ()
   

2. 我尝试使用 cargo rustc --verbose … 但此时 verbose不表示任何东西正在使用默认功能，其中可能包括使用标准

3. 我尝试使用 cargo 元数据……这生成了一长串难以解析的依赖项，但我确实看到了一些实例其中 scopeguard 和 byteorder 具有需要 std 的默认功能支持。我下载了所有这些 crate 并进行了硬编码属性，以便 crates 只能在没有 std 支持的情况下构建。

4. 我尝试查看 deps/输出并对所有rlibs 查看是否有任何库使用了在 std 中找到的符号。我找不到是这样的。我以为 rlibs 就像静态库，他们使用的任何东西都将包含在rlib 但显然不是。

5. 我查看了 cargo rustc -- -C --print-link-args 来检查链接器标志，但我找不到任何明显的东西告诉我它是引入标准库。

这些都没有帮助我确定是什么引入了 std lib。最终，rust 论坛上的建议是对根本不允许 std lib 的目标使用 cargo check。此处列出了带有 * 的人:enter link description here只有核心支持。我试过了，使用 --target=thumbv7m-none-eabi 运行并看到:

错误[E0463]:找不到分配的箱子
–>/home/jlb6740/github_dev/hashbrown/src/lib.rs:44:1
|
44 | extern crate std as alloc;
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^找不到箱子

原来它是 hashbrown，它是我的可执行文件依赖项的依赖项。它默认构建了 no_std，但有一个 extern std 以不同的名称链接，并由一个名为“nightly”的功能保护。在我除了 no_std 之外不构建任何东西的努力中，守卫被禁用了。在此之前，我尝试过的任何事情都没有提醒我负责的 crate 。似乎应该有比 cargo tree 提供的更好的方法来获得更全面的 crate 依赖项列表，但是更改 wasmi cargo 以确保设置了 nightly 功能解决了我的问题。