error: cannot satisfy dependencies

[tmerr]

I'm running into an error when using plugin libraries that share a common dependency. Here's a repository showcasing the problem.

https://github.com/tmerr/crateissue

[tmerr@tmerrArch crateissue]$ rustc --version
rustc 1.0.0-nightly (ea6f65c5f 2015-01-06 19:47:08 +0000)
[tmerr@tmerrArch crateissue]$ cargo --version
cargo 0.0.1-pre-nightly (23ed197 2015-01-06 02:37:42 +0000)
[tmerr@tmerrArch crateissue]$ cd a
[tmerr@tmerrArch a]$ cargo build --verbose
       Fresh d v0.0.1 (file:///home/tmerr/code/rust/crateissue/a)
       Fresh c v0.0.1 (file:///home/tmerr/code/rust/crateissue/a)
       Fresh b v0.0.1 (file:///home/tmerr/code/rust/crateissue/a)
   Compiling a v0.0.1 (file:///home/tmerr/code/rust/crateissue/a)
     Running `rustc /home/tmerr/code/rust/crateissue/a/src/main.rs --crate-name a --crate-type bin -g --out-dir /home/tmerr/code/rust/crateissue/a/target --emit=dep-info,link -L dependency=/home/tmerr/code/rust/crateissue/a/target -L dependency=/home/tmerr/code/rust/crateissue/a/target/deps --extern c=/home/tmerr/code/rust/crateissue/a/target/deps/libc-f342e094024f04d2.so --extern b=/home/tmerr/code/rust/crateissue/a/target/deps/libb-31d1c0a7adfdac94.so`
error: cannot satisfy dependencies so `d` only shows up once
note: having upstream crates all available in one format will likely make this go away
error: aborting due to previous error
Could not compile `a`.

Caused by:
  Process didn't exit successfully: `rustc /home/tmerr/code/rust/crateissue/a/src/main.rs --crate-name a --crate-type bin -g --out-dir /home/tmerr/code/rust/crateissue/a/target --emit=dep-info,link -L dependency=/home/tmerr/code/rust/crateissue/a/target -L dependency=/home/tmerr/code/rust/crateissue/a/target/deps --extern c=/home/tmerr/code/rust/crateissue/a/target/deps/libc-f342e094024f04d2.so --extern b=/home/tmerr/code/rust/crateissue/a/target/deps/libb-31d1c0a7adfdac94.so` (status=101)
[tmerr@tmerrArch a]$ 

I guess this is a new issue since @huonw managed to get this to compile on an earlier nightly. The only difference is that he needed to use #[phase] extern crate instead of the newer #[plugin] extern crate.

A workaround is to use #[no_link] #[plugin] extern crate but is this behavior expected?

[huonw]

I'm fairly sure this is expected behaviour, since #[no_link] #[plugin] is the direct equivalent to the old #[phase(plugin)]. (#[no_link] specifies that the crate should not be linked against for runtime, only loaded at compile time.)

[tmerr]

related: #20769
I'll close this since it's not a bug as I expected, just a design choice that may be changed after 1.0. Cheers