Created attachment 516752 [details] emerge info i686-pc-linux-gnu-gcc -I. -Isrc/ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DZLIB_CONST -DHAVE_AV_CONFIG_H -march=i686 -pipe -march=i686 -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/freetype2 -I/usr/include/opus -D_REENTRANT -I/usr/include/SDL2 -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-variable -march=i686 -pipe -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized -MMD -MF libpostproc/postprocess.d -MT libpostproc/postprocess.o -c -o libpostproc/postprocess.o src/libpostproc/postprocess.c In file included from src/libpostproc/postprocess.c:549:0: src/libpostproc/postprocess_template.c: In function 'dering_SSE2': src/libpostproc/postprocess_template.c:1097:5: error: 'asm' operand has impossible constraints __asm__ volatile( ^~~~~~~ make: *** [/var/tmp/portage/media-video/ffmpeg-3.3.6/work/ffmpeg-3.3.6/common.mak:60: libpostproc/postprocess.o] Error 1 * ERROR: media-video/ffmpeg-3.3.6::gentoo failed (compile phase): * emake failed Typical files attached.
Created attachment 516754 [details] emerge -pqv
Created attachment 516756 [details] environment
Created attachment 516758 [details] build log
In file included from src/libpostproc/postprocess.c:549:0: src/libpostproc/postprocess_template.c: In function 'dering_SSE2': src/libpostproc/postprocess_template.c:1097:5: error: 'asm' operand has impossible constraints __asm__ volatile( ^~~~~~~
The issue is reproducible with the following simplified configure line and gcc >= 6: $ ./configure --enable-shared --cc='gcc -m32' --optflags=-march=i686 --enable-gpl --cpu=i686 The problem is that FFmpeg's configure option --optflags is specified: I suspect the description of the option is misleading, in this specific case, you add options that to the best of my knowledge have no useful effect on teh binaries you compile, at the same time, you remove an (the!) important option from the actual compiler invocation that triggers this gcc regression. (Or did you intend to produce a slow binary?) I wonder if there are use cases where completely removing "--optflags" from Gentoo's FFmpeg builds would have a negative effect, I cannot immediately think of any... It is unlikely that there will be a code change in FFmpeg. Allow me to add (again) that reproducing issues such as this one from Gentoo builds gets infinitely more difficult by the fact that you add all these "disable-" options to the configure line that have no effect (and some "enable-" options that I believe also make no difference).
*** Bug 652132 has been marked as a duplicate of this bug. ***
(In reply to Carl Eugen Hoyos from comment #5) > The issue is reproducible with the following simplified configure line and > gcc >= 6: > $ ./configure --enable-shared --cc='gcc -m32' --optflags=-march=i686 > --enable-gpl --cpu=i686 > > The problem is that FFmpeg's configure option --optflags is specified: > I suspect the description of the option is misleading, in this specific > case, you add options that to the best of my knowledge have no useful effect > on teh binaries you compile, at the same time, you remove an (the!) > important option from the actual compiler invocation that triggers this gcc > regression. > (Or did you intend to produce a slow binary?) The problem with optflags is that it overrides completely user settings, as seen in this line for example: x86_64-pc-linux-gnu-gcc -m32 -I. -Isrc/ -D_ISOC99_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -D_POSIX_C_SOURCE=200112 -D_XOPEN_SOURCE=600 -DPIC -DZLIB_CONST -DHAVE_AV_CONFIG_H -DBUILDING_avfilter -march=skylake -mtune=skylake -O2 -pipe -march=skylake -std=c11 -fomit-frame-pointer -fPIC -pthread -I/usr/include/harfbuzz -I/usr/include/uuid -I/usr/include/fribidi -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/bs2b -I/usr/include/libdrm -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/freetype2 -I/usr/include/fribidi -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/openh264 -I/usr/include/openjpeg-2.3 -I/usr/include/opus -I/usr/include/opus -D_REENTRANT -pthread -I/usr/include/librsvg-2.0 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16 -I/usr/include/cairo -I/usr/include/glib-2.0 -I/usr/lib32/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/uuid -I/usr/include/freetype2 -I/usr/include/libdrm -I/usr/include/libpng16 -I/usr/include/samba-4.0 -I/usr/include/alsa -Wdeclaration-after-statement -Wall -Wdisabled-optimization -Wpointer-arith -Wredundant-decls -Wwrite-strings -Wtype-limits -Wundef -Wmissing-prototypes -Wno-pointer-to-int-cast -Wstrict-prototypes -Wempty-body -Wno-parentheses -Wno-switch -Wno-format-zero-length -Wno-pointer-sign -Wno-unused-const-variable -Wno-bool-operation -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize -Werror=format-security -Werror=implicit-function-declaration -Werror=missing-prototypes -Werror=return-type -Werror=vla -Wformat -fdiagnostics-color=auto -Wno-maybe-uninitialized -D_REENTRANT -I/usr/include/SDL2 -MMD -MF libavfilter/x86/avf_showcqt_init.d -MT libavfilter/x86/avf_showcqt_init.o -c -o libavfilter/x86/avf_showcqt_init.o src/libavfilter/x86/avf_showcqt_init.c -march=skylake -mtune=skylake -O2 -pipe are specified via CFLAGS and properly handled by ffmpeg -O3 -fno-math-errno -fno-signed-zeros -fno-tree-vectorize is optflags Now, I seriously doubt ffmpeg developers have time to test every single gcc release and patchset we use on Gentoo to ensure it is perfectly tuned. For example, if gcc 7.4.2_p12 has a bug that makes ffmpeg crash when compiled with -O3, there's no way around that (except making a debug build which is likely even slower). Plus, since the very beginning, Gentoo lets its users chose their compilation flags, with its pros and cons. In short: unless there is a way to append to optflags, we have to override them.
I would really like to discuss all these arguments (after all, FFmpeg developers made mistakes in the past, so it is quite likely that there are bugs in our build system) but I would like to suggest that you first provide a performance test (a command line including complete, uncut console output and an input sample) that shows how optflags overridden by Gentoo make (or actually: can make) FFmpeg faster than a default build: The sample configure line here in this bug report shows optimizations that to the best of my knowledge make the Gentoo binary slower than a default binary (on any x86 hardware). Until then, my suggestion is not to set any optimization flags with optflags (and not to set any optimizations with CFLAGS or --extra-cflags). It will still be possible to work-around compiler issues if necessary.
(In reply to Carl Eugen Hoyos from comment #8) It's not about performance here, it's about honouring what user wants. I'm pretty sure ffmpeg developers do a much better job at tuning compiler flags on the major architectures than the random user but that's not the point at all here: We want to leave people the ability to shoot themselves in the foot. If optflags can be appended, everything not specified by user would use ffmpeg's default, which should give the best results.
*** Bug 648518 has been marked as a duplicate of this bug. ***
Sorry for the misunderstanding: If this is not about the performance of the resulting binary and if users should be able to shoot themselves in the foot, what is the issue here?
(In reply to Carl Eugen Hoyos from comment #11) > Sorry for the misunderstanding: If this is not about the performance of the > resulting binary and if users should be able to shoot themselves in the > foot, what is the issue here? There is not much of an issue to me.
this occurs in 3.4.2-r1 too /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: lto-wrapper failed
I forgot '-pipe' and the optimization option (-O2 or -O3) in my CFLAGS and got this error.
This occurs without -flto in 3.4.2. So, using only the collowing CFLAGS: CFLAGS="-march=native"
Created attachment 528760 [details] CFLAGS="-march=native" build.log
Does the ebuild force -DPIC and -fPIC ? I think that's what may be causing this bug.
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6a2691a2bb66bd0497e458b0a00414507e8e99c0 commit 6a2691a2bb66bd0497e458b0a00414507e8e99c0 Author: Alexis Ballier <aballier@gentoo.org> AuthorDate: 2018-11-27 11:54:32 +0000 Commit: Alexis Ballier <aballier@gentoo.org> CommitDate: 2018-11-27 11:54:42 +0000 media-video/ffmpeg: Pass disable optimization to configure. This is only useful for hardcoded CFLAGS. We use optflags that override them anyway. However, some configure checks run with fomit-frame-pointer when this is enabled. This lures the build system it has enough registers to build some inline asm on x86 and then causes build failures. Closes: https://bugs.gentoo.org/671746 Closes: https://bugs.gentoo.org/645778 Package-Manager: Portage-2.3.51, Repoman-2.3.12 RepoMan-Options: --force Signed-off-by: Alexis Ballier <aballier@gentoo.org> media-video/ffmpeg/ffmpeg-4.1.ebuild | 4 ++++ media-video/ffmpeg/ffmpeg-9999.ebuild | 4 ++++ 2 files changed, 8 insertions(+)
