Comment # 10 on bug 1141913 from Martin Li��ka

(In reply to Richard Biener from comment #9)
> (In reply to Martin Li��ka from comment #8)
> > (In reply to Richard Biener from comment #5)
> > > Huh, looks like LTO bytecode leaked there.  Martin, I thought we have
> > > rpmlint checks in place that make sure this doesn't happen?
> > 
> > We do have a rpmlint check. But unfortunately, I also want to strip all LTO
> > ELF sections in brp-check-suse that runs before the rpmlint.
> 
> Hmm, I don't see either firing and the issue in binutils is probably that
> the static libraries we ship are built with slim LTO so stripping the LTO
> bytecode wouldn't help.

Exactly. Fat LTO objects will be needed for the package.

> 
> That is, this is a binutils packaging issue that surprisingly isn't caught
> by rpmlint checking that is in place?

Yes, as explained, caused by LTO section stripping before the check is fired.
So I'm suggesting to extend the rpmlint check to seek for __gnu_lto_slim symbol
in the archive.

Or do you have a better idea? Maybe an empty .text segment for embedded object
files?

> 
> > > 
> > > To reporter - do you have 'gcc' installed?  Your system _should_ have
> > > the plugin installed and thus you should get an LTO link here (not
> > > really intended by us, but ...).  It should be a symlink in
> > > /usr/lib/bfd-plugins/liblto_plugin.so.0.0.0 pointing to an existing
> > > actual shared library.