`cargo rustc -- --emit=obj` ignores flag

[LightVillet]

Problem

I am trying to stop build on linking phase so that I can provide required libraries later. When I execute rustc --emit=obj src/main.rs it works fine, however with cargo rustc --emit=obj it fails:

error: linking with `cc` failed: exit status: 1

With output of cargo --verbose -- --emit=obj I see a command being executed with multiple emit flags:

Running `.../rustc ... --emit=dep-info,link ... --emit=obj`

Steps

1. create new project with cargo init
2. add this to src/main.rs:

unsafe extern "C" {
    safe fn add(x: i32) -> i32;
}

fn main() {
    println!("5 + 1 according to C: {}", add(5));
}

3. Try to build with cargo rustc -- --emit=obj
4. It will fail with linking
5. Try to build with the output of cargo --verbose rustc -- --emit=obj and remove cargo's emit
6. It will work fine

Possible Solution(s)

Executing the same command with only one --emit=obj works fine too, so possibly this issue is related to #14346.

Notes

Maybe there are another ways to stop build on linking phase, all I found is cargo rustc -- --emit=obj (which doesn't work) and nightly cargo rustc -Zunstable-options -- -Zno-link. If I am missing some other variants to do it on stable version, let me know please.

Version

cargo 1.88.0 (873a06493 2025-05-10)
release: 1.88.0
commit-hash: 873a0649350c486caf67be772828a4f36bb4734c
commit-date: 2025-05-10
host: x86_64-unknown-linux-gnu
libgit2: 1.9.0 (sys:0.20.0 vendored)
libcurl: 8.12.1-DEV (sys:0.4.80+curl-8.12.1 vendored ssl:OpenSSL/3.4.1)
ssl: OpenSSL 3.4.1 11 Feb 2025
os: Fedora 41.0.0 (FortyOne) [64-bit]

[weihanglo]

It is probably unrelated to #14346. Cargo has assumptions and expectations on what rustc is going to --emit. There is no Cargo native way to achieve that at this moment. You might be interested in the -Zno-link progress though:

• Support -Zno-link #9019
• Add support for splitting linker invocation to a second execution of rustc rust#64191

[weihanglo]

And regarding cargo rustc -- <trailing-args> didn't deduplicate the --emit arg, that fits in a broader rustflags management discussion. See this closed issue #2559 and the tracking issue #12739.

[weihanglo]

I am trying to stop build on linking phase so that I can provide required libraries later.

I am more curious about the reason behind this. Mind sharing a bit more why you were doing this?

[LightVillet]

I am trying to stop build on linking phase so that I can provide required libraries later.

I am more curious about the reason behind this. Mind sharing a bit more why you were doing this?

I am doing a parallel build of my C++ and Rust parts of the project. Both of them take about 5 minutes to build from scratch. Now I need to call couple functions from C++ in Rust. So I was trying to build an entire Rust project in parallel with C++, copy provided library from C++ build and link only after that, which will keep those builds in parallel and reduce overall time.

One other approach besides stop on linking I could come up with is to hide calls of those functions under feature, have some placeholder functions without this feature, and compile Rust's part without a feature first, then copy library from C++ and compile again with the feature, but was curious, can I do this just as I would do with some C/C++ code (gcc -c) but without doing manual rustc invocations.

If you have any other ideas how could I achieve that besides stop on linking phase, I am glad to hear them.

[joshtriplett]

We talked about this in today's @rust-lang/cargo meeting.

We don't want to get into parsing rustc options, but we'd be willing to consider adding an --emit option to cargo rustc (before the --). Such an option would then override what cargo rustc would normally pass to rustc. (cargo rustc could still add dep-info, for instance, but not add link.)

If someone wants to write and propose a design for this, either here or as an RFC, we'd be happy to look at it.