Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 143597 - [Tracker] media-libs/x264-svn-20060810 incompatibilities
Summary: [Tracker] media-libs/x264-svn-20060810 incompatibilities
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: New packages (show other bugs)
Hardware: All Linux
: High major (vote)
Assignee: Marc Hildebrand (RETIRED)
URL:
Whiteboard:
Keywords: Tracker
: 143614 (view as bug list)
Depends on: 143495 143565 143593 143596 143646 143664 145343
Blocks: 157814
  Show dependency tree
 
Reported: 2006-08-11 11:39 UTC by Jakub Moc (RETIRED)
Modified: 2006-12-30 12:39 UTC (History)
9 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Moc (RETIRED) gentoo-dev 2006-08-11 11:39:48 UTC
Tracking media-libs/x264-svn-20060810 related b0rkage here.
Comment 1 Clint Silvester 2006-08-11 14:17:15 UTC
Both ffmpeg and mplayer failed to build with errors about x264 with this version.    Two bugs are already made.  Bug 143593 and Bug 143495.  Emerging the older x264-svn fixed them both for me.
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2006-08-11 16:13:47 UTC
*** Bug 143614 has been marked as a duplicate of this bug. ***
Comment 3 Jakub Moc (RETIRED) gentoo-dev 2006-08-12 05:58:43 UTC
@lu_zero: You've bumped this, so please package.mask this thing until the rest of the tree is properly fixed. Nothing compiles against it.



Comment 4 Luca Barbato gentoo-dev 2006-08-12 06:11:51 UTC
I'm about to provide a ffmpeg snapshot that requires it, there is a xine version requiring the newer ffmpeg snapshot, the mplayer snapshot requiring it is already in portage.

I'll p.mask both for now since looks like there is too much wreakage than expected

I'll try to track the packages and fix the deps if possible
Comment 5 Thomas Green 2006-08-12 07:18:37 UTC
The avidemux ebuilds don't seem to me to depend on x264-svn (directly or indirectly) and yet it does not compile after upgrading to x264-svn-20060810:

i686-pc-linux-gnu-g++ -DHAVE_CONFIG_H -I. -I. -I../..   -I/usr/include/malloc  -I.. -IADM_library -I../ADM_library  -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -march=athlon-xp -O2 -pipe -fomit-frame-pointer -O2 -falign-loops=16 -c -o ADM_x264.o ADM_x264.cpp
ADM_x264.cpp: In member function `virtual uint8_t X264EncoderCBR::init(uint32_t, uint32_t, ADM_x264Param*)':
ADM_x264.cpp:203: error: 'struct x264_param_t::<anonymous>' has no member named 'b_cbr'
ADM_x264.cpp: In member function `virtual uint8_t X264EncoderPass2::init(uint32_t, uint32_t, ADM_x264Param*)':
ADM_x264.cpp:237: error: 'struct x264_param_t::<anonymous>' has no member named 'b_cbr'
make[3]: *** [ADM_x264.o] Error 1
make[3]: *** Waiting for unfinished jobs....
make[3]: Leaving directory `/var/tmp/portage/avidemux-2.0.42-r1/work/avidemux-2.0.42/avidemux/ADM_codecs'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/avidemux-2.0.42-r1/work/avidemux-2.0.42/avidemux'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/avidemux-2.0.42-r1/work/avidemux-2.0.42'
make: *** [all] Error 2

!!! ERROR: media-video/avidemux-2.0.42-r1 failed.
Call stack:
  ebuild.sh, line 1539:   Called dyn_compile
  ebuild.sh, line 939:   Called src_compile
  avidemux-2.0.42-r1.ebuild, line 102:   Called die

ADM_x264.cpp does #include "x264.h" so shouldn't it depend on x264-svn? Or maybe I am missing something very obvious. In any case, it does seem that the bump to 20060810 has broken it.
Comment 6 Jakub Moc (RETIRED) gentoo-dev 2006-08-12 07:28:22 UTC
(In reply to comment #5)
> The avidemux ebuilds don't seem to me to depend on x264-svn (directly or
> indirectly) and yet it does not compile after upgrading to x264-svn-20060810:

Please, this is a tracker only. Comment on respective bugs for invidual ebuilds. Thanks.
Comment 7 Jakub Moc (RETIRED) gentoo-dev 2006-12-30 12:39:54 UTC
Closing this. avidemux needs to be p.masked until there's something working in the tree, not a version untouched for two years.