2.4.9 & 2.4.9-r200 ebuilds failed Reproducible: Always
Created attachment 405928 [details] emerge logs
Firstly, this bug report is all over the place. No declaration of what the package is, no build logs, no emerge --info, bug is filed in the wrong component... Please take some time to read https://wiki.gentoo.org/wiki/Bugzilla/Bug_report_guide before filing your next bug. As a result of the above, I'm going to be closing this as NEEDINFO. Feel free to re-open this after you have supplied emerge --info and build.logs, and please please please try to follow the reporting guidelines next time you file bug.
(In reply to NP-Hardass from comment #2) > Firstly, this bug report is all over the place. No declaration of what the > package is, no build logs, no emerge --info Logs are there. Unfortunately, logs show this: > CFLAGS="-march=core-avx-i -mcx16 -msahf -mno-movbe -mno-aes -mpclmul -mpopcnt -mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-bmi2 -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1 -mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mf16c -mfsgsbase -mno-rdseed -mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -mtune=core-avx-i -O2 -pipe -fgraphite -flto=4 -fopenmp -fgraphite-identity -floop-block -floop-interchange -floop-strip-mine -ftree-loop-distribution -ftree-loop-linear -ftree-vectorize" Such aggressive optimization, especially using new compiler features like graphite and lto, *especially* when using compilers (4.8 and 4.9) where those features are somewhat buggy, can cause all sorts of failures. So reset CFLAGS to something reasonable, I recommend "-march=core-avx-i -mtune=core-avx-i -O2 -pipe". Then rebuild your entire system (starting with the toolchain, glibc, and the kernel), and see if you can still reproduce this failure. Very aggressive flags should be reserved for specific packages where performance is critical, for example media codecs in a render farm or scientific libraries for a bioinformatics cluster, and *only* if you've carefully checked that the resulting binary works and passes a wide range of tests.
And same applies to LDFLAGS and CXXFLAGS of course.
Apologies. Misinterpreted the logs, and concur with the bug being reopened. Regarding the comment about CFLAGS, are you able to replicate this bug when your system is build with Safe CFLAGS? https://wiki.gentoo.org/wiki/Safe_CFLAGS
(what is the reason for reopening if info is still pending?)
