emerge mplayer fails with: x86_64-pc-linux-gnu-gcc -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -O2 -pipe -march=core2 -D__STDC_LIMIT_MACROS -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/X11R6/include -I/usr/include/SDL -D_REENTRANT -Ilibdvdread4 -I/usr/include/freetype2 -I/usr/include/schroedinger-1.0 -I/usr/include/liboil-0.3 -Ilibdvdnav -Ilibfaad2 -D_GNU_SOURCE -DHAVE_CONFIG_H -c -o libfaad2/drc.o libfaad2/drc.c libfaad2/cfft.c:1001: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.gentoo.org/> for instructions. make: *** [libfaad2/cfft.o] Error 1 make: *** Waiting for unfinished jobs.... libfaad2/decoder.c: In function 'NeAACDecInit': libfaad2/decoder.c:255: warning: passing argument 2 of 'NeAACDecInit2' from incompatible pointer type * * ERROR: media-video/mplayer-20090226.28734-r1 failed. * Call stack: * ebuild.sh, line 49: Called src_compile * environment, line 2999: Called die * The specific snippet of code: * emake || die "Failed to build MPlayer!"; * The die message: * Failed to build MPlayer! * * If you need support, post the topmost build error, and the call stack if relevant. * A complete build log is located at '/var/tmp/portage/media-video/mplayer-20090226.28734-r1/temp/build.log'. * The ebuild environment file is located at '/var/tmp/portage/media-video/mplayer-20090226.28734-r1/temp/environment'. Reproducible: always
Created attachment 185085 [details] build.log
Created attachment 185086 [details] emerge --info
I can confirm the save error on my system (amd64)
I have the exact same error on ~x86
Just the same error too.
This is bug of gcc-4.3.3-r1 certainly. Both mplayer-20090226.28734 and mplayer-20090226.28734-r1 fails with gcc-4.3.3-r1 but gcc-4.3.3 can compile them.
Created attachment 185106 [details] Preprocessed source This is the preprocessed form of the source file which causes the problem. The compiler flag "-std=gnu99" seems to be involved as well; without that flag it compiles all right. So to reproduce this, call "i686-pc-linux-gnu-gcc -std=gnu99 -c cfft.e.c".
(In reply to comment #7) > So to reproduce this, call "i686-pc-linux-gnu-gcc > -std=gnu99 -c cfft.e.c". Same here, with x86_64-pc-linux-gnu-gcc. BTW, ./libavcodec/eatqi.c is also problematic, and the same workaround applies
*** Bug 262584 has been marked as a duplicate of this bug. ***
Same here, ~x86
*** Bug 262619 has been marked as a duplicate of this bug. ***
*** Bug 262618 has been marked as a duplicate of this bug. ***
seems to be caused by 69_all_gcc43-pr39013.patch you should be able to work around by doing: GENTOO_PATCH_EXCLUDE="69_all_gcc43-pr39013.patch" emerge gcc
*** Bug 262627 has been marked as a duplicate of this bug. ***
*** Bug 262634 has been marked as a duplicate of this bug. ***
you're trying to build mplayer with an pie compiler ? this has failed for me like forever ;)
(In reply to comment #13) > seems to be caused by 69_all_gcc43-pr39013.patch Yes, the patch is broken. Just as I wanted to write details about this, I found that SpanKY came to the same conclusion in bug 254355 comment 25.
*** Bug 262646 has been marked as a duplicate of this bug. ***
*** Bug 262643 has been marked as a duplicate of this bug. ***
(In reply to comment #13) > seems to be caused by 69_all_gcc43-pr39013.patch > > you should be able to work around by doing: > GENTOO_PATCH_EXCLUDE="69_all_gcc43-pr39013.patch" emerge gcc Confirmed. No ICE when compiling ffmpeg and mplayer with gcc-4.3.3-r1 having that patch backed out.
Hane added a new patch for #254355 and i hope it works this time.
*** Bug 262657 has been marked as a duplicate of this bug. ***
*** Bug 262738 has been marked as a duplicate of this bug. ***
I've tested new patch from #254355 BEFORE PATCH: twolame: /bin/sh ../libtool --tag=CC --mode=compile x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../build -I ../build/ -march=native -O2 -pipe -std=c99 -Wunused -Wall -MT encode.lo -MD -MP -MF .deps/encode.Tpo -c -o encode.lo encode.c x86_64-pc-linux-gnu-gcc -DHAVE_CONFIG_H -I. -I../build -I ../build/ -march=native -O2 -pipe -std=c99 -Wunused -Wall -MT crc.lo -MD -MP -MF .deps/crc.Tpo -c crc.c -fPIC -DPIC -o .libs/crc.o encode.c:1305: internal compiler error: Segmentation fault crc.c:83: internal compiler error: Segmentation fault mplayer: x86_64-pc-linux-gnu-gcc -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -march=x86-64 -mtune=generic -pipe -ffast-math -fomit-frame-pointer -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/include/directfb -I/usr/X11R6/include -I/usr/include/ -I/usr/include/SDL -D_REENTRANT -D_REENTRANT -Ilibdvdread4 -I/usr/include/freetype2 -I/usr/include/dirac -I/usr/include/schroedinger-1.0 -I/usr/include/liboil-0.3 -Ilibdvdnav -Ilibfaad2 -D_GNU_SOURCE -DHAVE_CONFIG_H -c -o libfaad2/cfft.o libfaad2/cfft.c libfaad2/cfft.c:1001: internal compiler error: Segmentation fault with NEW patch from #254355 everything compiles ok. Rob
Confirming error on 2 systems. One is ~x86 and other is ~amd64. I get the same build issue with ffmpeg 0.5-r1 on the ~x86 system. Reverting to gcc-4.3.3 resolves the issue
*** Bug 262767 has been marked as a duplicate of this bug. ***
The same with media-sound/twolame
Same here (~ppc64) powerpc64-unknown-linux-gnu-gcc -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -pipe -ffast-math -fomit-frame-pointer -maltivec -mabi=altivec -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/X11R6/include -I/usr/inc lude/SDL -D_REENTRANT -Ilibdvdread4 -I/usr/include/freetype2 -I/usr/include/dirac -I/usr/include/schroedinger-1.0 -I/usr/include/liboil-0.3 -I/usr/include/gtk-2.0 -I/usr/ lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/inc lude/freetype2 -I/usr/include/libpng12 -Ilibdvdnav -Ilibfaad2 -D_GNU_SOURCE -DHAVE_CONFIG_H -c -o libfaad2/bits.o libfaad2/bits.c powerpc64-unknown-linux-gnu-gcc -Wundef -Wdisabled-optimization -Wno-pointer-sign -Wdeclaration-after-statement -std=gnu99 -Wall -Wno-switch -Wpointer-arith -Wredundant-decls -O4 -pipe -ffast-math -fomit-frame-pointer -maltivec -mabi=altivec -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE64_SOURCE -I. -I/usr/X11R6/include -I/usr/include/SDL -D_REENTRANT -Ilibdvdread4 -I/usr/include/freetype2 -I/usr/include/dirac -I/usr/include/schroedinger-1.0 -I/usr/include/liboil-0.3 -I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/libpng12 -Ilibdvdnav -Ilibfaad2 -D_GNU_SOURCE -DHAVE_CONFIG_H -c -o libfaad2/cfft.o libfaad2/cfft.c libfaad2/cfft.c:1001: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://bugs.gentoo.org/> for instructions. make: *** [libfaad2/cfft.o] Error 1
I guess we don't need any more confirmations. The issue is well understood and bug 254355 comment 29 already has a solution waiting for inclusion. You might vote for either bug instead, if you wish to take some action. Someone with sufficient privileges might make this bug here depend on (the reopened) bug 254355, as that's what we are waiting for.
*** Bug 262782 has been marked as a duplicate of this bug. ***
*** Bug 262790 has been marked as a duplicate of this bug. ***
http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-devel/gcc/gcc-4.3.3-r1.ebuild?r1=1.1&r2=1.2 IOW, resyncing and re-emerging gcc will clear this bug provisionally.
Why this error is corrected without increasing the version number?
agreed. There should be a revbump for this fix.
(In reply to comment #32) > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-devel/gcc/gcc-4.3.3-r1.ebuild?r1=1.1&r2=1.2 > > IOW, resyncing and re-emerging gcc will clear this bug provisionally. > Why do you want to disable this patch rather than use corrected one? I've tested new patch from bug #254355 and it works fine (comment #24) R
(In reply to comment #35) > (In reply to comment #32) > > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-devel/gcc/gcc-4.3.3-r1.ebuild?r1=1.1&r2=1.2 > > > > IOW, resyncing and re-emerging gcc will clear this bug provisionally. > > > > Why do you want to disable this patch rather than use corrected one? I've > tested new patch from bug #254355 and it works fine (comment #24) Just to be clear, that commit was by Vapier. I imagine he'll use the correct patch once he's sure it's safe. As to why not yet, time-management issues probably come into play. For now, this bug has a work-around and will be fixed correctly when time permits. FYI, running the GCC test-suite can take quite a long time on some architectures.
*** Bug 262807 has been marked as a duplicate of this bug. ***
*** Bug 263076 has been marked as a duplicate of this bug. ***
*** Bug 263092 has been marked as a duplicate of this bug. ***
*** Bug 263220 has been marked as a duplicate of this bug. ***
(In reply to comment #32) > http://sources.gentoo.org/viewcvs.py/gentoo-x86/sys-devel/gcc/gcc-4.3.3-r1.ebuild?r1=1.1&r2=1.2 > > IOW, resyncing and re-emerging gcc will clear this bug provisionally. > Confirmed - just re-emerging gcc fixed this bug for me.
bug 263577 is possibly duplicate
*** Bug 263577 has been marked as a duplicate of this bug. ***
*** Bug 263605 has been marked as a duplicate of this bug. ***
*** Bug 263616 has been marked as a duplicate of this bug. ***
*** Bug 263677 has been marked as a duplicate of this bug. ***
*** Bug 263816 has been marked as a duplicate of this bug. ***
*** Bug 263821 has been marked as a duplicate of this bug. ***
*** Bug 263825 has been marked as a duplicate of this bug. ***
*** Bug 263855 has been marked as a duplicate of this bug. ***
I have the exact same error on ~amd64
Since re-emerging gcc fixes this, given the number of people running into the issue a bump to -r2 to force a rebuild of gcc is appropriate?
*** Bug 263850 has been marked as a duplicate of this bug. ***
(In reply to comment #52) > Since re-emerging gcc fixes this, given the number of people running into the > issue a bump to -r2 to force a rebuild of gcc is appropriate? > Absolutely. Now let's try to convince the gcc maintainers...
what amazes me is how many people don't know how to do a simple bug search.
The summary is to blame, not the users. If anything, they should be thanked for reporting.
*** Bug 263957 has been marked as a duplicate of this bug. ***
*** Bug 263995 has been marked as a duplicate of this bug. ***
+*gcc-4.3.3-r2 (27 Mar 2009) + + 27 Mar 2009; Peter Alfredsen <loki_val@gentoo.org> -gcc-4.3.3-r1.ebuild, + +gcc-4.3.3-r2.ebuild: + Revbump with broken patch disabled to stop duplicates of bug 262567 from + flowing in. Bug wranglers know this bug by heart now. +
At last, rev-bumped. Btw, maybe all those duplicates are not the user's inability to search, but their ability to tell you "please *always* rev-bump fixes that are not build-related to the package itself" :P
*** Bug 264076 has been marked as a duplicate of this bug. ***
I think the reason why there are so many duplicates of this bug is because many people don't know what ICE is or they are trying to compile a different version from the one in the summary and assume this is an old error.
(In reply to comment #62) > I think the reason why there are so many duplicates of this bug is because many > people don't know what ICE is or they are trying to compile a different version > from the one in the summary and assume this is an old error. > I can't agree. This bug is seventh-newest in the search results for "mplayer", and two of the newer six are for different packages. Checking a good handful (if not all) of the newest bugs for the affected package-name and looking for error output that matches your own is just due diligence IMHO. Mind you, I would dearly love to see better indexing in bugzilla, as searching for a snatch of error output is the easiest way to find "your" bug but sadly isn't really possible (unless the output is in the summary, which in this and most cases it isn't). More on-topic, doesn't this bug also affect ffmpeg, vlc and possibly others? If I'm correct on that, perhaps this ought to be mentioned in summary?
same here, recompiling GCC without patch. wil report if it helped or not.
(In reply to comment #64) > same here, recompiling GCC without patch. wil report if it helped or not. > Update youre GCC and it will be fixed.
compiling without patch and recompiling mplayer worked out fine.
which is why gcc-4.3.3-r2 doesn't contain that patch.
The offending patch to gcc has been fixed.
(In reply to comment #68) > The offending patch to gcc has been fixed. > gcc-4.3.2-r3 Same problem with media-video/ffmpeg-0.5-r1.