failed to select a version for clang-sys which could resolve this conflict

[duhruh]

I'm running into issues trying to run the examples with the asio feature turned on on
I might be doing something wrong here, wondering if anybody can help.

C:\project\foo>cargo run
    Updating crates.io index
error: failed to select a version for `clang-sys`.
    ... required by package `bindgen v0.42.0`
    ... which is depended on by `asio-sys v0.1.0`
    ... which is depended on by `cpal v0.11.0`
    ... which is depended on by `audio v0.1.0 (C:\project\foo)`
versions that meet the requirements `^0.24` are: 0.24.0

the package `clang-sys` links to the native library `clang`, but it conflicts with a previous package which links to `clang` as well:
package `clang-sys v0.28.1`
    ... which is depended on by `bindgen v0.53.1`
    ... which is depended on by `coreaudio-sys v0.2.4`
    ... which is depended on by `coreaudio-rs v0.9.1`
    ... which is depended on by `cpal v0.11.0`
    ... which is depended on by `audio v0.1.0 (C:\project\foo)`

[mitchmindtree]

Hi @duhruh thanks for posting!

This is a particularly nasty issues where both coreaudio and asio require different versions of clang. See RustAudio/coreaudio-rs#68 and nannou-org/nannou#502.

The amusing thing is that it's not possible to build both of these crates on the same platform, and the feature gating ensures it, however cargo is unaware of this and so forces both crates to fall back to the last valid version that has a matching clang-sys dependency.

We can potentially work around this for now by updating asio-sys to use the same version of bindgen that coreaudio-sys does. This unfortunately won't solve the issue where an unknowing user might update either asio-sys' or coreaudio-sys' version of bindgen in the future.

Intuitively it seems to me that cargo should allow this case, but I don't recall what the reason is for why it does not. I do know that it's been a known issue with cargo for a long time.

[mitchmindtree]

Thinking on this a little more, I think the better solution might be to remove the dependency on bindgen from asio-sys altogether and include the bindings in the repo for a specific version of asio. We can leave the bindings generation code in a separate asio-generate-bindings crate, so that future users who require a newer version of asio-sys can regenerate the bindings and update asio-sys when necessary.

[9to1url]

I also encounter this issue in MacOS:

$ cargo run
error: multiple packages link to native library `clang`, but a native library can be linked only once

package `clang-sys v0.21.2`
    ... which is depended on by `bindgen v0.32.3`
    ... which is depended on by `coreaudio-sys v0.2.2`
    ... which is depended on by `coreaudio-rs v0.9.1`
    ... which is depended on by `cpal v0.12.1`
links to native library `clang`

package `clang-sys v1.0.1`
    ... which is depended on by `bindgen v0.55.1`
also links to native library `clang`

Could you advise what is the status of the fix?

[open-trade]

I also encounter this issue in MacOS:

$ cargo run
error: multiple packages link to native library `clang`, but a native library can be linked only once

package `clang-sys v0.21.2`
    ... which is depended on by `bindgen v0.32.3`
    ... which is depended on by `coreaudio-sys v0.2.2`
    ... which is depended on by `coreaudio-rs v0.9.1`
    ... which is depended on by `cpal v0.12.1`
links to native library `clang`

package `clang-sys v1.0.1`
    ... which is depended on by `bindgen v0.55.1`
also links to native library `clang`

Could you advise what is the status of the fix?

I have to downgrade my bindgen. Disgusting, coreaudio-sys is tooooooo old, the author does not maintain it.

[downfall85]

Hello,

As a workaround, you can define the clang-sys version in your Cargo.toml file.

For your specific case duhruh, if you need asio, add clang-sys = "0.24.0" and if you need coreaudio, add clang-sys = "0.28.1".

As @mitchmindtree stated, you don't need to build both of these crates as the same time.

[MarkDDR]

So clang-sys now has a 1.x.0 version of its crate, so if we can get both asio-sys and coreaudio-sys to update to the latest bindgen (or at least v0.55.0 or newer) then this should no longer be a problem (assuming clang-sys v2.x.y doesn't happen anytime soon)

Edit: As it turns out only asio-sys needs to update its bindgen

[est31]

PRs are welcome, but please ones that don't break CI.

[hyunh90]

Noob question: I still don't understand why Cargo is trying to involve coreaudio-rs as part of dependencies resolution even when building on Windows, despite the dependency is behind target_os = "macos" guard?

cpal/Cargo.toml

Lines 41 to 42 in 9597330

	[target.'cfg(target_os = "macos")'.dependencies]
	coreaudio-rs = { version = "0.10.0", default-features = false, features = ["audio_unit", "core_audio"] }

[est31]

@hyunh90 cargo tries to have one platform independent Cargo.lock so that if you put it into git, there is no back and forth when e.g. someone on windows or someone on linux makes a commit. Sadly, the check for duplicate dependencies is at that level, before the platform gets invoked. The advantage of such a check is though that you don't need to test all platforms.

[hyunh90]

@est31 Thanks for the insights. I got a glimpse of how it works now.
As a workaround for the time being, I simply removed Cargo.lock to have it regenerated with correct feature flags and now it builds well.

Thanks!