lto cannot be used for `proc-macro` crate type without `-Zdylib-lto`

[marvin-hansen]

The last release, 0.56, introduced a new setting for LTO (PR #3104).

However, this conflicts with the official Bzlmod LTO example and throws an error
that embed-bitcode does contain symbols for LTO. That is consistently the case on my CI.

Okay, when I enable the new LTO setting in my .bazelrc via

build --@rules_rust//rust/settings:lto=thin

bazel build throws then an error, both locally on MacOS and on CI / Linux:

error: lto cannot be used for proc-macrocrate type without-Zdylib-lto``

Indeed, I have a bunch of proc macros in my repo.

Currently, the previous LTO config throws an error and the new LTO setting also throws an error.

How do you advice to setup LTO?
Where do I set the Zdylib-lto flag?

[havasd]

I have fix for it in #3147

[marvin-hansen]

Thank you, appreciate your effort to get this solved.

[marvin-hansen]

@havasd Okay, now as the fix is merged, how am I supposed to use this one?

[havasd]

you can use, git_override to pick up the latest version if you use MODULE.bazel. Ideally it should work out of the box. If you use workspace you need to pick download the main branch in http_archive with https://github.com/bazelbuild/rules_rust/archive/refs/heads/main.zip.

bazel_dep(name = "rules_rust", version = "0.56.0")
git_override(
  module_name = "rules_rust",
  commit = "568bb7b70f32d52e6626c313fc1d3dc18a0757af",
  remote = "https://github.com/bazelbuild/rules_rust.git",
)

[marvin-hansen]

Okay, my question was about using the new LTO configuration format introduced by the last PR. Previously, I could define LTO in BUILD.bazek like so: rust_binary( name = name, srcs = srcs, crate_root = "src/main.rs", rustc_flags = select({ "//:release": [ "-Clto=true", "-Ccodegen-units=1", "-Cpanic=abort", "-Copt-level=3", "-Cstrip=symbols", # "-Ctarget-cpu=native", # Only use this when the build CPU is the same as the target CPU ], "//conditions:default": [ "-Copt-level=0", ], However, that broke with the last release in favor of some wonky flag that doesn't work on my CI, with the last PR presumably having fixed that. Now, with the PR that just got merged, how do I configure the LTO now?

…

On Fri, Jan 3, 2025 at 5:10 PM David Havas ***@***.***> wrote: you can use, git_override to pick up the latest version if you use MODULE.bazel. Ideally it should work out of the box. If you use workspace you need to pick download the main branch in http_archive with https://github.com/bazelbuild/rules_rust/archive/refs/heads/main.zip. bazel_dep(name = "rules_rust", version = "0.56.0") git_override( module_name = "rules_rust", commit = "568bb7b70f32d52e6626c313fc1d3dc18a0757af", remote = "https://github.com/bazelbuild/rules_rust.git", ) — Reply to this email directly, view it on GitHub <#3143 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AFYR7XGNIWBTSV45BPCGAD32IZHYFAVCNFSM6AAAAABUL66V6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKNRYHEYDCMRXGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[havasd]

I see, I misunderstood your question.

With the original implementation you can do this --@rules_rust//rust/settings/lto=thin
this can be put to .bazelrc or passed to CLI. Also if you specify --@rules_rust//rust/settings/lto=manual your original settings should work without any change.

With my latest changes ideally you could make it work by creating your own toolchain and there specifying the lto flag.

load("//rust/private:lto.bzl", "rust_lto_flag")

rust_lto_flag(
    name = "lto_thin",
    build_setting_default = "thin",
    visibility = ["//visibility:public"],
)

rust_lto_flag(
    name = "lto_off",
    build_setting_default = "unspecified",
    visibility = ["//visibility:public"],
)

load("@rules_rust//rust:toolchain.bzl", "rust_toolchain")

rust_toolchain(
  ....
  lto = select({
          "//:release": ":lto_thin",
          "//conditions:default": ":lto_off",
  }),
  ...
)

Now how you prepare a custom toolchain that is a different story.

[marvin-hansen]

Hey, would it possible to update the official comp_opt example with the new toolchain approach?

https://github.com/bazelbuild/rules_rust/tree/main/examples/compile_opt

I am asking b/c right now, the official LTO/compiler optimization example is pinned to v0.46 of rules_rust and I am pretty certain once the new release comes out with LTO config changed again, people will ask how to set this up just to figure out that the official code example is basically pinned to an old version of the rules.

https://github.com/bazelbuild/rules_rust/blob/main/examples/compile_opt/MODULE.bazel