rust-lang
can't specify lto in profile
Problem
Cargo doesn't accept lto in profile as below:
[profile.release.package.fluvio-filter-test]
lto = true
Steps This result in following error message:
$ cargo check
error: failed to parse manifest at `/home/ubuntu/fluvio/Cargo.toml`
Caused by:
`lto` may not be specified in a `package` profile
$ cargo version
cargo 1.51.0 (43b129a20 2021-03-16)
Thanks for the report! Can you say more about your use case? LTO only works for the final artifact, so it can't be set per-dependency. Is this maybe an executable in a workspace?
library crates (like clap-rs) can enable LTO. If the toolchain does not support LTO the build is gonna fail even though the binary crate you're trying to build doesn't have that enabled.
@ehuss
Is this maybe an executable in a workspace?
Yes, multiple executables, they can easily need different build settings. In general, crates in the build tree aren't necessarily built together into the same binary.
I encountered the same issue, but with panic instead of lto
`panic` may not be specified in a `package` profile
The worst thing is that there's no reasonable workaround for this (or at least I haven't found one).
10 more people encountered the same issue here - https://github.com/rust-lang/cargo/issues/8264#issuecomment-751931213.
(I consider all of the "may not be specified in a {} profile" errors to be the same issue because in all these cases cargo wrongly assumes that all of the workspace members are always going to be combined into the same binary, which is pretty far from the truth.)
there's no reasonable workaround for this
Looks like it's possible to make a separate profile that inherits from the main one, but overrides panic or lto. Then the specific package will always be built with that profile.
workspace members are always going to be combined into the same binary
Ugh, looks like different executables may share built dependencies, which is obviously good, but will prevent overriding things like panic.
I guess it's hard for cargo to setup some mini-equivalent of profiles to build dependencies with different panic values separately while keeping everything in a single workspace?
Is this being taken care of?
I'm having the same issue. Of many packages and crates in the workspace, I was hoping some specific crates to be compiled with different settings. Specifying profile in the non-root package caused warnings hence I put those in the workspace which throws out errors.
workspace
- pkg1
- lib crate
- lib crate
- bin crate
- pkg2
- lib crate (needs the compilation-specific settings)
- other pkgs...
Well, in the Cargo documentation it's already mentioned that panic, lto and rpath are not supported.
See: https://doc.rust-lang.org/cargo/reference/profiles.html#overrides at last line of the section.
What I ignore is if it could be supported or not.
This is honestly pretty painful. I am giving up on the workspace for my toy example due to this, but it will arise in larger contexts. Anything that could be done to kludge around it?
Since its not mentioned, the workaround for this is to define different profiles and build the different binaries with the relevant profiles.
@petrochenkov commented that it's not clear that using different profiles is sufficient? I don't think I understand this workaround very well.
Missed that in the among the different commes but not seeing what the downside to it is.
For LTO I don't know that it matters much if some deps are built with and some without: should be just a small performance surprise. For panic=abort it does seem to me that one normally wants it everywhere if they want it anywhere? Or am I misunderstanding how all this works?
