On Sat, Apr 26, 2014 at 11:00 AM, Martin Vaeth <mar...@mvath.de> wrote: > Rich Freeman <ri...@gentoo.org> wrote: >> It does make sense to filter the flag when it is known to >> not work. > > This would be the best solution of course: Recommend LTO and > filter every occassion which breaks. But currently this is > not realistic, because too many ebuilds would need to be tested > and checked. Moreover, sometimes it depends on the gcc version > whether filtering is necessary (although, as mentioned, these > cases are relatively rare with <gcc-4.9). > So, one should not expect this in any near future.
Sounds like many are already using it, and thus much of this testing has already been done. The results simply need to be collected. FWIW the list of packages I have issues with include: app-antivirus/clamav app-backup/bacula app-office/libreoffice dev-libs/elfutils dev-libs/libaio dev-libs/libpcre dev-python/pygtkglext dev-python/wxpython dev-qt/qt-creator dev-tex/luatex dev-util/kdevelop dev-util/kdevplatform kde-base/gwenview kde-base/kdelibs kde-base/korganizer media-gfx/inkscape media-sound/amarok media-video/mplayer net-libs/webkit-gtk net-misc/nx net-wireless/gnuradio sys-apps/kmod sys-devel/llvm sys-power/upower x11-libs/gtkglext x11-libs/wxGTK There are also other packages which I build with very simplified CFLAGS (just -O2 basically) which may or may not have LTO issues. Also, some packages above like libreoffice may very well build just fine if you have sufficient RAM. I do run a modest number of multimedia packages, and only the ones above have caused issue (though if any haven't been updated in a few years by some stroke of luck and being abandoned then they wouldn't be tested with LTO). Rich
