Bug 1072129

Summary: libvpx-1.2 ABI incompatible with libvpx-1.3: missing symbols
Product: [Fedora] Fedora Reporter: Rex Dieter <rdieter>
Component: libvpxAssignee: Tom "spot" Callaway <tcallawa>
Status: CLOSED CANTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 20CC: dan, tcallawa
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-03-31 15:03:38 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Rex Dieter 2014-03-04 02:01:48 UTC
A user reported on #fedora today,

symbol lookup error: /lib64/libavcodec.so.55: undefined symbol: vpx_codec_vp9_dx_algo".

vpx_codec_vp9_dx_algo appears to be a new symbol in libvpx-1.3, not included in 1.2.  I didnt look closely yet, but if there's this one, there may be others.  Seems there may be alright:
http://upstream-tracker.org/compat_reports/libvpx/1.2.0_to_current/abi_compat_report.html

Options:
* Since you're already using a version script, consider versioning these affected symbols (won't help stuff built already, but will benefit anything built against the fixed libvpx)
* bump soname
or any other better idea you can think of.

Comment 1 Dan HorĂ¡k 2014-03-14 12:46:42 UTC
AFAIK the version script is used only on our secondary arches, primary arches use the internal buildsystem.

Comment 2 Tom "spot" Callaway 2014-03-31 15:03:38 UTC
The internal stuff builds with a version script too... so this should all be done. Upstream continues to use the versioning of the release as the soname version, so this didn't bump the major soname. This really ought to be something handled by the upstream, but since they're Google, I don't expect it to happen. Closing this CANTFIX.