Move dynamic_lib out of std.

[treeman]

A first step in fixing #8157.

We might want to move dynamic_lib to a crate in rust-lang org, this is a first step towards that. Does it make sense to do it this way?

[treeman]

Rebased and merged.

[brson]

I'm a fan. @alexcrichton @aturon?

[brson]

It should probably leave the old module in place, #[deprecated].

[aturon]

Seems like a step in the right direction to me.

[alexcrichton]

Ah yes indeed! I think that some of this may end up eventually in libnative (at least the raw low-level native bindings), but as its own crate this certainly has room to grow to do things like inspect metadata for type safety, etc.

@brson, Sadly I don't think we can use #[deprecated] here because the standard library can't depend on this crate (to provide the redirect).

@treeman, could you expand the commit message a little bit more to explain what code is going to break and how it can be updated. You may also want to move some rationale from the issue to the commit message as well.

[treeman]

Updated commit message.

[alexcrichton]

Thanks!

[treeman]

Interesting. The build system found a cyclic crate dependency between std and dynamic_lib. In libstd/rt/backtrace.rs there is a single usage of DynamicLibrary see: https://github.com/treeman/rust/blob/dynamic_lib/src/libstd/rt/backtrace.rs#L959.. This is under a #[cfg(windows)] which explains why I didn't find it before.

I couldn't get the build system to work around it, if it's even possible.

dynamic_lib has quite a few std dependencies, such as os and path so it needs to depend on std. It might be possible to decouple dynamic_lib from std, but I'm not sure how we should do that.

Any ideas on how to proceed?

[alexcrichton]

Aha, I thought I remembered some use case in libstd.

This is where the bindings for that module don't need the full functionality of dynamic_lib, just basically the raw access to the system. If we were to split the core functionality into libnative and dynamic lib, and then move libnative underneath the facade (as we may do), then it would solve the problem. That change is aways out, however.

[treeman]

Closed this PR as we may want to do what @alexcrichton said in the future.