--crate-type cdylib causes errors looking for rlib dependencies

[seanmonstar]

Problem

When running cargo rustc --crate-type cdylib -Z unstable-options, I see errors that dependencies were expected to be available in rlib format. If I put the crate-type in the Cargo.toml, I don't see these errors.

Output:

 ~/code/test.rs $ cargo rustc --crate-type cdylib -Z unstable-options
   Compiling scratchpad v0.0.0 (/home/sean/code/test.rs)
error: crate `http` required to be available in rlib format, but was not found in this form

Steps

Here's a minimal repro:

1. Make a new crate, using any simple dependency. http = "*" works.
2. In lib.rs, add pub extern "C" fn yeet() { println!("{:?}", http::StatusCode::OK) }.
3. Run cargo rustc --crate-type cdylib -Z unstable-options.

I originally discovered this by trying to convert hyper to use it:

1. Removing the [lib] and crate-type = ["cdylib", "staticlib", "lib"] lines.
2. Run cargo rustc --crate-type cdylib -Z unstable-options.

Possible Solution(s)

No response

Notes

• If I keep the line in Cargo.toml, then hyper builds properly.
• When making a minimal repro, I noticed that it works without a dependency, and it also works with a dependency that isn't used. You must use the dependency in the file.

Version

cargo 1.60.0-nightly (25fcb13 2022-02-01)
release: 1.60.0-nightly
commit-hash: 25fcb135d02ea897ce894b67ae021f48107d522b
commit-date: 2022-02-01
host: x86_64-unknown-linux-gnu
libgit2: 1.3.0 (sys:0.13.23 vendored)
libcurl: 7.80.0-DEV (sys:0.4.51+curl-7.80.0 vendored ssl:OpenSSL/1.1.1l)
os: Ubuntu 16.04 (xenial) [64-bit]

[seanmonstar]

Relevant tracking issue: #10083

[weihanglo]

The root cause is that #10093 handles rustc's --crate-type arg well but doesn't take care of others, such as --extern. The unit thought it only requires rmeta but actually it needs rlib to build artifacts other than rlib. Below are the differece between two rustc invocations. (left: toml, right: cmd arg)

Here is a simple patch for cargo::core::compiler::context::Context::only_requires_rmeta to let the build pass.

         // object code must be useful in some fashion
         && !dep.requires_upstream_objects()
         && dep.mode == CompileMode::Build
+        && !self.bcx.rustc_crate_types_args_for(parent)
+            .map_or(false, |v| v.iter()
+                .map(|s| s.into())
+                .any(|ty: super::CrateType| ty.requires_upstream_objects()))
+}

However, there are lots of places calling Unit::requires_upstream_objects, which are not Context-aware and I cannot think of an easy way to fix without duplicate our --crate-type overridden logic.

An intuitive solution is setting crate types into unit.target.kind directly, so that no extra workaround is needed. Unfortunately Unit doesn't implement DerefMut but only Deref. This mutating approach won't work unless we open a mutable backdoor on Unit.

@ehuss Any insight into this?

[elichai]

EDIT: I misused cargo rustc,
Some results on google show using the crate-type feature via cargo rustc -- --crate-type=TYPE but that can lead to the same error as here, instead it should be called(as stated in the docs) via: cargo rustc --crate-type=TYPE which fixes the "problem" (maybe a better diagnostic can help here)

(P.S. if you want an example you can see the past edit of this comment)

[weihanglo]

I feel like you didn't use --crate-type flag correctly. Flags after -- go directly to rustc invocation, whereas the RFC stabilized --crate-type for cargo-rustc affects how Cargo determine the crate type of the final artifact.

Could you try cargo rustc --target x86_64-linux-android --crate-type=cdylib?

[weihanglo]

Oh I see. Glad you figured it out :)