Rust libc crate 是否会抑制自定义恐慌处理程序的编译? [英] Does Rust libc crate inhibit the compilation of custom panic handler?

问题描述

所以我们目前正在尝试编译一些 Rust 代码，然后我们可以链接到一些 C 代码.为此，我们使用 Bindgen 生成 FFI，然后我们将使用它从 Rust 调用一些 C 函数.

So we are currently trying to compile some Rust code that we can then link to some C code. To do this we are using Bindgen to generate an FFI, and then we will use it to call some C functions from Rust.

但是，我们必须首先在项目的 Cargo.toml 文件中将 crate "libc" 作为依赖项.我们目前正在处理的项目要求我们使用 crate 范围内的 !#[no_std] 属性，因为我们不想要 Rust 的整个 stdlib.我们只需要核心.libc crate 说我们可以通过在Cargo.toml 文件，即:

However, we must first have the crate "libc" as a dependency in the Cargo.toml file of the project. The project we are currently working on demands that we use the crate wide !#[no_std] attribute, as we don't want the entire stdlib of Rust. We only need the core. The libc crate says we can "request" it not be linked to the standard library by putting some options in the Cargo.toml file, namely:

[dependencies]
libc = { version = "0.2", default-features = false }

这一切都很好，但是当我们尝试编译时，会收到以下错误消息.

This is all fine and dandy, but when we try to compile we get the following error message.

Ubuntu:~/nautilus/src/rust/example# cargo build
   Compiling example v0.0.0 (/home/me/nautilus/src/rust/example)
error[E0152]: duplicate lang item found: `panic_impl`.
  --> src/lib.rs:33:1
   |
33 | / pub fn nk_rust_panic(_info: &PanicInfo) -> !
34 | | {
35 | |    // should call nk_panic here...
36 | |    loop { }
37 | | } 
   | |_^
   |
   = note: first defined in crate `std`.

error: aborting due to previous error

For more information about this error, try `rustc --explain E0152`.
error: Could not compile `example`.

To learn more, run the command again with --verbose.

E0152 如下

A lang item was redefined.

Erroneous code example:

```
#![feature(lang_items)]

#[lang = "arc"]
struct Foo; // error: duplicate lang item found: `arc`
```

Lang items are already implemented in the standard library. Unless you are
writing a free-standing application (e.g. a kernel), you do not need to provide
them yourself.

You can build a free-standing crate by adding `#![no_std]` to the crate
attributes:

```
#![no_std]
```

我们的 lib.rs 文件已经有 #![no_std] 了，但看起来因为 libc 通常会链接到 stdlib，所以 Rust 可能认为如果我们使用 libc，我们就不能有自定义的恐慌处理程序.

Our lib.rs file has #![no_std] already in it, but it appears that since libc would normally link against stdlib, that maybe Rust thinks that we cannot have a custom panic handler if we are using libc.

当我们从 Cargo.toml 文件中删除 libc 并从 lib.rs 中删除 extern crate lib 时，问题自行解决.

The problem relieves itself when we remove libc from the Cargo.toml file, and remove the extern crate lib from lib.rs.

lib.rs

// no stdlib
#![no_std]

// Give us this feature to override?
#![feature(start)]

#![feature(lang_items)]

// avoid buildins - we want it to use our library
#![no_builtins]

// The following cruft is here to handle Rust->OS dependencies
// currently only one:  Rust needs to know how to panic
use core::panic::PanicInfo;

extern crate libc;
#[panic_handler]
#[no_mangle]
pub fn nk_rust_panic(_info: &PanicInfo) -> !
{
   // should call nk_panic here... (panic handler of OS)
   loop { }
}

Cargo.toml

[package]
name = "example"  # this is for core-kernel
version = "0.0.0"


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

[dependencies]
libc = { version = "0.2", default-features = false }

[build-dependencies]
bindgen = "0.42.2"

[profile.dev]
panic = "abort"    # no stack unwind on rust panic

[profile.release]
panic = "abort"    # no stuck unwind on rust panic

那么，总而言之，使用 libc 作为依赖项是否会使我们无法使用我们自己的自定义恐慌处理程序?是否有任何不稳定的编译器标志我们可以直接传递给 rustc 来消除这个问题?

So, in sum, does using libc as a dependency make us unable to use our own custom panic handler? Are there any wonky compiler flags we can pass directly to rustc to eliminate this problem?

编译器是 1.32.0-nightlylibc 版本为 libc v0.2.44

Compiler is 1.32.0-nightly Libc version is libc v0.2.44

推荐答案

您在 Cargo 中遇到了一个错误.

You are running into a bug in Cargo.

功能有点微妙.它们可以通过任何传递依赖启用，这是预期的行为.但是，它们甚至可以通过传递的 build 依赖项启用，这是一个 错误.

Features are a bit subtle. They can be enabled by any transitive dependency, which is expected behaviour. However, they can even be enabled by transitive build dependencies, which is a bug.

这篇关于Rust libc crate 是否会抑制自定义恐慌处理程序的编译?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！