Skip to content

Instantly share code, notes, and snippets.

@zamazan4ik
Created December 17, 2024 19:04
Show Gist options
  • Select an option

  • Save zamazan4ik/30214afc04e895ecad8722aa63ef6bf0 to your computer and use it in GitHub Desktop.

Select an option

Save zamazan4ik/30214afc04e895ecad8722aa63ef6bf0 to your computer and use it in GitHub Desktop.
CachyOS and LTO
zamazan4ik — Сегодня, в 19:43
Can please anyone point me where in CachyOS's build scripts LTO is enabled by default for packages?
ptr1337 — Сегодня, в 19:44
Thats default enabled in archlinux in its makepkg.conf:
https://github.com/CachyOS/docker-makepkg/blob/master/docker-makepkg-v3/makepkg.conf#L97
lto string here
zamazan4ik — Сегодня, в 19:45
Is it the same for Rust packages?
Because I see e.g. in Fedora that they enable LTO by default for C packages but not for Rust
ptr1337 — Сегодня, в 19:46
many rust packages do not really work, with the above "lto" enabled, because it applies somehow double lto
rust packages, do whatever is default. We are changing here and there already to lto (we did for example on arch at cosmic)
https://gitlab.archlinux.org/pacman/pacman/-/merge_requests/131
Has been sadly closed
zamazan4ik — Сегодня, в 19:47
Yeah, i know about some nasty behavior when LTO is enabled in makepkg it breaks somehow LTO for Rust packages but if LTO is enabled in Cargo for a Rust package, it works completely fine
vnepogodin — Сегодня, в 19:47
it will never work. until cargo fix (probably will never happen as it is indended)
zamazan4ik — Сегодня, в 19:47
Oh....
ptr1337 — Сегодня, в 19:48
haha
vnepogodin — Сегодня, в 19:48
because Cargo doesn't promise lto will be used, in case it cannot compile/handle lto via bindgen or so on -> it wont use lto for crate/crates
while external -> you force it to use and it fails
zamazan4ik — Сегодня, в 19:50
I probably misunderstand you but if you enable in Cargo lto = true or set it via an env var, LTO definetely will be enabled (let's skip the cross-lang case for now)
zamazan4ik — Сегодня, в 19:51
For clarification about "enabled LTO" in Rust I mean Fat LTO or ThinLTO, not a Thin Local LTO
vnepogodin — Сегодня, в 19:51
it is conditional if you enable in Cargo.toml with lto = true
vnepogodin — Сегодня, в 19:51
neither do I
zamazan4ik — Сегодня, в 19:52
When this condition is violated?
vnepogodin — Сегодня, в 19:52
if it cannot compile
zamazan4ik — Сегодня, в 19:52
Ahhh, okay)
vnepogodin — Сегодня, в 19:52
so you have 10/11 with enabled LTO(either full or thin how you set it in Cargo.toml), and 1/11 will be without LTO
when you set via global, instead of Cargo.toml -> it will try to force it, therefore giving you error
been like that since 2021, from my memory. maybe its very old issue(or feature idk)
zamazan4ik — Сегодня, в 19:54
Could you please give me an example of package where I can test such a difference? Because I never heard about such a difference and it's not a documented behavior definetely
vnepogodin — Сегодня, в 19:54
back in the days I was also forcing lto on everything, learned that Cargo doesnt like force being applied. no abuse for cargo
behaviour is documented:
"Performs “fat” LTO which attempts to perform optimizations across all crates within the dependency graph."
zamazan4ik — Сегодня, в 19:56
But it doesn't say that it disables LTO if it cannot compile with LTO
vnepogodin — Сегодня, в 19:56
"thin" value is same, but attempts "thinlto"
actually it might be fixed with forcing lto with the plugin and emitcode
zamazan4ik — Сегодня, в 19:58
Okay, it's very interesting. Let me please recheck it with Cargo devs
uno momento
vnepogodin — Сегодня, в 19:58
idk. I just checked binary, lto was applied
so it did enable lto, but not for all (as with forced lto it was failing with error)
zamazan4ik — Сегодня, в 19:59
Could you please give me this binary as an example?
I will recheck it
vnepogodin — Сегодня, в 19:59
em maybe xD
I think easiest would be with cross-build
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment