Open rtfeldman opened 11 months ago
It looks like the gimli based symbilizer is unconditionally used on unix, even if the std feature is disabled. It requires fs libc calls to load debug info. If you are on neither Windows nor Unix you will get a noop symbolizer impl though which doesn't need libstd.
Hm, are you sure? Here's what I see for cargo tree
on backtrace-rs
:
backtrace v0.3.69
├── addr2line v0.21.0
│ └── gimli v0.28.0
├── cfg-if v1.0.0
├── libc v0.2.147
├── miniz_oxide v0.7.1
│ └── adler v1.0.2
├── object v0.32.1
│ └── memchr v2.6.3
└── rustc-demangle v0.1.23
[build-dependencies]
└── cc v1.0.83
└── libc v0.2.147
[dev-dependencies]
├── dylib-dep v0.1.0
└── libloading v0.7.4
└── cfg-if v1.0.0
So gimli v0.28.0 comes in from addr2line v0.21.0.
addr2line
0.21.0 depends on gimli
like this:
gimli = { version = "0.28.0", default-features = false, features = ["read"] }
So only the read
feature. But gimli 0.28.0 only brings in the std
crate when the std
or write
features are enabled, and addr2line doesn't enable either of those features.
Putting those together, it seems like this indirect gimli dependency should still be no_std
, yeah?
The glue code in backtrace-rs which uses gimli/addr2line uses libstd: https://github.com/rust-lang/backtrace-rs/blob/a390aa732132b7cfcc1404a39178f5dbd3926ccc/src/symbolize/gimli.rs#L17-L27
Ah, I see. So I guess it's not a goal for the crate to actually support no_std
, but rather that's an implementation detail of it being a part of std
?
I'm happy to accept PRs that improve the situation without breaking things for std-using programs, but it is very true it might be... challenging.
I reproduced this with a minimal
#![no_std]
executable that does nothing but return an exit code:main.rs
cargo run
works as expected (exits with code 42) with the followingCargo.toml
, which includes thebacktrace
dependency (withdefault-features = false
so it doesn't have thestd
feature):Cargo.toml
At least in macOS, I needed to add compiler flags for this to run; here is my
.cargo/config.toml
.cargo/config.toml
At this point, if I actually try to use
backtrace
- doing nothing else but addinguse
tomain.rs
like so:...now
cargo check
fails, saying thatbacktrace
is bringing in thestd
crate which introduces a conflictingpanic_impl
implementation:Note that the
error[E0152]: found duplicate lang item 'panic_impl'
explicitly saysthe lang item is first defined in crate 'std' (which 'backtrace' depends on)
, and that everything worked until I added the (unused)use backtrace::trace_unsynchronized;
declaration. Also, I know thestd
feature is off, because if I try to import something that needs it (e.g.backtrace::Backtrace
), I get an error.This is with stable rustc 1.68.0 (2c8cc3432 2023-03-06) and cargo 1.68.0 (115f34552 2023-02-26).
Unfortunately, this seems to make it impossible to use
backtrace
in ano_std
executable - unless I'm missing something!