Summary: | media-video/vlc-2.1.2 - deinterlace/yadif_template.h: In function 'yadif_filter_line_ssse3': deinterlace/yadif_template.h:134:9: error: 'asm' operand has impossible constraints | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bertrand Jacquin <bertrand> |
Component: | Current packages | Assignee: | Paweł Stankowski <aambitny> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | aambitny, anton.kochkov, bertrand, dlan, dubnerm, hardened, lucas.yamanishi, media-video, quantheory, tka, vapier |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | x86 | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=506206 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
emerge --info |
Description
Bertrand Jacquin
2014-02-01 17:35:43 UTC
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. |