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

Using crates.io libc triggers unstable libc warning #21771

Closed
SSheldon opened this issue Jan 30, 2015 · 9 comments · Fixed by #21782
Closed

Using crates.io libc triggers unstable libc warning #21771

SSheldon opened this issue Jan 30, 2015 · 9 comments · Fixed by #21782

Comments

@SSheldon
Copy link
Contributor

With the crates.io distribution of libc (#20606) in my Cargo.toml:

[dependencies]
libc = "0.1"

I still get a warning on extern crate libc:

lib.rs:6:1: 6:19 warning: use of unstable library feature 'libc'
lib.rs:6 extern crate libc;
         ^~~~~~~~~~~~~~~~~~
lib.rs:6:1: 6:19 help: add #![feature(libc)] to the crate attributes to silence this warning
lib.rs:6 extern crate libc;
         ^~~~~~~~~~~~~~~~~~

Am I linking to the wrong crate? How do you choose the version from cargo over the version included in rustc?

@nagisa
Copy link
Member

nagisa commented Jan 30, 2015

A rule of thumb is to always use the version shipped with the compiler unless you know you need the version from crates.io (e.g. crossbuilding).

The warning is expected since libc in crate is the same thing that is shipped with the rust compiler.

@SSheldon
Copy link
Contributor Author

@nagisa, #19260 says of libc:

These crates will all be distributed, but participate in #![staged_api]. This means they will not be accessible in the stable channel's standard distribution, but they will all be available through crates.io.

So that suggests to me that the version shipped with the compiler shouldn't be used.

@SSheldon
Copy link
Contributor Author

cc @alexcrichton, who has worked on the libc for crates.io

@alexcrichton
Copy link
Member

Working on a fix, thanks for the report! I've also seen this recently and I've been baffled.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Jan 30, 2015
Previously if --extern was specified it would not override crates in the
standard distribution, leading to issues like rust-lang#21771. This commit alters the
behavior such that if --extern is passed then it will always override any other
choice of crates and no previous match will be used (unless it is the same path
as --extern).

Closes rust-lang#21771
@tbu-
Copy link
Contributor

tbu- commented Jan 31, 2015

@nagisa You shouldn't work with the explicitely-deprecated compiler-shipped libraries.

alexcrichton added a commit to alexcrichton/rust that referenced this issue Feb 2, 2015
Previously if --extern was specified it would not override crates in the
standard distribution, leading to issues like rust-lang#21771. This commit alters the
behavior such that if --extern is passed then it will always override any other
choice of crates and no previous match will be used (unless it is the same path
as --extern).

Closes rust-lang#21771
@stevedonovan
Copy link

I note that this is still the case for 1.12 stable, which seems alarming...

@steveklabnik
Copy link
Member

@stevedonovan can you share your exact code? I can't reproduce.

@stevedonovan
Copy link

Sorry, I forgot to actually add libc to my crate that imported a crate needing libc, hence the issue! That makes sense, so I'm happy.

@steveklabnik
Copy link
Member

Ah, great!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

7 participants