Bindgen features not additive

[jethrogb]

If you have two different dependencies that both depend on bindgen, but dependency A uses static linking and dependency B using dynamic linking, this will fail to build.

You can test this easily with the following Cargo.toml:

[dependencies]
bindgen57 = { version = "0.57", package = "bindgen", default-features = false, features = ["static"] }
bindgen58 = { version = "0.58", package = "bindgen", default-features = false, features = ["runtime"] }

Cargo features are supposed to be additive, i.e. one crate in your dependency tree should never fail to build because another crate elsewhere in your dependency tree enables some feature.

There's also a related issue where if you do something like this:

[dependencies]
bindgen57 = { version = "0.57", package = "bindgen", default-features = false }
bindgen58 = { version = "0.58", package = "bindgen", default-features = false, features = ["runtime"] }

This will build, but it will panic at runtime:

thread 'main' panicked at 'a `libclang` shared library is not loaded on this thread', .../.cargo/registry/src/github.com-1ecc6299db9ec823/clang-sys-1.2.0/src/lib.rs:1682:1

See also https://github.com/KyleMayes/clang-sys/issues/128

[emilio]

Yeah, this was known when taking #1617, but there didn't seem to be a lot of better solutions to this problem. Better ideas def. welcome.

[jethrogb]

You need to choose one of the features to override the other. It's not really clear to me what the difference is between “no features”, the “runtime feature”, but I'd suggest:

(default behavior): dynamic linking static: this forces static linking

Also, IIUC, if static feature is enabled by clang-sys, you need to call it in a different way. So then the existence of this feature should be propagated by clang-sys's build script to dependents using the DEP_... environment variable.

[jethrogb]

Another option would be that the dependents that want static linking get static linking, and the ones that want dynamic linking get dynamic linking? You'd need two separate crates, or types, or a builder to do this properly.

[emilio]

I need to page this back in, but IIRC the problem is that there are effectively three behaviors, not two:

• Static linking (what you get with the static feature).
• Runtime dynamic linking (the default behavior).
• Dynamic linking (linking to the .so, like a static library)

[jethrogb]

Ah, that makes sense. So yeah you have to make a choice between static and dynamic. But runtime could be used independently, assuming symbols are sufficiently namespaced?

[robin-nitrokey]

I ran into this issue when trying to use both littlefs2-sys and nettle-sys in the same crate.

example Cargo.toml

``` [package] name = "bindgen-test" version = "0.1.0" edition = "2021" [dependencies] littlefs2-sys = "0.1.6" nettle-sys = "2.1.0" ```

Is there any way to work around this issue? If not, how should littlefs2-sys and nettle-sys be changed to avoid it?

[robin-nitrokey]

Also, if this isn’t fixed in the code, it should at least be documented to make users aware of this issue and how to fix it.

[nickray]

Perhaps a solution based on --cfg flags would be preferable over mutually exclusive features. This is an example of another library taking this approach: https://github.com/dalek-cryptography/curve25519-dalek/pull/455