Or the other way around, -lto becomes harmful if it is enabled during an ebuild which uses "filter-flags -O?". I discovered that after building media-libs/x264 with -lto (link time optimization) the resulting binaries where not optimizied at all. That is the code looked like ist was compiled with "-O0" and the resulting low performance made it unuseable for live-streaming. I discovered that the ebuild strips all -O flags from LDFLAGS while linking. But if "-lto" is used, the -O flag used during linking determines the final optimization of the resulting binary. Even if the the code was optimized according to some "-O" level during compile, if linking without "-O" the optimization is _completely_ removed. An easy workaround for this package exists (USE=custom-cflags avoids the stripping), but this is something to keep in mind. Teere may be plenty of packages suffering from this. Maybe a general warning whenever during link phase "-ftlo..." is detected, by "-O..." is not would be a good idea. Reproducible: Always Steps to Reproduce: 1. Use CFLAFS="-O2 -flto" and LDFLAGS=$CFLAGS 2. emerge x264 3. Have no fun with completly unoptimized libx264 codecs Actual Results: Resulting binaris are silently completely unoptimized. Expected Results: Ideal would be working binaries optmized with -lto, but even a failed build would be ok too.
> Use CFLAFS="-O2 -flto" and LDFLAGS=$CFLAGS I do not use lto, but LDFLAGS="-O2 -flto" sure is wrong: http://www.gentoo.org/proj/en/qa/asneeded.xml "Note that LDFLAGS are generally passed not directly to ld but to gcc, so you have to use the -Wl, prefix to pass them back to the linker." I have LDFLAGS="-Wl,-O1 -Wl,--as-needed" and x264 logs have such lines: x86_64-pc-linux-gnu-gcc -o libx264.so.130 common/mc.o common/predict.o common/pixel.o common/macroblock.o common/frame.o common/dct.o common/cpu.o common/cabac.o common/common.o common/osdep.o common/rectangle.o common/set.o common/quant.o common/deblock.o common/vlc.o common/mvpred.o common/bitstream.o encoder/analyse.o encoder/me.o encoder/ratecontrol.o encoder/set.o encoder/macroblock.o encoder/cabac.o encoder/cavlc.o encoder/encoder.o encoder/lookahead.o common/threadpool.o common/x86/mc-c.o common/x86/predict-c.o common/x86/const-a.o common/x86/cabac-a.o common/x86/dct-a.o common/x86/deblock-a.o common/x86/mc-a.o common/x86/mc-a2.o common/x86/pixel-a.o common/x86/predict-a.o common/x86/quant-a.o common/x86/cpu-a.o common/x86/dct-64.o common/x86/bitstream-a.o common/x86/sad-a.o common/x86/trellis-64.o -shared -Wl,-soname,libx264.so.130 -Wl,-Bsymbolic -m64 -Wl,-O1 -Wl,--as-needed -lm -lpthread x86_64-pc-linux-gnu-gcc -o x264 x264.o input/input.o input/timecode.o input/raw.o input/y4m.o output/raw.o output/matroska.o output/matroska_ebml.o output/flv.o output/flv_bytestream.o filters/filters.o filters/video/video.o filters/video/source.o filters/video/internal.o filters/video/resize.o filters/video/cache.o filters/video/fix_vfr_pts.o filters/video/select_every.o filters/video/crop.o filters/video/depth.o input/thread.o -lx264 -m64 -Wl,-O1 -Wl,--as-needed -lm -lpthread As you can see '-Wl,-O1' is not filtered. This bug should be closed as INVALID.
(In reply to Nikoli from comment #1) > As you can see '-Wl,-O1' is not filtered. This bug should be closed as > INVALID. looks like you are right, closing
"Note that LDFLAGS are generally passed not directly to ld but to gcc, so you have to use the -Wl, prefix to pass them back to the linker." This is indeed exactly what is needed: -flto and -O2 should be passed to gcc, not to the linker. Prefixing them with "-Wl," doesn't make any sense. Please have a look at http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-flto-902 if you are unsure how to use LTO. The gcc guys give exactly this example for using LTO while linking: gcc -o myprog -O2 -flto -fuse-linker-plugin a.o b.o -lfoo > LDFLAGS="-O2 -flto" sure is wrong Pretty bold statement :-)
filter-flags has been dropped from -9999 and thus from upcoming snapshot
