Ability to set crate-type depending on target

[fschutt]

This is an issue that currently blocks me from porting a library to WASM:

I have a library called proj5, which I use in a backend server (in a regular Rust program). I wanted to port the library to wasm (the wasm32-unknown-unknown target) that is now available on nightly and found it to be impossible to do it while still being able to use it in the backend:

The only way to get a WASM binary is by setting the crate-type to "cdylib" in the Cargo.toml file. However, if I do this, I can't use the crate in my regular rust program anymore! And if I leave it out, there is not WASM output.

So currently a crate can be compiled either for WASM or for use in a regular Rust program, not both (controlled by the target). I tried the following so far:

1. Setting the crate-type in Cargo.toml

[target.'cfg(target_arch = "wasm32")']
crate-type = ["dylib"]

This doesn't work, the argument goes unused:

warning: unused manifest key: target.cfg(target_arch = "wasm32").crate-type

I also tried:

[target.wasm32-unknown-unknown]
crate-type = ["dylib"]

Same thing, same error message. The crate builds, but doesn't produce a WASM binary.

2. Setting RUSTFLAGS (in the .cargo/config) does not seem to have any effect. I tried:

[target.wasm32-unknown-unknown]
rustflags = [ "--crate-type=cdylib" ]

This just gives a cryptic error, and sets the crate-type twice:

error: unexpected character in cfg `/`, expected parens, a comma, an identifier, or a string

No line number, no column number, nothing. Not sure where it failed - the error message could be heavily improved upon.

I also tried it with crate_type, -- --crate-type, --crate-type dylib. None of which work. I expected --crate-type=dylib to work, because it is documented this way, however I suspect that the documentation is incorrect or out of date.

3. Setting the crate type in lib.rs

So the last thing I tried was to override the crate type via cfg_attr:

// lib.rs
#![cfg_attr(target_arch = "wasm32", crate_type = "cdylib")]

This is simply ignored by cargo. I still get a .rlib file, not a .wasm file.

So right now I'm out of options. Why is is so hard to build a library for both regular Rust use and WASM? Right now I can only choose either-or.

There is a workaround in that I make a second crate (as cdylib), which just exposes the first one (the rlib), but I don't think this is the way to go. This is important for feature-gating crates so that they can be compiled to WASM without any workarounds.

[y-ich]

How about adding an example for wasm in Cargo.toml?

...
[[example]]
name = "wasm"
path = "src/lib.rs"
crate-type = ["cdylib"]

And build by

cargo +nightly build --example wasm --target wasm32-unknown-unknown --release

[flukejones]

@fschutt I currently have the same issue, my workaround is basically this for WASM and rlib releases:

Cargo.toml

[lib]
crate-type = ["rlib"]

[[bin]]
name = "test_wasm"
path = "src/lib.rs"

src/lib.rs

#[cfg(target_arch = "wasm32")]
fn main() {}

So

cargo build --lib

will build the rlib, and

cargo build --bin test_wasm

builds the WASM.

Seems to work well for all lib types.

[alvitawa]

Noob here, but I came here with the same (I think) problem. and solved it by trying

[lib]
crate-type = ["cdylib", "lib"]

Both cargo +nightly build --target wasm32-unknown-unknown and cargo run from a crate including the wasm-compilable crate work, and I am able to use the functionality from wasm_or_lib as wasm and as a rust lib.

"rlib" instead of "lib" works too

[prographo]

Is it possible to specify create type by target in the .cargo/config file?

Android targets need cdylib
iOS need staticlib

I've tried but it does not seem to accept.

[alexcrichton]

@prographo no, unfortunately that's not supported by Cargo right now

[J-F-Liu]

@alvitawa Specified crate-type = ["cdylib", "lib"], but the generated wasm file size goes from 166KB to 2MB in my case.

[dvc94ch]

Is it possible to specify create type by target in the .cargo/config file?

setting it from the env like CARGO_TARGET_{triple}_CRATE_TYPE would also be nice for tooling.

Android targets need cdylib
iOS need staticlib

any updates?

[getreu]

Why is is so hard to build a library for both regular Rust use and WASM? Right now I can only choose either-or.

Is there any progress on this?

Proposal: in analogy to:

[target.'cfg(target_arch = "wasm32")'.dependencies]
rand = { version = "0.7.3", features = ["getrandom"] }

This should be allowed:

[target.'cfg(target_arch = "wasm32")'.lib]     
crate-type = ["cdylib", "rlib"]

Unfortunately, at the moment I still get:

$ wasm-pack build  --target web --out-name wasm
Error: crate-type must be cdylib to compile to wasm32-unknown-unknown. Add the following to your Cargo.toml file:

[lib]
crate-type = ["cdylib", "rlib"]

[alex]

This also impacts folks trying to builds Python extension modules for iOS.

Is there consensus that the fix is to support specifying arbitrary keys on a per target basis, or is that merely a proposal and more design is required?

[dvc94ch]

Last I heard the cargo team is not willing to take a PR to fix this currently and an RFC would need to happen. I think the more deeper problem that makes this hard to fix is that cargo parses the toml and then freezes it by passing around a reference. So there isn't an easy way to adjust the crate-type key in the toml based on information gained later in the compilation.

#7900

[str4d]

A related request I have (which likely would use the same mechanics as a fix for this issue, so I'm mentioning it here, but can open a separate issue if desired) is enabling crate-type to be controlled by feature flags. hyper 0.14.3 added a C FFI behind an ffi feature flag, but to do so they added crate-type = ["lib", "staticlib", "cdylib"] to their Cargo.toml. This breaks cross-compilation for downstream staticlib Rust users such as myself, because even though the ffi feature flag is disabled, the (completely unused) cdylib is still compiled for hyper, and rustc needs to know how to link for the target architecture (which is completely unnecessary for the staticlib I want to compile for use in my C++ binary, so wasn't plumbed in). If hyper could have placed the staticlib, cdylib behind the ffi feature flag, there would have been no downstream effects.

[VladasZ]

This really needs to be implemented. Without crate-type depending on target building cross platform crates supporting mobile platforms such as iOS and Android requires a lot fuss and workarounds.

[flukejones]

Related issue: #6179

[daxpedda]

Related: rust-lang/rfcs#3180, and the follow-up: #10083.
Cargo teams opinion on (parts of) this at the moment: rust-lang/rfcs#3180 (comment).

[epage]

While #12260 is a duplicate of this, it has more input from the cargo team, so I'm going to close in favor of that. If there is a reason to keep this open separately that I overlooked, let us know!