[arch-dev-public] Fun with LTO and stripping

[Allan McRae]

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