Emerge of xine-lib failed at dxr3_decode_video.c:189 Reproducible: Always Steps to Reproduce: 1.emerge xine-lib 2. 3. Actual Results: dxr3_decode_video.c: In function `dxr3_open_plugin': dxr3_decode_video.c:147: sorry, unimplemented: inlining failed in call to 'dxr3_present': function body not available dxr3_decode_video.c:189: sorry, unimplemented: called from here make[3]: *** [dxr3_decode_video.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/xine-lib-1_rc5/work/xine-lib-1-rc5/src/dxr3' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/xine-lib-1_rc5/work/xine-lib-1-rc5/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/xine-lib-1_rc5/work/xine-lib-1-rc5'make: *** [all] Error 2 !!! ERROR: media-libs/xine-lib-1_rc5 failed. !!! Function src_compile, Line 128, Exitcode 2 !!! Parallel make failed Expected Results: Expected it to emerge. Portage 2.0.50-r8 (default-x86-1.4, gcc-3.4.0, glibc-2.3.4.20040605-r1, 2.6.7-rc3-love2) ================================================================= System uname: 2.6.7-rc3-love2 i686 Pentium III (Coppermine) Gentoo Base System version 1.4.16 Autoconf: sys-devel/autoconf-2.59-r4 Automake: sys-devel/automake-1.8.5-r1 ACCEPT_KEYWORDS="x86 ~x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -mtune=i686 -O2 -funroll-loops -pipe -fno-unit-at-a-time" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3.2/share/config /usr/kde/3/share/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dvipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config/ /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/bind /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -mtune=i686 -O2 -funroll-loops -pipe -fno-unit-at-a-time" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache sandbox" GENTOO_MIRRORS="ftp://ftp.ucsb.edu/pub/mirrors/linux/gentoo/ http://mirror.clarkson.edu/pub/distributions/gentoo/" MAKEOPTS="-j2" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/var/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="/usr/local/portage /usr/local/bmg-main /usr/local/bmg-gnome-current" SYNC="rsync://rsync.us.gentoo.org/gentoo-portage" USE="X alsa apm avi berkdb cdr crypt cups doc encode esd foomaticdb gdbm gif gimp gimp-print gnome gtk gtk2 imlib java jpeg libg++ libwww mad mikmod motif mozilla mpeg ncurses nls nptl oggvorbis opengl oss pam pdflib perl png python quicktime readline samba sdl slang spell ssl svga tcltk tcpd tetex truetype x86 xml2 xmms xv zlib"
drop the "-fno-unit-at-a-time" from your CFLAGS and try again.
Thanks it worked. That means don't use it for xine-lib but have to use it in order for transcode to compile would sure be nice if they would all accept the same CFlAGS.
now filtering this flag in xine-lib-1_rc5-r1
*** Bug 52380 has been marked as a duplicate of this bug. ***
Removing "-fno-unit-at-a-time" from the CFLAGS does not work with xine-lib-1_rc5-r2 it still fails with the same error. So the problem has not been fixed.
Want to add that I'm seeing this same problem with xine-lib-1_rc5-r2. However xine-lib-1_rc5-r1 two days ago compiled just fine.
Kathy and Chris, please post the header of the failed ebuild.
Requested header of failed ebuild:# $Header: /var/cvsroot/gentoo-x86/media-libs/xine-lib/xine-lib-1_rc5-r2.ebuild,v 1.8 2004/06/30 01:20:22 vapier Exp $ Also speaking of headers, I notice that there's a kernel headers patch being applied and in case it matters at all my linux-headers were at 2.6.7 when xine-lib-1_rc5-r1 was compiled but has since been upgraded to 2.6.7-r1.
Created attachment 34499 [details, diff] linux-headers-2.6.7-appCompat.patch.diff Chris, if you know how to patch, please copy sys-kernel/linux-headers to your overlay and applied the attached patch, emerge linux-headers then try again. Thanks.
Lang, I will try to figure that out later but I'm out the door right now. As a note I created a "Frankenbuild" by adding a dxr3 use flag (with an appropriate use_enable line) so that the ebuild would skip compiling the dxr3 plugin (isn't this only usable with a specific hardware device?), yet the compile croaked at: gcc -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../.. -I../../../include -I../../../include -I../../../src -I../../../src/xine-engine -I../../../src/xine-engine -I../../../src/xine-utils -I../../../src/input -I../../../src/input -DSIMPLE_IDCT -DHAVE_AV_CONFIG_H -DRUNTIME_CPUDETECT -DUSE_FASTMEMCPY -DCONFIG_RISKY -DCONFIG_DECODERS -DXINE_MPEG_ENCODER -DCONFIG_ZLIB -O3 -pipe -fomit-frame-pointer -falign-functions=4 -falign-loops=4 -falign-jumps=4 -mpreferred-stack-boundary=2 -fexpensive-optimizations -fschedule-insns2 -fno-strict-aliasing -ffast-math -funroll-loops -finline-functions -Wall -DNDEBUG -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DXINE_COMPILE -Wpointer-arith -Wnested-externs -Wcast-align -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -O2 -march=pentium4 -fomit-frame-pointer -fforce-mem -pipe -s -fno-stack-protector -fno-web -O1 -mno-sse2 -mno-sse3 -ffunction-sections -MT h263.lo -MD -MP -MF .deps/h263.Tpo -c h263.c -o .libs/h263.o h263.c: In function `mpeg4_decode_partition_a': h263.c:69: sorry, unimplemented: inlining failed in call to 'mpeg4_decode_dc': function body not available h263.c:3324: sorry, unimplemented: called from here make[5]: *** [h263.lo] Error 1
I'm not sure how to get the header for the failed ebuild but sounds like I may have the same setup as Chris so will try the patch to my linux-headers.
The patch for linux-headers did not fix the problem. How do I find the xine-lib headers that you want. Here is what I get when I try to emerge after applying the patch: dxr3_decode_video.c: In function `dxr3_open_plugin': dxr3_decode_video.c:147: sorry, unimplemented: inlining failed in call to 'dxr3_present': function body not available dxr3_decode_video.c:189: sorry, unimplemented: called from here make[3]: *** [dxr3_decode_video.lo] Error 1 make[3]: Leaving directory `/var/tmp/portage/xine-lib-1_rc5-r2/work/xine-lib-1-rc5/src/dxr3' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/xine-lib-1_rc5-r2/work/xine-lib-1-rc5/src' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/xine-lib-1_rc5-r2/work/xine-lib-1-rc5' make: *** [all] Error 2 !!! ERROR: media-libs/xine-lib-1_rc5-r2 failed. !!! Function src_compile, Line 138, Exitcode 2 !!! Parallel make failed
Ditto - same as Kathy reports - linux-headers patch does not resolve issue and error is the same as she provides. I also tried rebuilding all of the xine-lib dependencies as there's a report on the forum that this resolved the issue for someone, but that was fruitless as well in this case.
Looks to be a gcc-3.4.0 compat problem. I switched gcc-3.3.3 and all went fine.
Getting the same errors here with media-libs/xine-lib-1_rc5-r2: dxr3_decode_video.c: In function `dxr3_open_plugin': dxr3_decode_video.c:147: sorry, unimplemented: inlining failed in call to 'dxr3_present': function body not available dxr3_decode_video.c:189: sorry, unimplemented: called from here dxr3_decode_video.c: In function `dxr3_decode_data': CFLAGS here aren't too interesting, though: CFLAGS="-march=k8 -O2 -pipe"
Would still like to know about the dxr3 plug. Is there any reason to build this without the associated hardware being present or planned?
Sounds pointless to me...99%+ of people do not have these cards, and software decoding now yields higher quality output. Unfortunately this may mean another use flag for antiquated hardware (ugh)... given the obvious stats, though, it should probably me omitted by default.
gcc-3.4: open the ebuild - is-flag -O? || append-flags -O2 #31243 + is-flag -O? || append-flags -O2 #31243 I think gcc-3.4 doesn't like inline with O1
sorry, should be - is-flag -O? || append-flags -O1 #31243 + is-flag -O? || append-flags -O2 #31243
About building dxr3. There is no use-flags because there are not that many programs which would use such a flag, and those who do will autodetect if the dxr3 headers has been installed. I'm very confident that this should also happen in xine-lib. Building xine-lib 1.0-rc5 by unpacking it somewhere and compiling it the normal way works for me.
Lang, - is-flag -O? || append-flags -O1 #31243 + is-flag -O? || append-flags -O2 #31243 Works just fine here with gcc-3.4.0. Maybe it should be: - is-flag -O? || append-flags -O1 #31243 + is-flag -O? || append-flags -O2 #55202 Chris
Anders, "About building dxr3. There is no use-flags because there are not that many programs which would use such a flag" Without a use-flag it appears to get built by default yet it is a configure option. Is there some use at all for it without specific supporting hardware? Chris
Chris you are correct. There is no need to the video output driver dxr3 if you don't own a card. And it doesn't get detected automaticly. Your patch works for me :-)
Thanks Lang and Chris, the change in the following did the job. - is-flag -O? || append-flags -O1 #31243 + is-flag -O? || append-flags -O2 #55202
Works for me, too. Thanks -- perhaps it's time for a bump to -r3? And yeah, I totally agree that there is no need for a dxr(3) USE flag, as it's such an amazingly tiny portion of the userbase that would use it, and they'd get better results without the card anyways.
Created attachment 34554 [details] edited xine-lib-1_rc5-r2.ebuild This is my edited xine-lib-1_rc5-r2.ebuild, which with the proper guidance from real developers may become xine-lib-1_rc5-r3.ebuild. It works for me and has Lang's fix for gcc-3.4.0. It also introduces the drx3 use-flag. Without the flag the drx3 plugin (which nobody seems to need or desire) would be built by default as that is the normal default for the source. If it's turned off in Gentoo land without a use-flag (not built by default) than the silent minority who actually want the plugin have no way to compile it using emerge. The addition of the local drx3 use-flag means it will not be built by default (a good thing, yes?), but only when the use-flag is set. I don't see a whole lot of choice, but then again I'm not a developer or programmer, just a user.
[ "`gcc-fullversion`" == "3.4.0" ] && append-flags -fno-web #49509 ugh. that line is ugly as sin... i say we get rid of that -and- fix this bug with: if [ "`gcc-major-version`" -ge "3" -a "`gcc-minor-version`" -ge "4" ]; then append-flags -fno-web #49509 append-flags -funit-at-a-time #55202 fi and then also replace "is-flag -O? || append-flags -O1 #31243" with "replace-flags -O0 -O1 #31243" so that it doesnt FORCE -O1 when it doesnt need to.
on an unrelated note, this bug should (accent on should) be fixed in gcc 3.4.1... 14950 [non unit-at-a-time] always_inline does not mix with templates and -O0 that PR is listed as fixed.
Travis (if you read this), # gcc-config -c x86_64-pc-linux-gnu-3.4.1 dxr3_decode_video.c: In function `dxr3_open_plugin': dxr3_decode_video.c:147: sorry, unimplemented: inlining failed in call to 'dxr3_present': function body not available dxr3_decode_video.c:189: sorry, unimplemented: called from here dxr3_decode_video.c: In function `dxr3_decode_data': dxr3_decode_video.c:584: warning: long long int format, int64_t arg (arg 4) dxr3_decode_video.c:612: warning: int format, different type arg (arg 4) Thats the 'naked' ebuild for r2. With the change to the -O flag as suggested, it appears happy (didn't use the dxr flag ebuild). --- !targe sym /usr/lib/libxine.so.1 --- !targe sym /usr/lib/libxine.so * Caching service dependencies... * Caching service dependencies... >>> Auto-cleaning packages ... >>> No outdated packages were found on your system. Built. Dunno if it runs.
fixed in cvs. give it some time to reach rsync
