Cargo 1.52 causes a regression in dylib behaviour

[alexkornitzer]

Problem
Since Cargo 1.52, a change in behaviour of how dylibs are compiled has resulted in valid projects now failing to compile with rust 1.52. This is a little bit confusing because it compounds with an issue in the rust compiler but hopefully we can work around that.

Steps

1. Clone this repo: https://github.com/alexkornitzer/dylib-errors/tree/error/nested
2. Build with 1.51 we get the expected linker failure, we can circumvent this with hacks
3. Build with 1.52 we now get dependency satisfaction errors

error: cannot satisfy dependencies so `std` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `core` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `compiler_builtins` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `rustc_std_workspace_core` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `alloc` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `libc` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `unwind` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `cfg_if` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `hashbrown` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `rustc_std_workspace_alloc` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `rustc_demangle` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `addr2line` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `gimli` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `object` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `panic_unwind` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: cannot satisfy dependencies so `bar` only shows up once
  |
  = help: having upstream crates all available in one format will likely make this go away

error: aborting due to 16 previous errors

error: could not compile `serverctl`

To learn more, run the command again with --verbose.

Possible Solution(s)
Originally we only had to handle this bug: rust-lang/rust#82151. In this case the work around was to make sure that the dependant libraries were rlibs so that we compile down to a single dylib. Now with 1.52 we cant even get to this stage as cargo is blocking on dependency resolution.

As noted in the issue above, I assume we are getting to the stage here where we need a system in cargo that lets us specify which dependencies in the tree are what crate type. For example:

hyper = ['rlib', 'dylib']
mysharedlib = ['dylib']

where mysharedlib uses hyper, I want hyper to build as `rlib` and mysharedlib as `dylib` currently both would be compiled as dylibs resulting in satisfaction errors.

Notes

Output of cargo version:
cargo 1.52.0 (69767412a 2021-04-21)

[chachi]

This seems to make dylib usage impossible anywhere in a crate graph, yes? It's unfortunate as link times can dominate a cargo build with static linking and using a dylib used to work around that.

Is there any path forward here or indication of what in rustc actually caused this regression?

[bjorn3]

I believe the change was in cargo now passing (or not passing, can't remember) -Cprefer-dynamic in some cases where it didn't previously. Both options break certain use cases. Dylibs are currently not very well supported by rust. I would like it to be fixed, but an actual fix would require more than a couple of small tweaks.

[chachi]

Aha, yes that seems to be it! Adding in a -Cprefer-dynamic=yes brings back the old working dylib behavior.

Understood on the quasi-dylib support and I imagine it's no small feat. Thank you!

[zy010101]

About when can it be resolved?