On 24/12/21 00:03, Allan McRae via arch-dev-public wrote:
With the latest devtools, LTO is enabled by default. This causes an
issue with .a and .o archived when stripping. Look out for output like:
strip:
./usr/lib/st4RPjCb/libsyslog_ng_native_connector_a-native-grammar.o:
plugin needed to handle lto object
That file is now nicely mangled!
Turns out this is a very well known issue in other distros, and has not
been fixed in binutils since reported in 2017.
There are a couple of workarounds:
1) disable LTO for that package
2) add -ffat-lto-objects to the C{,XX}FLAGS for those packages
I can see how to fix this in makepkg, but that will take a few days to
push out. In the meantime, pay attention to your build output!
I have discovered two things about LTO today:
1) the strip issue is issue really hard to detect in order to work
around in makepkg... There are too many variables.
2) clang requires -flto in LDFLAGS for LTO to work, but GCC does not.
This fix for the strip issue is for people to add CFLAGS+="
-ffat-lto-objects" to their PKGBUILDs if they use LTO and contain a .a
or .o archive. This affects ~300 packages in our repos (~2.5%). I will
create a TODO list.
I will patch makepkg to add -flto to LDFLAGS when lto is enabled. It has
no effect for gcc, and fixes clang. Until a new pacman package appears,
I'd suggest packages compiling with clang either add the LDFLAG in the
PKGBUILD or disable LTO.
Allan
Allan
