You are not logged in.
Pages: 1
Recently mesa-git required a newer version of directx-headers that the one in repos, so as co-maintainer I switched the dependency from directx-headers to aur directx-headers-git
Build tests on my own systems worked fine, but several users reported build failures I couldn't reproduce .
The users were asked to build in clean chroots, but this didn't solve the issue.
I investigated and realised the directx-headers-git I used was build on my live system.
Building it with pkgctl did give the same error during building mesa-git that users reported .
I looked very close at the build logs, but didn't see anything suspicious.
The terminal output however did give an important clue .
-> Stripping unneeded symbols from binaries and libraries...
strip: ./usr/lib/stADczKO/src_dxguids.cpp.o: plugin needed to handle lto object
strip: ./usr/lib/stXo3DY8/src_dxguids.cpp.o: plugin needed to handle lto object
strip: ./usr/lib/stkCTnDj/src_d3dx12_property_format_table.cpp.o: plugin needed to handle lto object
strip: ./usr/lib/stgptr0C/src_d3dx12_property_format_table.cpp.o: plugin needed to handle lto object
-> Compressing man and info pages...
On my live system makepkg.conf disables lto unconditionally* .
Adding options=(!lto) solved the buiold failure for mesa-git and gave this as terminal output .
-> Stripping unneeded symbols from binaries and libraries...
-> Compressing man and info pages...
$ type strip
strip is /usr/bin/strip
$ pacman -Qo /usr/bin/strip
/usr/bin/strip is owned by binutils 2.43+r4+g7999dae6961-1
$
Should i file a bugreport against arch binutils package or upstream ?
While the cause is now known, the lack of logging in makepkg for such cases makes it very easy to miss the problem.
Would a bugreport to add logging a good idea ?
If so, should the BR be filed against archlinux pacman package or upstream ?
*packages I maintain that do work with lto explicilty enable it.
Last edited by Lone_Wolf (2024-09-21 12:56:01)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online
Offline
Building with CXXFLAGS+=" -ffat-lto-objects" does have the same effect as disabling lto :
- no errors when building directx-headers-git
- mesa-git finds what it needs
Seems I need to read up on (dis)advantages of fat-lto-objects.
(There must be a reason why it's not set by default)
Disliking systemd intensely, but not satisfied with alternatives so focusing on taming systemd.
clean chroot building not flexible enough ?
Try clean chroot manager by graysky
Online
Offline
Why are object files being packaged in directx-headers-git?
Offline
https://gitlab.archlinux.org/archlinux/ … type=heads has two static objects and !lto
usr/lib/libDirectX-Guids.a
usr/lib/libd3dx12-format-properties.a
Offline
Pages: 1