Created attachment 800899 [details] buildlog sys-libs/binutils-libs-2.38-r2: finishes the strip stage with x86_64-pc-linux-gnu-strip: /var/tmp/portage/sys-libs/binutils-libs-2.38-r2/image/usr/lib64/stIEIWxU/regex.o: plugin needed to handle lto object can be solved by adding -ffat-lto-objects to the compiler flags
*** Bug 866416 has been marked as a duplicate of this bug. ***
*** Bug 866419 has been marked as a duplicate of this bug. ***
*** Bug 866500 has been marked as a duplicate of this bug. ***
"plugin needed to handle lto object" message should now be completely harmless. Workaround (calling ranlib on archive) was added to Portage over 3 years ago for bug #603594: https://gitweb.gentoo.org/proj/portage.git/commit/?id=2404ddca9d5db7992bf6853cbde8ca944224560c See also: https://sourceware.org/bugzilla/show_bug.cgi?id=21479 https://github.com/InBetweenNames/gentooLTO/issues/49
I suppose we can close this then?
Let's keep this open in case someone runs into it again.
Hey, just wanted to open a new bug for this issue. It occurs to any package built with LTO with USE="static-libs". Are you sure it's harmless?
(In reply to zurabid2016 from comment #7) > Hey, just wanted to open a new bug for this issue. It occurs to any package > built with LTO with USE="static-libs". Are you sure it's harmless? I've had kde-frameworks/kwayland fail to build with -fno-lto if dev-qt/qtgui:5 wasn't built with -ffat-lto-objects, but that's only happened when using the mold linker.