can't specify lto in profile

[sehz]

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)

[ehuss]

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?

[M1cha]

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.

[petrochenkov]

@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).

[petrochenkov]

10 more people encountered the same issue here - #8264 (comment).

(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.)

[petrochenkov]

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?

[eldenpark]

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...

[ctrlcctrlv]

Same issue here.

[CPerezz]

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.

[BartMassey]

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?

[vogtb]

I'm experiencing this same issue. Would love a way around this.

[LeoBorai]

Any news on this?

[epage]

Since its not mentioned, the workaround for this is to define different profiles and build the different binaries with the relevant profiles.

[BartMassey]

@petrochenkov commented that it's not clear that using different profiles is sufficient? I don't think I understand this workaround very well.

[epage]

Missed that in the among the different commes but not seeing what the downside to it is.

[BartMassey]

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?

[JohnScience]

Similar issue.

`panic` may not be specified in a `package` profile

[ExaltedVanguard]

The need to use multiple profiles definitely isn't ideal, since you can't just cargo build --workspace --release and have everything build correctly. I would also like to see overrides work for panic, lto, and rpath.

For those coming from google looking for a resolution, there are 2 workarounds. The first is to define a second profile with the relevant settings:

[profile.release-lto]
inherits = "release"
lto = true

and compile using cargo build --profile release-lto

The second is to add a /.cargo/config.toml to the crate and compile it from outside the workspace root. This works great for wasm.

workspace/
  - crates/
    - crate1/
      - .cargo/
        - config.toml
    - crate2/
    - crate3/
  - cargo.toml

where the contents of config.toml are the same as a standard cargo.toml and will override the workspace cargo.toml.

Note that this will NOT work if you call cargo build from workspace root (workspace>cargo build) but will work as expected (using local settings to override workspace settings) if you call it from the subdirectory (workspace/crates/crate1>cargo build).

This works great for the very common use-case of wasm-pack (which seems to be the use-case for several people in a related thread).
workspace>wasm-pack build crates/crate1 will work just fine, and you can get great size optimizations without affecting other projects in your workspace.

[sehz]

Profile in workspace works fine now and solves original problem I had. I consider this as resolved.

[tgross35]

I think this may be worth leaving open to track a way to do this using the release profile, without workarounds.