media-video/vlc fail to build with gcc version 4.8.2 (Gentoo Hardened 4.8.2 p1.3r1, pie-0.5.8r1). Using gcc version 4.7.3 (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) is a workaround. # emerge -va1t emerge -va1t media-video/vlc [ebuild R ] media-video/vlc-2.1.2:0/5-7 USE="X a52 aalib alsa atmo avahi avcodec avformat bidi bluray cdda cddb dbus dirac directfb dts dvbpsi dvd egl encode faad ffmpeg flac fontconfig gcrypt gme gnutls libass libcaca libsamplerate live matroska mmx modplug mp3 mpeg mtp musepack ncurses ogg omxil opengl opus png postproc pulseaudio rtsp schroedinger sdl sdl-image shout speex sse svg swscale taglib theora truetype twolame udev vaapi vdpau vorbis wma-fixed x264 xcb xml xv zvbi (-altivec) (-audioqueue) -chromaprint -dc1394 -debug (-directx) -dvb (-dxva2) -fdk -fluidsynth -gnome -growl -httpd -ieee1394 (-ios-vout) -jack -kate -kde -libnotify -libtar -libtiger -linsys -lirc -lua (-macosx) (-macosx-audio) (-macosx-dialog-provider) (-macosx-eyetv) (-macosx-qtkit) (-macosx-quartztext) (-macosx-vout) (-media-library) (-neon) -opencv -optimisememory -projectm -qt4 (-qt5) -rdp -run-as-root -samba -sftp -sid -skins {-test} -tremor -upnp -v4l -vcdx -vlm" [snip] ../../doltlibtool --tag=CC --mode=compile i686-pc-linux-gnu-gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../.. -DMODULE_NAME=$(p="libdeinterlace_plugin_la-algo_yadif.lo"; p="${p##*/}"; p="${p#lib}"; echo "${p%_plugin*}") -DMODULE_NAME_IS_$(p="libdeinterlace_plugin_la-algo_yadif.lo"; p="${p##*/}"; p="${p#lib}"; echo "${p%_plugin*}") -DMODULE_STRING=\"$(p="libdeinterlace_plugin_la-algo_yadif.lo"; p="${p##*/}"; p="${p#lib}"; echo "${p%_plugin*}")\" -D__PLUGIN__ -I../../include -I../../include -O2 -march=native -O2 -pipe -fomit-frame-pointer -Wall -Wextra -Wsign-compare -Wundef -Wpointer-arith -Wbad-function-cast -Wwrite-strings -Wmissing-prototypes -Wvolatile-register-var -Werror-implicit-function-declaration -pipe -fvisibility=hidden -c -o libdeinterlace_plugin_la-algo_yadif.lo `test -f 'deinterlace/algo_yadif.c' || echo './'`deinterlace/algo_yadif.c deinterlace/algo_yadif.c: In function 'RenderYadif': deinterlace/algo_yadif.c:129:20: warning: assignment from incompatible pointer type [enabled by default] filter = yadif_filter_line_c_16bit; ^ In file included from deinterlace/yadif.h:49:0, from deinterlace/algo_yadif.c:48: deinterlace/yadif_template.h: In function 'yadif_filter_line_ssse3': deinterlace/yadif_template.h:134:9: error: 'asm' operand has impossible constraints __asm__ volatile(\ ^ deinterlace/yadif_template.h:256:9: note: in expansion of macro 'FILTER' FILTER ^ deinterlace/yadif_template.h:134:9: error: 'asm' operand has impossible constraints __asm__ volatile(\ ^ deinterlace/yadif_template.h:262:9: note: in expansion of macro 'FILTER' FILTER ^ Makefile:3066: recipe for target 'libdeinterlace_plugin_la-algo_yadif.lo' failedmake[4]: *** [libdeinterlace_plugin_la-algo_yadif.lo] Error 1 make[4]: Leaving directory '/var/tmp/portage/media-video/vlc-2.1.2/work/vlc-2.1.2/modules/video_filter' Makefile:2550: recipe for target 'all' failed make[3]: *** [all] Error 2 make[3]: Leaving directory '/var/tmp/portage/media-video/vlc-2.1.2/work/vlc-2.1.2/modules/video_filter' Makefile:1084: recipe for target 'all-recursive' failed make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory '/var/tmp/portage/media-video/vlc-2.1.2/work/vlc-2.1.2/modules' Makefile:1952: recipe for target 'all-recursive' failed make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory '/var/tmp/portage/media-video/vlc-2.1.2/work/vlc-2.1.2' Makefile:1836: recipe for target 'all' failed make: *** [all] Error 2 * ERROR: media-video/vlc-2.1.2::gentoo failed (compile phase): * emake failed Full log attached and emerge --info Reproducible: Always
Created attachment 369280 [details] build.log
Created attachment 369282 [details] emerge --info
GCC seems more picky about asm operands, as seen by other packages starting to throw this too; since I lack the knowledge, I'll await and look around for resolution. Feel free to report this upstream and provide us a link to there.
I filed a ticket upstream: https://trac.videolan.org/vlc/ticket/11144 I don't really understand what's going on, but if no one has filed a bug on the corresponding file in libav or ffmpeg, I suppose that there must be a fix for this somewhere in the world.
Alternatively, this could be a hardened issue; see here: https://bugs.gentoo.org/show_bug.cgi?id=506206#c5
Okay, I'm tring to fix bugs blocking gcc-4.8, so this one has got to be dealt with. What's going on here is that you are an x86 system with only 4 general purpose regesters, %eax through %edx. On an non-hardened system, vlc's asm needs all four, but on a hardened system, you need to reserve one, typically %ebx, for PIE, leaving you one register short. We could try to move stuff around the registers to shield ebx, but probably the easiest thing to do is turn off PIE. I'll see what I can come up with.
If you disable sse do it compile?
(In reply to Magnus Granberg from comment #7) > If you disable sse do it compile? No its mmx, but do we really want to mask mmx on vlc for hardened i686?
(In reply to Anthony Basile from comment #8) > (In reply to Magnus Granberg from comment #7) > > If you disable sse do it compile? > > No its mmx, but do we really want to mask mmx on vlc for hardened i686? Actually its both mmx and sse. The offending functions are yadif_filter_line_{mmx,sse2,ssse3} in modules/video_filter/deinterlace/algo_yadif.c that make use of the same FILTER macro in yadif_template.h. This is i686 specific, but I am not yet convinced it is hardened specific. We may have to mask on the default profiles.
(In reply to Anthony Basile from comment #9) > (In reply to Anthony Basile from comment #8) > > (In reply to Magnus Granberg from comment #7) > > > If you disable sse do it compile? > > > > No its mmx, but do we really want to mask mmx on vlc for hardened i686? > > Actually its both mmx and sse. The offending functions are > yadif_filter_line_{mmx,sse2,ssse3} in > modules/video_filter/deinterlace/algo_yadif.c that make use of the same > FILTER macro in yadif_template.h. > > This is i686 specific, but I am not yet convinced it is hardened specific. > We may have to mask on the default profiles. Okay the problem here is -fstack-check which is new in 4.8 and is enabled in the gcc specs for hardened, but not vanilla. This takes up on register which puts i686 over the edge. The sitatuation is similar to ffmpeg where we have + # we need to disable -fstack-check if use >=gcc 4.8.0 on x86 and + # hardened compiler #471755 #506206 + if use x86 && gcc-specs-ssp-to-all ; then + append-flags $(test-flags -fstack-check=no) + fi + However this is less that idea because it checks of the gcc specs have -fstack-protector-all and not stack-check. It works because the later is contigent on the former. Before I fix this, I'm going to propose to gentoo-dev@ that we add the following to toolchain-funcs.eclass to directly check for stack-check: --- toolchain-funcs.eclass.orig 2014-10-12 11:23:41.585182742 -0400 +++ toolchain-funcs.eclass 2014-10-12 11:31:57.170205300 -0400 @@ -610,6 +610,12 @@ directive=$(gcc-specs-directive cc1) return $([[ "${directive/\{!fstrict-overflow:}" != "${directive}" ]]) } +# Returns true if gcc builds with fstack-check +gcc-specs-stack-check() { + local directive + directive=$(gcc-specs-directive cc1) + return $([[ "${directive/\{!fno-stack-check:}" != "${directive}" ]]) +} # @FUNCTION: gen_usr_ldscript Then in both vlc and ffmpeg we'll add if use x86 && gcc-specs-stack-check ; then append-flags $(test-flags -fstack-check=no) fi This will future proof our code against some future time when we decide vanilla gcc should have -fstack-check and forget all about this bug.
Okay I just tested and the following patch fixes the problem. I'll just inline it because its short and it makes it easier to read. It should be added to at least 2.1.2 and above. yellow vlc # diff -Naur vlc-2.1.2.ebuild vlc-2.1.2-r1.ebuild --- vlc-2.1.2.ebuild 2014-09-10 18:31:13.000000000 -0400 +++ vlc-2.1.2-r1.ebuild 2014-10-17 08:28:55.485368651 -0400 @@ -262,6 +262,11 @@ # FIXME! append-ldflags "-L/usr/$(get_libdir)/sidplay/builders/" + # We need to turn off -fstack-check on x86. Bug #499996 + if use x86 && gcc-specs-stack-check ; then + append-flags $(test-flags -fno-stack-check) + fi + if use truetype || use projectm ; then local dejavu="/usr/share/fonts/dejavu/" myconf="--with-default-font=${dejavu}/DejaVuSans.ttf \ Can we get this in soon so we can remove this blocker to gcc-4.8. Alternatively we can just drop it as a blocker since only hardened adds -fstack-check to the specs now. One caveat. This will bite anyone who adds -fstack-check manually since gcc-specs-stack-check doesn't check the user added flags.
ping?
From the devaway ;) tomwij I am taking a break from Gentoo. I don't think I'm ready to retire, but I think I need a break to decide. Still present to talk if you can catch me... @ 2014/09/10 12:28Z
(In reply to Anthony Basile from comment #11) > yellow vlc # diff -Naur vlc-2.1.2.ebuild vlc-2.1.2-r1.ebuild > [...] > > Can we get this in soon so we can remove this blocker to gcc-4.8. > Alternatively we can just drop it as a blocker since only hardened adds > -fstack-check to the specs now. > > One caveat. This will bite anyone who adds -fstack-check manually since > gcc-specs-stack-check doesn't check the user added flags. Go ahead; for -fstack-check, you can use toolchain-funcs to remove it.
(In reply to Anthony Basile from comment #11) why does the spec matter ? why not just always append -fno-stack-check ? it'd be simpler and less error prone.
It would be nice if you included your configure and build log as well.
Sorry, wrong bug. ;)
fixed, pushed to portage tree, thanks Pawel and @all
(In reply to SpanKY from comment #15) > (In reply to Anthony Basile from comment #11) > > why does the spec matter ? why not just always append -fno-stack-check ? > it'd be simpler and less error prone. But I'm being stupid. This is better. (In reply to Yixun Lan from comment #18) > fixed, pushed to portage tree, thanks Pawel and @all It went in as use x86 && append-cflags $(test-flags-CC -fno-stack-check) which is good. Thanks.