Created attachment 865123 [details] build log compressed with xz Title basically, I can't figure out what's going on. It somehow ignores package.env and reads -flto from the flags in make.conf. If I remove the flag from make.conf too, --enable-lto doesn't get passed. I have an entry in /etc/portage/package.env media-video/ffmpeg nolto Contents of /etc/portage/package.env/nolto: CFLAGS="-march=native -O2 -pipe -fno-plt -fno-semantic-interposition -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing" CXXFLAGS="-march=native -O2 -pipe -fno-plt -fno-semantic-interposition -Werror=odr -Werror=lto-type-mismatch -Werror=strict-aliasing"
Created attachment 865124 [details] /var/tmp/portage/media-video/ffmpeg-9999/temp/environment
ffmpeg's is-flagq looks at *all* flags, that includes fortran ones like FFLAGS and FCFLAGS which I assume your make.conf is defining but package.env is not overriding. Albeit imo ffmpeg should just have a USE=lto like most other ebuilds rather than rely on heuristics, not only avoids checking unused variables but also allows to override with -fno-lto.
(In reply to Ionen Wolkens from comment #2) > ffmpeg's is-flagq looks at *all* flags, that includes fortran ones like > FFLAGS and FCFLAGS To be precise, it looks at these: all-flag-vars() { echo {ADA,C,CPP,CXX,CCAS,F,FC,LD}FLAGS }
(In reply to Kostadin Shishmanov from comment #1) > Created attachment 865124 [details] > /var/tmp/portage/media-video/ffmpeg-9999/temp/environment Hrm, guess I spoke too soon with that guess. It doesn't seem to be in there.
(In reply to Ionen Wolkens from comment #4) > (In reply to Kostadin Shishmanov from comment #1) > > Created attachment 865124 [details] > > /var/tmp/portage/media-video/ffmpeg-9999/temp/environment > Hrm, guess I spoke too soon with that guess. It doesn't seem to be in there. Oh right, filter-lto removed it, so it wouldn't be. But that's after is-flagq was ran. So nevermind, it's probably indeed {F,FC}FLAGS.
You were indeed right initially, it also looks at FCFLAGS and FFLAGS, too. After adding them manually to the env file with -flto removed, it builds properly.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=47a2a87a9573f8d77f38f3a9bbfa4d4e8eb54d28 commit 47a2a87a9573f8d77f38f3a9bbfa4d4e8eb54d28 Author: Sam James <sam@gentoo.org> AuthorDate: 2024-01-23 18:41:15 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2024-01-23 18:45:25 +0000 media-video/ffmpeg: use tc-is-lto instead of error-prone is-flagq is-flagq won't pick up on e.g. -fno-lto appended. Closes: https://bugs.gentoo.org/909572 Signed-off-by: Sam James <sam@gentoo.org> media-video/ffmpeg/ffmpeg-4.4.4-r8.ebuild | 2 +- media-video/ffmpeg/ffmpeg-5.1.4-r2.ebuild | 2 +- media-video/ffmpeg/ffmpeg-6.0-r11.ebuild | 2 +- media-video/ffmpeg/ffmpeg-6.0-r9.ebuild | 2 +- media-video/ffmpeg/ffmpeg-6.0.1-r1.ebuild | 2 +- media-video/ffmpeg/ffmpeg-6.1-r4.ebuild | 2 +- media-video/ffmpeg/ffmpeg-6.1.1-r1.ebuild | 2 +- media-video/ffmpeg/ffmpeg-9999.ebuild | 2 +- 8 files changed, 8 insertions(+), 8 deletions(-)
If I understand https://bugs.gentoo.org/772854 correctly, they decided to just disable LTO for x86, but leave it on for amd64 in multilib set ups. For my system it's doing x86 first, which calls filter-lto, tc-is-lto will return true here, but when it goes to build amd64 next, tc-is-lto returns false since filter-lto was already called which filters out the flags already. So lets say I have an ebuild that does some debug prints in multilib_src_configure that will print the ABI, then print yes or no if tc-is-lto is true, I guess the output: debug: x86 debug: yes <bunch more junk> debug: amd64 debug: no The cflags are not reset between multilib calls, causing tc-is-lto to have unexpected results I guess.
