Early exit or disable LTO if clang & rustc LLVM versions don't match #27

bandogora commented 2026年04月13日 21:54:53 +02:00

My builds often fail during the linking stage. I found the issue was due using 'rustup' for my host rust toolchain. rustup statically bundles its own LLVM backend, which lags behind the native Arch Linux system LLVM backend. Cross-Language LTO requires exact major versions so the build fails late in the process.

Changes:

• Check clang and rust LLVM versions are the same
  • On mismatch
    • Prompt user to exit or disable LTO
    • Give user hint for mismatch (rustup)
    • Give user workaround options
• Minor linting

I've tested this locally on a x86_64 platform and the check/build succeeds. I haven't tested on aarch64.

I haven't done much PKGBUILD development so I'm not sure if a user prompt is a good idea. If not, I can just make it an early exit to avoid waiting for a build to fail at the linking stage.

My builds often fail during the linking stage. I found the issue was due using 'rustup' for my host rust toolchain. `rustup` statically bundles its own LLVM backend, which lags behind the native Arch Linux system LLVM backend. Cross-Language LTO requires exact major versions so the build fails late in the process. Changes: - Check clang and rust LLVM versions are the same - On mismatch - Prompt user to exit or disable LTO - Give user hint for mismatch (rustup) - Give user workaround options - Minor linting I've tested this locally on a `x86_64` platform and the check/build succeeds. I haven't tested on `aarch64`. I haven't done much PKGBUILD development so I'm not sure if a user prompt is a good idea. If not, I can just make it an early exit to avoid waiting for a build to fail at the linking stage.

any1here commented 2026年04月13日 22:31:39 +02:00

While it is mostly the case that the major versions have to match, it doesn't always apply. Currently the stable Rust version 1.94.1 is based on LLVM 21 and cross LTO with Clang 22 (current clang version) apparently works. I have suggested to @ohfp to rather pin versions that are known to work together instead.

While it is mostly the case that the major versions have to match, it doesn't always apply. Currently the stable Rust version 1.94.1 is based on LLVM 21 and cross LTO with Clang 22 (current clang version) apparently works. I have suggested to @ohfp to rather pin versions that are known to work together instead.

bandogora commented 2026年04月13日 22:42:40 +02:00

@any1here wrote in #27 (comment):

While it is mostly the case that the major versions have to match, it doesn't always apply. Currently the stable Rust version 1.94.1 is based on LLVM 21 and cross LTO with Clang 22 (current clang version) apparently works. I have suggested to @ohfp to rather pin versions that are known to work together instead.

Linking is failing for me using Clang 22 and Rust 1.94.1 (LLVM 21) via rutup. I've also tried using thin LTO instead of cross, but no luck. Have you tested compiling with these versions? Maybe I missed a configuration somewhere?

@any1here wrote in https://codeberg.org/librewolf/arch/pulls/27#issuecomment-13091220: > While it is mostly the case that the major versions have to match, it doesn't always apply. Currently the stable Rust version 1.94.1 is based on LLVM 21 and cross LTO with Clang 22 (current clang version) apparently works. I have suggested to @ohfp to rather pin versions that are known to work together instead. Linking is failing for me using Clang 22 and Rust 1.94.1 (LLVM 21) via rutup. I've also tried using `thin` LTO instead of `cross`, but no luck. Have you tested compiling with these versions? Maybe I missed a configuration somewhere?

any1here commented 2026年04月13日 22:44:14 +02:00

@bandogora wrote in #27 (comment):

@any1here wrote in #27 (comment):

While it is mostly the case that the major versions have to match, it doesn't always apply. Currently the stable Rust version 1.94.1 is based on LLVM 21 and cross LTO with Clang 22 (current clang version) apparently works. I have suggested to @ohfp to rather pin versions that are known to work together instead.

Linking is failing for me using Clang 22 and Rust 1.94.1 (LLVM 21) via rutup. I've also tried using thin LTO instead of cross, but no luck. Have you tested compiling with these versions? Maybe I missed a configuration somewhere?

I was told that it apparently works by @ohfp 😅

I have compiled locally with rust 1.96 nightly and clang20 with thin not cross lto

@bandogora wrote in https://codeberg.org/librewolf/arch/pulls/27#issuecomment-13091487: > @any1here wrote in #27 (comment): > > > While it is mostly the case that the major versions have to match, it doesn't always apply. Currently the stable Rust version 1.94.1 is based on LLVM 21 and cross LTO with Clang 22 (current clang version) apparently works. I have suggested to @ohfp to rather pin versions that are known to work together instead. > > Linking is failing for me using Clang 22 and Rust 1.94.1 (LLVM 21) via rutup. I've also tried using `thin` LTO instead of `cross`, but no luck. Have you tested compiling with these versions? Maybe I missed a configuration somewhere? I was told that it apparently works by @ohfp 😅 I have compiled locally with rust 1.96 nightly and clang20 with thin not cross lto

bandogora commented 2026年04月13日 22:50:30 +02:00

@any1here wrote in #27 (comment):
I was told that it apparently works by @ohfp 😅

Maybe @ohfp has slightly different versions? I think LLVM 22 might have had some big changes to LTO.

This is what my env looks like right now for comparison

$ rustup -V:

rustup 1.29.0 (2026年03月23日)
info: This is the version for the rustup toolchain manager, not the rustc compiler.
info: the currently active `rustc` version is `rustc 1.94.1 (e408947bf 2026年03月25日)`

$ clang -v:

clang version 22.1.3
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/15.2.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64

> > @any1here wrote in #27 (comment): > I was told that it apparently works by @ohfp :sweat_smile: Maybe @ohfp has slightly different versions? I think LLVM 22 might have had some big changes to LTO. This is what my env looks like right now for comparison `$ rustup -V`: ``` rustup 1.29.0 (2026年03月23日) info: This is the version for the rustup toolchain manager, not the rustc compiler. info: the currently active `rustc` version is `rustc 1.94.1 (e408947bf 2026年03月25日)` ``` `$ clang -v`: ``` clang version 22.1.3 Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/15.2.1 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1 Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/15.2.1 Candidate multilib: .;@m64 Candidate multilib: 32;@m32 Selected multilib: .;@m64 ```

ohfp commented 2026年04月13日 23:01:50 +02:00

The base assumption with the PKGBUILD (and everything AUR, that is), is usually that the users run up to date "regular Arch" systems, and that (Arch) upstream rust, clang, llvm, etc. packages are installed (in the currently most up to date versions from the Arch repos).

Which is why issues like Manjaro users for example often have are a bit out of scope what the AUR PKGBUILDs usually aim to provide.

Which doesn't mean one couldn't address things per se, just to clarify why aspects like those here are usually not considered very much (with the PKGBUILD always trying to keep close(ish) to https://gitlab.archlinux.org/archlinux/packaging/packages/firefox/-/blob/main/PKGBUILD?ref_type=heads, too).

Which should answer the other question, too: it worked with clang and llvm 22.1.3 and rust 1.94.1 from the Arch repos :D
(rust 1.94.1 from the Arch repos is slightly patched though, see: https://gitlab.archlinux.org/archlinux/packaging/packages/rust)

The base assumption with the `PKGBUILD` (and everything AUR, that is), is usually that the users run up to date "regular Arch" systems, and that (Arch) upstream rust, clang, llvm, etc. packages are installed (in the currently most up to date versions from the Arch repos). Which is why issues like Manjaro users for example often have are a bit out of scope what the AUR `PKGBUILD`s usually aim to provide. Which doesn't mean one couldn't address things per se, just to clarify why aspects like those here are usually not considered very much (with the `PKGBUILD` always trying to keep close(ish) to https://gitlab.archlinux.org/archlinux/packaging/packages/firefox/-/blob/main/PKGBUILD?ref_type=heads, too). Which should answer the other question, too: it worked with clang and llvm 22.1.3 and rust 1.94.1 from the Arch repos :D (rust 1.94.1 from the Arch repos is slightly patched though, see: https://gitlab.archlinux.org/archlinux/packaging/packages/rust)

bandogora commented 2026年04月13日 23:50:54 +02:00

@ohfp wrote in #27 (comment):

The base assumption with the PKGBUILD (and everything AUR, that is), is usually that the users run up to date "regular Arch" systems, and that (Arch) upstream rust, clang, llvm, etc. packages are installed (in the currently most up to date versions from the Arch repos).

That makes sense. I like to think I have a "regular Arch" system, but maybe programming in rust disqualifies me?

To be fair, the Rust Archwiki says there are "two main ways to install Rust", "The Native installation", and "The rustup installation".

Which doesn't mean one couldn't address things per se, just to clarify why aspects like those here are usually not considered very much (with the PKGBUILD always trying to keep close(ish) to https://gitlab.archlinux.org/archlinux/packaging/packages/firefox/-/blob/main/PKGBUILD?ref_type=heads, too).

I understand if you don't want to add the user prompt and dynamic LTO. I think guarding against an LLVM mismatch in the prepare() function would still be nice so I know I have to makechrootpkg before waiting ~45min before realizing the linking failed :)

I know that's how I should do it now, but I'm sure I'll forget again!

Which should answer the other question, too: it worked with clang and llvm 22.1.3 and rust 1.94.1 from the Arch repos :D (rust 1.94.1 from the Arch repos is slightly patched though, see: https://gitlab.archlinux.org/archlinux/packaging/packages/rust)

rust 1.94.1 from the Arch repos is using LLVM 22 now. This issue keeps happening to me because I always do a full system upgrade and Arch always has updates sooner than rustup!

@ohfp wrote in https://codeberg.org/librewolf/arch/pulls/27#issuecomment-13092081: > The base assumption with the `PKGBUILD` (and everything AUR, that is), is usually that the users run up to date "regular Arch" systems, and that (Arch) upstream rust, clang, llvm, etc. packages are installed (in the currently most up to date versions from the Arch repos). That makes sense. I like to think I have a "regular Arch" system, but maybe programming in rust disqualifies me? To be fair, the [Rust Archwiki](https://wiki.archlinux.org/title/Rust#Installation) says there are "two main ways to install Rust", "The Native installation", and "The rustup installation". > Which doesn't mean one couldn't address things per se, just to clarify why aspects like those here are usually not considered very much (with the `PKGBUILD` always trying to keep close(ish) to https://gitlab.archlinux.org/archlinux/packaging/packages/firefox/-/blob/main/PKGBUILD?ref_type=heads, too). I understand if you don't want to add the user prompt and dynamic LTO. I think guarding against an LLVM mismatch in the `prepare()` function would still be nice so I know I have to `makechrootpkg` before waiting ~45min before realizing the linking failed :) I know that's how I should do it now, but I'm sure I'll forget again! > Which should answer the other question, too: it worked with clang and llvm 22.1.3 and rust 1.94.1 from the Arch repos :D (rust 1.94.1 from the Arch repos is slightly patched though, see: https://gitlab.archlinux.org/archlinux/packaging/packages/rust) rust 1.94.1 from the Arch repos is using LLVM 22 now. This issue keeps happening to me because I always do a full system upgrade and Arch always has updates sooner than rustup!

ohfp commented 2026年04月14日 00:18:54 +02:00

@bandogora wrote in #27 (comment):

I think guarding against an LLVM mismatch in the prepare() function would still be nice so I know I have to makechrootpkg before waiting ~45min before realizing the linking failed :)

Oh, yeah; no disagreement there ^^

Interactive prompts though would be a bit of a "bad practice thing" in PKGBUILDs though, so exiting/failing early in such cases would probably be the appropriate approach, yeah ^^

@bandogora wrote in https://codeberg.org/librewolf/arch/pulls/27#issuecomment-13093827: > I think guarding against an LLVM mismatch in the `prepare()` function would still be nice so I know I have to `makechrootpkg` before waiting ~45min before realizing the linking failed :) Oh, yeah; no disagreement there ^^ Interactive prompts though would be a bit of a "bad practice thing" in `PKGBUILD`s though, so exiting/failing early in such cases would probably be the appropriate approach, yeah ^^

bandogora commented 2026年04月14日 17:14:00 +02:00

@ohfp wrote in #27 (comment):

Oh, yeah; no disagreement there ^^

Oh good, I'm glad we agree :)

Interactive prompts though would be a bit of a "bad practice thing" in PKGBUILDs though, so exiting/failing early in such cases would probably be the appropriate approach, yeah ^^

Would you rather just the early exit, or automagically disabling LTO so the build can proceed?

@ohfp wrote in https://codeberg.org/librewolf/arch/pulls/27#issuecomment-13094538: > Oh, yeah; no disagreement there ^^ Oh good, I'm glad we agree :) > Interactive prompts though would be a bit of a "bad practice thing" in `PKGBUILD`s though, so exiting/failing early in such cases would probably be the appropriate approach, yeah ^^ Would you rather just the early exit, or automagically disabling LTO so the build can proceed?

This pull request has changes conflicting with the target branch.