[OE-core] [PATCH 4/5] libav: upgrade to 9.18

[Paul Eggleton]

On Friday 29 May 2015 09:36:28 Kang Kai wrote:
> On 2015年05月28日 16:47, Martin Jansa wrote:
> > On Thu, May 28, 2015 at 04:18:24PM +0800, Kang Kai wrote:
> >> On 2015年05月28日 15:14, Jussi Kukkonen wrote:
> >>> On 28 May 2015 at 04:26, Kai Kang <kai.kang at windriver.com> wrote:
> >>>> Upgrade libav from version 9.16 to 9.18. Remove unused var INC_PR and
> >>>> backport patch to fix CVE-2014-9676.
> >>> 
> >>> I'm sorry I didn't ask this in the original discussion but... Is there
> >>> a good reason for keeping 9.x in oe-core if we're bringing in 11.x
> >>> (instead of either dropping 9.x or moving it to meta-oe)?
> >>> 
> >>> I haven't found the API changes between 9 and 11 to be so large that
> >>> they would warrant keeping two versions. Admittedly I'm not working
> >>> with libav on daily basis so I might have missed things.
> >> 
> >> The original thought is just in case someone may want libav 9. According
> >> to release log, series 11
> >> is
> >> 
> >> "Libav 11 is API-, but not ABI-compatible with the previous major
> >> release."
> >> 
> >> So it is ok for us to use libav 11 as default. libav 9 recipe could be
> >> removed if no one opposes.
> >> 
> >> Ref:
> >> https://libav.org/releases/libav-11.3.release
> > 
> > Does libav-11 show the same textrel issues? If it's fixed there I'm in
> > favor of dropping libav-9.
> > 
> > from last world build:
> > gstreamer1.0-libav-1.4.5: ELF binary
> > '/tmp/work/armv5e-oe-linux-gnueabi/gstreamer1.0-libav/1.4.5-r0/packages-s
> > plit/gstreamer1.0-libav/usr/lib/gstreamer-1.0/libgstlibav.so' has
> > relocations in .text [textrel] gstreamer1.0-libav-1.4.5: ELF binary
> > '/tmp/work/i586-oe-linux/gstreamer1.0-libav/1.4.5-r0/packages-split/gstre
> > amer1.0-libav/usr/lib/gstreamer-1.0/libgstlibav.so' has relocations in
> > .text [textrel] libav-9.16: ELF binary
> > '/tmp/work/armv5e-oe-linux-gnueabi/libav/9.16-r0/packages-split/libavcode
> > c/usr/lib/libavcodec.so.54.35.0' has relocations in .text [textrel]
> > libav-9.16: ELF binary
> > '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavcodec/usr/lib/
> > libavcodec.so.54.35.0' has relocations in .text [textrel] libav-9.16: ELF
> > binary
> > '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavdevice/usr/lib
> > /libavdevice.so.53.2.0' has relocations in .text [textrel] libav-9.16: ELF
> > binary
> > '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavfilter/usr/lib
> > /libavfilter.so.3.3.0' has relocations in .text [textrel] libav-9.16: ELF
> > binary
> > '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavformat/usr/lib
> > /libavformat.so.54.20.4' has relocations in .text [textrel] libav-9.16:
> > ELF binary
> > '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavresample/usr/l
> > ib/libavresample.so.1.0.1' has relocations in .text [textrel] libav-9.16:
> > ELF binary
> > '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libavutil/usr/lib/l
> > ibavutil.so.52.3.0' has relocations in .text [textrel] libav-9.16: ELF
> > binary
> > '/tmp/work/i586-oe-linux/libav/9.16-r0/packages-split/libswscale/usr/lib/
> > libswscale.so.2.1.1' has relocations in .text [textrel]
> > libpostproc-52.3.0+gitAUTOINC+811db3b957: ELF binary
> > '/tmp/work/armv5te-oe-linux-gnueabi/libpostproc/52.3.0+gitAUTOINC+811db3b
> > 957-r0/packages-split/libpostproc/usr/lib/libpostproc.so.52.3.0' has
> > relocations in .text [textrel] libpostproc-52.3.0+gitAUTOINC+811db3b957:
> > ELF binary
> > '/tmp/work/i586-oe-linux/libpostproc/52.3.0+gitAUTOINC+811db3b957-r0/pack
> > ages-split/libpostproc/usr/lib/libpostproc.so.52.3.0' has relocations in
> > .text [textrel]
>
> No, the textrel issue is not fixed in version 11.3 either. It has an
> configure option '--enable-pic' but seems doesn't work.
> x86 has same warnings and it just skips the textrel check in the libav
> recipe.

Just for background, the reason I disabled the textrel check for x86 in 
libav.inc was that I was able to determine based on quick research that 
upstream deliberately doesn't enable -fPIC for x86 (32-bit) because apparently 
it doesn't really work there. I honestly didn't check what the situation was 
on 32-bit ARM; I probably should have done that at the time.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre