-
Notifications
You must be signed in to change notification settings - Fork 440
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
lto cannot be used for proc-macro
crate type without -Zdylib-lto
#3143
Comments
Proc-macro crates can not be linked with lto and we should not emit bitcode either. This fixes bazelbuild#3143
I have fix for it in #3147 |
Thank you, appreciate your effort to get this solved. |
Proc-macro crates can not be linked with lto and we should not emit bitcode either. This fixes bazelbuild#3143
Proc-macro crates can not be linked with lto and we should not emit bitcode either. This fixes bazelbuild#3143
…#3147) I would like to make lto setting public in toolchain so that when we are providing custom toolchains it would be easier to make configurations for LTO with `select` statements. The logic which determines the flags based on cargo outputs. Proc-macro crates can not be linked with lto and we should not emit bitcode either. This fixes #3143 --------- Co-authored-by: Daniel Wagner-Hall <dwagnerhall@apple.com>
@havasd Okay, now as the fix is merged, how am I supposed to use this one? |
you can use, git_override to pick up the latest version if you use
|
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:
***@***.***>
|
I see, I misunderstood your question. With the original implementation you can do this With my latest changes ideally you could make it work by creating your own toolchain and there specifying the
Now how you prepare a custom toolchain that is a different story. |
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 |
Fixes comment mentioned in [3143#issuecomment-2568947858](#3143 (comment)) --------- Co-authored-by: UebelAndre <github@uebelandre.com>
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?
The text was updated successfully, but these errors were encountered: