Update of the VP8 SDK. I just bumped the current 0.9.7-r1.ebuild to 1.0.0 and it compiles and works (tested with ffmpeg). Reproducible: Always Actual Results: compiles and works
Mozilla team will need 1.0.0 for fx/tb-11 sooner we can get this landed sooner we will be able to keep things rolling.
checking for vpx/vpx_decoder.h... yes checking for vpx_codec_dec_init_ver in -lvpx... yes checking for libvpx version >= v0.9.7... no configure: error: --with-system-libvpx requested but it is not v0.9.7 or later *** Fix above errors and then restart with "make -f client.mk build" make[2]: *** [configure] Error 1 make[2]: Leaving directory `/build/portage/www-client/firefox-10.0.1/work/mozilla-release' make[1]: *** [obj-x86_64-unknown-linux-gnu/Makefile] Error 2 make[1]: Leaving directory `/build/portage/www-client/firefox-10.0.1/work/mozilla-release' make: *** [build] Error 2 emake failed * ERROR: www-client/firefox-10.0.1 failed (compile phase): looks like it's not just a trivial bump as FF10 / TB10 don't pick it up
(In reply to comment #2) > checking for vpx/vpx_decoder.h... yes > checking for vpx_codec_dec_init_ver in -lvpx... yes > checking for libvpx version >= v0.9.7... no > configure: error: --with-system-libvpx requested but it is not v0.9.7 or later > *** Fix above errors and then restart with "make -f client.mk > build" > make[2]: *** [configure] Error 1 > make[2]: Leaving directory > `/build/portage/www-client/firefox-10.0.1/work/mozilla-release' > make[1]: *** [obj-x86_64-unknown-linux-gnu/Makefile] Error 2 > make[1]: Leaving directory > `/build/portage/www-client/firefox-10.0.1/work/mozilla-release' > make: *** [build] Error 2 > emake failed > * ERROR: www-client/firefox-10.0.1 failed (compile phase): > > looks like it's not just a trivial bump as FF10 / TB10 don't pick it up That's a known bug in FF10. FF10 looks hard coded for libvpx.so.0, which is now libvpx.so.1. There is already a link from /usr/lib64/libvpx.so -> libvpx.so.1.0.0, so FF10 should search for libvpx.so and not libvpx.so.0
(In reply to comment #3) > That's a known bug in FF10. FF10 looks hard coded for libvpx.so.0, which is now No, it doesn't. It merely adds the flags "-L${LIBVPX_DIR}/lib -lvpx" (search for MOZ_LIBVPX_LIBS in configure.in) to enable --with-system-libvpx. This really is a known bug, though, specifically https://bugzilla.mozilla.org/show_bug.cgi?id=722127 FF is checking header files for a version-specific #define (because libvpx provided no way, prior to the 1.0.0 soname bump, to check for a specific version at link time, so checking at compile time was the next best option). Unfortunately, the #define it was checking was renamed in 1.0.0, breaking the API. The _reason_ for the version check (and the reason the check was bumped to 1.0.0 in FF11) have nothing to do with the #define itself, but are due to unpatched crash vulnerabilities triggered by web content in older versions of libvpx (in the case of https://bugzilla.mozilla.org/show_bug.cgi?id=696390, even non-malicious content could cause a crash when seeking). FF10 and later include patches in its internal copy of v0.9.7-p1 for these bugs, but Gentoo is still shipping an unpatched version. If we're not going to do the work to keep up with libvpx vulnerabilities (at a minimum, scanning media/libvpx/update.sh in FF for patches to ensure we include those already fixed in FF, though in this case upgrading to 1.0.0 would also work), we shouldn't be using --with-system-libvpx.
1.0.0 in tree
(In reply to comment #5) > 1.0.0 in tree Care to comment on why keywords were drop'd?
(In reply to comment #6) > (In reply to comment #5) > > 1.0.0 in tree > > Care to comment on why keywords were drop'd? my mistake, sorry, i copied -9999 where they hadnt been added :(
