Adding bindgen to build-dependencies prevents crate from being no_std

[aleksanb]

This doesn't really seem intentional, although this might be more of a cargo issue than a bindgen issue.

Minimal example that doesn't work when you add bindgen to build-rependencies:
main.rs:

#![feature(lang_items, start)]
#![no_std]

use core::panic::PanicInfo;
use libc;

#[panic_handler]
fn panic(_panic: &PanicInfo<'_>) -> ! { 
    loop {}
}

#[lang = "eh_personality"]
extern "C" fn eh_personality() {}

#[start]
fn start(_argc: isize, _argv: *const *const u8) -> isize {
    0   
}

Cargo.toml:

[package]
name = "yolo"
version = "0.1.0"
authors = ["aleksanb"]
edition = "2018"

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

[build-dependencies]
bindgen = "*"

I used to invoke bindgen via the shell, which would work fine with my no_std crate, but using it in a build.rs prevents me from using no_std at all.

[emilio]

Hmm, this definitely used to work. This looks to have regressed because a few of the bindgen dependencies use libc with the default features, and cargo only knows about a single dependency graph.

[emilio]

So this is fixable to some extent, by going through bindgen's dependencies and ensuring that libc isn't built with default features. I just checked and it can be done for some, like clang-sys (KyleMayes/clang-sys#85).

Probably we can do the same for all others, or find a way to remove that dependency using a bindgen feature or what not. I cannot commit to do all the work, though I'm happy to help if I find time :)

In any case this is rust-lang/cargo#2589.

[emilio]

I don't think there's something actionable here on bindgen's side, but please reopen if you think otherwise.