Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cargo optional feature (those with ?) is not working as expected #14494

Closed
sunng87 opened this issue Sep 4, 2024 · 2 comments
Closed

Cargo optional feature (those with ?) is not working as expected #14494

sunng87 opened this issue Sep 4, 2024 · 2 comments
Labels
A-dependency-resolution Area: dependency resolution and the resolver A-features Area: features — conditional compilation C-bug Category: bug S-triage Status: This issue is waiting on initial triage.

Comments

@sunng87
Copy link
Contributor

sunng87 commented Sep 4, 2024

Problem

I'm using sqlx library which has a big usage of optional feature dependencies (I'm not sure if the name is correct, it's in a form like sqlx-sqlite?/chrono).

It works perfectly with exlucding optional features. However, when building the dependency graph, I found it's still including those optional one, which can cause conflict for libraries you don't really use.

Steps

Create a project with these dependencies and run cargo tree

[package]
name = "sqlx-test"
version = "0.1.0"
edition = "2021"

[dependencies]
tokio = { version = "1", features = ["full"] }
sqlx = { version = "0.8", features = [
    "runtime-tokio-rustls",
    "postgres",
    "chrono"
], default-features = false }

cargo tree result looks great and no sqlite dependencies are included. However, if I have a sqlite dependency in the project, it cause conflicts

[package]
name = "sqlx-test"
version = "0.1.0"
edition = "2021"

[dependencies]
tokio = { version = "1", features = ["full"] }
sqlx = { version = "0.8", features = [
    "runtime-tokio-rustls",
    "postgres",
    "chrono"
], default-features = false }
## add a sqlite dependency that is incompatible with the one from sqlx
libsqlite3-sys = "=0.25.2"

Now cargo refuses to build the dependency graph

error: failed to select a version for `libsqlite3-sys`.
    ... required by package `sqlx-sqlite v0.8.0`
    ... which satisfies dependency `sqlx-sqlite = "=0.8.0"` of package `sqlx v0.8.0`
    ... which satisfies dependency `sqlx = "^0.8"` of package `sqlx-test v0.1.0 (/home/sunng/tmp/sqlx-test)`
versions that meet the requirements `^0.28.0` are: 0.28.0

the package `libsqlite3-sys` links to the native library `sqlite3`, but it conflicts with a previous package which links to `sqlite3` as well:
package `libsqlite3-sys v0.25.2`
    ... which satisfies dependency `libsqlite3-sys = "=0.25.2"` of package `sqlx-test v0.1.0 (/home/sunng/tmp/sqlx-test)`
Only one package in the dependency graph may specify the same links value. This helps ensure that only one copy of a native library is linked in the final binary. Try to adjust your dependencies so that only one package uses the `links = "sqlite3"` value. For more information, see https://doc.rust-lang.org/cargo/reference/resolver.html#links.

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

However, we don't really included sqlx-sqlite in our project. So I consider this a bug for optional feature implementation.

Possible Solution(s)

No response

Notes

No response

Version

cargo 1.80.1 (376290515 2024-07-16)
release: 1.80.1
commit-hash: 37629051518c3df9ac2c1744589362a02ecafa99
commit-date: 2024-07-16
host: x86_64-unknown-linux-gnu
libgit2: 1.7.2 (sys:0.18.3 vendored)
libcurl: 8.6.0-DEV (sys:0.4.72+curl-8.6.0 vendored ssl:OpenSSL/1.1.1w)
ssl: OpenSSL 1.1.1w  11 Sep 2023
os: Arch Linux Rolling Release [64-bit]
@sunng87 sunng87 added C-bug Category: bug S-triage Status: This issue is waiting on initial triage. labels Sep 4, 2024
@epage epage added A-features Area: features — conditional compilation A-dependency-resolution Area: dependency resolution and the resolver labels Sep 4, 2024
@epage
Copy link
Contributor

epage commented Sep 4, 2024

I believe this is a duplicate of #10801

@sunng87
Copy link
Contributor Author

sunng87 commented Sep 4, 2024

I think so. Feel free to close this one and I will be following that #10801. But it's unfortunate to see the issue has been there for two years.

@epage epage closed this as not planned Won't fix, can't repro, duplicate, stale Sep 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-dependency-resolution Area: dependency resolution and the resolver A-features Area: features — conditional compilation C-bug Category: bug S-triage Status: This issue is waiting on initial triage.
Projects
None yet
Development

No branches or pull requests

2 participants