http://bugzilla.suse.com/show_bug.cgi?id=1141913
http://bugzilla.suse.com/show_bug.cgi?id=1141913#c12
--- Comment #12 from Richard Biener
(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.
Ah, OK. I would suggest to not strip LTO sections for slim objects instead. I guess invoking ar in a way forcing not to load a plugin would reveal such?
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.
-- You are receiving this mail because: You are on the CC list for the bug.