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 build --release ignores dependencies in favor of dev-dependencies for shared sub-dependency #6549

Closed
ghost opened this issue Jan 14, 2019 · 2 comments
Labels
C-bug Category: bug

Comments

@ghost
Copy link

ghost commented Jan 14, 2019

cargo new package --lib

lib.rs

#![no_std]

Cargo.toml

[package]
name = "package"
version = "0.1.0"
edition = "2018"

[dependencies]
memchr = { version = "2", default-features = false }

[dev-dependencies]
term-table = "1.1"

cargo tree

package v0.1.0                                
└── memchr v2.1.2
    ├── cfg-if v0.1.6
    └── libc v0.2.46
    [build-dependencies]
    └── version_check v0.1.5
[dev-dependencies]
└── term-table v1.1.0
    ├── lazy_static v1.2.0
    ├── regex v1.1.0
    │   ├── aho-corasick v0.6.9
    │   │   └── memchr v2.1.2 (*)
    │   ├── memchr v2.1.2 (*)
    │   ├── regex-syntax v0.6.4
    │   │   └── ucd-util v0.1.3
    │   ├── thread_local v0.3.6
    │   │   └── lazy_static v1.2.0 (*)
    │   └── utf8-ranges v1.0.2
    └── wcwidth v1.0.1

cargo build --release

   Compiling version_check v0.1.5                                               
   Compiling libc v0.2.46                                                       
   Compiling cfg-if v0.1.6                                                      
   Compiling memchr v2.1.2                                                      
   Compiling package v0.1.0
    Finished release [optimized] target(s) in 3.76s

cargo build --release --target thumbv7em-none-eabihf

   Compiling libc v0.2.46
   Compiling version_check v0.1.5
   Compiling cfg-if v0.1.6
error[E0463]: can't find crate for `std`
  |
  = note: the `thumbv7em-none-eabihf` target may not be installed

error: aborting due to previous error

For more information about this error, try `rustc --explain E0463`.
error: Could not compile `libc`.
warning: build failed, waiting for other jobs to finish...
error: build failed

rustup show

installed targets for active toolchain
--------------------------------------

thumbv7em-none-eabihf
x86_64-apple-darwin

cargo version

cargo 1.33.0-nightly (34320d212 2019-01-03)

Workaround

Cargo.toml

[package]
name = "package"
version = "0.1.0"
edition = "2018"

[dependencies]
memchr = { git = "https://github.com/BurntSushi/rust-memchr", tag = "2.1.2", default-features = false }

[dev-dependencies]
term-table = "1.1"

cargo build --release

    Updating git repository `https://github.com/BurntSushi/rust-memchr`
   Compiling version_check v0.1.5
   Compiling cfg-if v0.1.6
   Compiling memchr v2.1.2 (https://github.com/BurntSushi/rust-memchr?tag=2.1.2#437a177a)
   Compiling package v0.1.0
    Finished release [optimized] target(s) in 3.74s

cargo build --release --target thumbv7em-none-eabihf

   Compiling version_check v0.1.5
   Compiling cfg-if v0.1.6
   Compiling memchr v2.1.2 (https://github.com/BurntSushi/rust-memchr?tag=2.1.2#437a177a)
   Compiling package v0.1.0
    Finished release [optimized] target(s) in 2.52s

cargo tree

package v0.1.0
└── memchr v2.1.2 (https://github.com/BurntSushi/rust-memchr?tag=2.1.2#437a177a)
    └── cfg-if v0.1.6
    [build-dependencies]
    └── version_check v0.1.5
[dev-dependencies]
└── term-table v1.1.0
    ├── lazy_static v1.2.0
    ├── regex v1.1.0
    │   ├── aho-corasick v0.6.9
    │   │   └── memchr v2.1.2
    │   │       ├── cfg-if v0.1.6 (*)
    │   │       └── libc v0.2.46
    │   │       [build-dependencies]
    │   │       └── version_check v0.1.5 (*)
    │   ├── memchr v2.1.2 (*)
    │   ├── regex-syntax v0.6.4
    │   │   └── ucd-util v0.1.3
    │   ├── thread_local v0.3.6
    │   │   └── lazy_static v1.2.0 (*)
    │   └── utf8-ranges v1.0.2
    └── wcwidth v1.0.1
@ghost ghost added the C-bug Category: bug label Jan 14, 2019
@ehuss
Copy link
Contributor

ehuss commented Jan 14, 2019

Thanks for the report. This is a pretty well known issue where features bleed between dependency types. #1796 is probably most similar to your situation, so closing in favor of that. It's definitely an issue on my radar, though.

@ehuss ehuss closed this as completed Jan 14, 2019
@ghost
Copy link
Author

ghost commented Jan 14, 2019

I see! Thanks! (#5730)

tarcieri added a commit to tarcieri/curve25519-dalek that referenced this issue May 21, 2019
It looks like you're encountering this bug:

rust-lang/cargo#6549

There are many dev-dependencies in Cargo.lock which activate the `std`
features of both `byteorder` and `rand_core`.

To address `byteorder` I've switched to `to_le_bytes`/`from_le_bytes`
which are available on integer primitives since 1.32. To support earlier
versions of Rust while using core in 1.32+, we can add an extension
trait and impl it on the relevant primitive types. This commit, however,
at least demonstrates that things will link with `byteorder` removed.

For `rand_core` I just ended up gating it on `std`. It's similarly
impacted by the cargo feature activation bug.

Finally, I added a step to the Travis build matrix which cross-compiles
to a `no_std`-only target (`thumbv7`), which should ensure future
`no_std` regressions are spotted in CI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
C-bug Category: bug
Projects
None yet
Development

No branches or pull requests

1 participant