does not work with -Z build-std

[insomnimus]

Trying to build a cargo-c project with the build-std unstable cargo option results in a perplexing error:

# project: https://github.com/xiph/rav1e
# ^ commit: 953fbb2e8f3c0869caa735b2f6fb5c2d43930858

cargo cbuild --version
# cargo-c 0.10.4+cargo-0.82.0                                                                                             

cargo --version
# cargo 1.83.0-nightly (c1fa840a8 2024-08-29)                                                                             

rustup show active-toolchain
# nightly-x86_64-unknown-linux-gnu (default)

rustup component list --installed --toolchain nightly | grep rust-src
# rust-src

cargo cbuild --target x86_64-unknown-linux-gnu -Z build-std=std,core,alloc
# Error: CliError { error: Some("/home/insomnia/.rustup/toolchains/nightly-x86_64-unknown-linux-gnu/lib/rustlib/src/rust/Cargo.lock" does not exist, unable to build with the standard library, try:
#         rustup component add rust-src --toolchain nightly-x86_64-unknown-linux-gnu), exit_code: 101 }

rustup component add rust-src --toolchain nightly-x86_64-unknown-linux-gnu
# info: component 'rust-src' is up to date                                                                                

Note that I'm able to compile non-cargo-c projects with build-std using the same installation; I'm confident it's not directly cargo's fault.

Is it maybe because cargo-c's version string claims it's built for cargo 1.82.0?

[lu-zero]

cargo 0.82.0, as reported, is a stable cargo, -Z build-std is a nightly feature and not tested nor supported.

If you need this feature there is quite a bit to debug I'm afraid =/

[insomnimus]

Ah, does that mean nightly isn't supported for other use cases either?

I don't strictly need the feature, but I've noticed that the produced binaries are smaller (enough that I'd want to do it that way), and probably slightly faster as rustc gets to do LTO across std and my code.

However even though I don't need the feature, I believe it would be something embedded folks might want (building core and alloc only), for binary size reasons.
So maybe it's worth considering supporting?

[lu-zero]

nightly isn't tested, so if something breaks I wouldn't notice.

Fixing any nightly issue and making sure it keeps working would be a full time activity.

[lu-zero]

All I could think is that cargo-0.82.0 is looking for something in rust-src that isn't anymore, if you have free time you can try to figure out where in the cargo the path lookups are derived and/or see why it looks for src/rust/Cargo.lock a simple grep didn't lead to anything useful.

[insomnimus]

I see.

I have very little free time these days so I'll wait if a future update to cargo would automatically solve the problem.

[kleisauke]

This can be worked around by updating Cargo to rust-lang/cargo@50237f4, see for example:
https://github.com/libvips/build-win64-mxe/blob/b3d5c5ab739be1fdd81f3f4dfafe7d1b7a708e33/build/patches/cargo-c-0.10-fixes.patch

(I'm not sure why that commit wasn't backported to Cargo 0.82.0)