mirror of
https://github.com/JakeStanger/ironbar.git
synced 2026-07-11 08:15:21 +01:00
[GH-ISSUE #921] AUR Fails to build from Git (colpetto) #276
Labels
No labels
A:Build
A:CI
A:Client
A:Config
A:Core
A:Documentation
A:Documentation
A:IPC
A:Testing
A:UX/UI
blocked
BREAKING CHANGE
duplicate
good first issue
GTK4
help wanted
invalid
M:Battery
M:Battery
M:Bindmode
M:Bluetooth
M:Brightness
M:Cairo
M:Clipboard
M:Clock
M:Clock
M:Custom
M:Focused
M:Keyboard
M:Launcher
M:Menu
M:Music
M:Music
M:Music
M:Network Manager
M:Notifications
M:SysInfo
M:Tray
M:Volume
M:Workspaces
partially resolved
P:Critical
P:High
P:Low
P:Medium
pull-request
T:Bug
T:Bug
T:Core Enhancement
T:Module Enhancement
T:New Module
T:Question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
JakeStanger/ironbar#276
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @kode54 on GitHub (Apr 4, 2025).
Original GitHub issue: https://github.com/JakeStanger/ironbar/issues/921
Describe the bug
The project now fails to build as of commit
226048a2e3due to colpetto failing to link.To Reproduce
Steps to reproduce the behavior:
ironbar-gitfrom the AURpkgctl buildExpected behavior
Package should link properly, I'm not sure if it's a missing dependency.
System information:
226048a2e3Configuration
N/A, as the issue is with building.
Additional context
Here is the error message:
Screenshots
N/A
@JakeStanger commented on GitHub (Apr 4, 2025):
That's an odd error that it's failing with at the system level. Can you check the following please:
@quietvoid commented on GitHub (Apr 4, 2025):
Getting the same here.
I use Wayland but had no issue building previously.
@JakeStanger commented on GitHub (Apr 4, 2025):
It could be the evdev package. With that it builds fine for me in isolation. If not I'll have a more in depth look when I can.
@quietvoid commented on GitHub (Apr 4, 2025):
Still doesn't build after installing
xf86-input-evdevfor me.I have no problem building
colpettoon its own FWIW.@JakeStanger commented on GitHub (Apr 5, 2025):
I can confirm it breaks for me running
pkgctl build. It works in a clean docker container though, so not sure what that's about.If you run using just
makepkg -sdoes it work?@quietvoid commented on GitHub (Apr 5, 2025):
Does not work with
makepkgeither.@JakeStanger commented on GitHub (Apr 5, 2025):
Can you upload the full build log if possible please?
Also paging @morr0ne
@quietvoid commented on GitHub (Apr 5, 2025):
Looks like this: build.txt
It only seems to fail building the package, manually building with cargo works fine.
@puppymati commented on GitHub (Apr 5, 2025):
I am almost certain that what's happening is the linker failing to find the C helper and not including it. I do wonder what changes between a clean chroot and normal builds. My naive assumption is that we need some extra deps or possibly linker args. It would help having a full verbose log of makepkg. It seems that verdi also fails to build so maybe it's worth opening an issue on the colpetto repo.
@JakeStanger commented on GitHub (Apr 5, 2025):
Yep, I've done sanity checks on just about everything else I can think of at this point. Nothing's getting stripped out and all the symbols are there, the linker just doesn't see it.
Everything points to it being either a missing dep, or a difference in compiler/linker configs.
@quietvoid commented on GitHub (Apr 6, 2025):
I have managed to build it when adding
options=("!buildflags")to the PKGBUILD: https://wiki.archlinux.org/title/Makepkg#Makepkg_fails,_but_make_succeedsMy makepkg.conf has these:
Not sure because if I do add these flags (exporting or before
cargo build), it still builds and links fine.@quietvoid commented on GitHub (Apr 6, 2025):
This is as verbose as I can get things to be: ironbar-git-0.16.1.r212.gf2bc33e-1-x86_64-build.log
@JakeStanger commented on GitHub (Apr 7, 2025):
Thanks for the extra info, that seems like a promising lead. Hoping to track this down tonight.
@JakeStanger commented on GitHub (Apr 7, 2025):
Haven't had a chance to test yet, but here's my flags for comparison. There are a few differences so presumably one of them is the cause
@JakeStanger commented on GitHub (Apr 7, 2025):
Alright yeah I've no idea, but I've confirmed exactly what you found. None of the flags seem responsible, and just pasting the flags as-is into the PKGBUILD works fine. It's only when they're imported from the pkgbuild file, which points to a bug in Arch's build system to me?
Until anybody suggests anything better, I've put
options=("!buildflags")and the default flags inside the PKGBUILD so it should build now.Please let me know if that seems to have sorted it.
@quietvoid commented on GitHub (Apr 7, 2025):
It works fine now but the fix is a bit weird.
@quietvoid commented on GitHub (Apr 8, 2025):
It can be reproduced with
-flto/-flto=autoalone by the way.@kode54 commented on GitHub (Apr 8, 2025):
Yes, Arch enables LTO by default. Bugs with LTO can be worked around by the application of:
Edit: Also, technically, you were missing the RUSTFLAGS from /etc/makepkg.conf.d/rust.conf, but that wasn't the cause of the problem.
Edit 2: Yup, builds with !lto and none of the other stuff.
@JakeStanger commented on GitHub (Apr 8, 2025):
I've been talking to @morr0ne in the background, and based off the above (thanks again for all the help) she believes it was just a small issue in the crate where functions weren't correctly marked as
extern. This hit a bit of an edge-case because LTO is enabled by default for C but not Rust (I think).The takeaway from that is that there should now be a proper fix in place in the colpetto crate as of this commit, and hopefully this can be resolved without needing to resort to disabling LTO.
I will test, confirm and update the PKGBUILD later.
@JakeStanger commented on GitHub (Apr 8, 2025):
Confirmed it's LTO. Seems that was enabled by default a few years back, and my own install predates that so checks out.
Colpetto commit doesn't seem to have fixed the build in Ironbar for some reason, so I'll push up an update to the makepkg that just disables LTO instead of yesterday's hack.
@mati865 commented on GitHub (Jul 3, 2025):
I think disabling LTO in PKGBUILD is a valid solution here.
First of all, that option AFAIK only enables C/C++ LTO which itself is not going to be noticeable for that library even if it worked.
If you want to get it to work, you have to use
-C linker-plugin-ltowhich complicates things a bit. You have to build C code with Clang version that roughly matches LLVM version used by Rust and finally use LLD (maybe Mold would also work) for linking.So, that's a lot of hassle for often a little benefit (unless your C code does some heavy lifting). Notice how all Arch Linux packages that use Rust and depend on C libraries also disable
ltooption.That's because when LTO is enabled, GCC/Clang will emit only GIMPLE or LLVM IR bitcode instead of machine code. This can be overriden by using not just
CFLAGS=-fltobutCFLAGS="-flto -ffat-lto-objects". This will make them emit both bitcode and machine code, so the linker can pick either. Note, this gives no benefit over disabling LTO in this case and just slows down compilation.Note this is different from LTO level that you configure in
Cargo.toml. That optimisation works only on Rust code and is performed before outputting final objects, so also before the linker is involved.@JakeStanger commented on GitHub (Jul 7, 2025):
That's a convincing enough argument to close this issue for now at least. If it does cause issues or a better solution presents itself, we can re-open. Thanks for your input!
@puppymati commented on GitHub (Jul 7, 2025):
Just to add a little post-mortem. Using linker-plugin-lto does work and that's why I never noticed the issue; verdi itself is built using the linker flag and the arch packages build properly with lto:
github.com/morr0ne/xtask-common@6cfcb9b685/src/lib.rs (L71)@mati865 commented on GitHub (Jul 7, 2025):
BTW, I forgot to mention it last time but
github.com/verdiwm/colpetto@6108f5e832is not a correct way to do it.externshould be placed only on the declaration and not on the definition.The correct way to let the compiler know to emit a specific function is to add
attribute__((used))to its definition. The linker might still optimise it out however.