How do I find out which crate dependency is requiring the standard library to be linked?

I want to completely eliminate the dependency on std in my project so I disable the std feature in extern crates.

Somehow the final product is still linked to std, so I want to figure out which external crate is causing the linkage to std.

Just removing the std feature if a crate has one won’t stop you from linking in std, what you are actually looking for is the #![no_std] attribute (relevant chapter from The Book). This completely removes the standard library, only letting you use things from core.

As a warning, adding #![no_std] to your program will probably break a lot of stuff… And I do mean a lot! You mainly use no_std when you don’t have an operating system, like when you are programming for a microcontroller or if are the operating system. Most crates are built against the standard library because it gives you access to useful things like Vec and std::process::Command, whereas programs which run in a no_std context usually don’t even have access to an allocator.

Out of curiosity, why do you want to completely remove the dependency on std? That’s kinda like a C program not using libc

1 Like

One reliable trick I have used for this (realistic for libraries) is to use xargo. It compiles a custom libcore (and libstd if needed). If you don’t configure a std, it doesn’t use it by default. So simply compiling your project with xargo should be able to spot if something is linking to std.


Thanks. I’m aware of #![no_std] and have specified that in my root crate. I’m programming for a special environment with a custom std library that redefines items in std. So I have to eliminate std to avoid redefinition errors (e.g. for f32 and panic_fmt). Somehow disabling std for extern crates still causes such redefinitions errors. Hence the question :slight_smile:

1 Like

Thanks. Will take a look. My environment requires a custom std. Xargo looks relevant.