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.k...@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 -- _______________________________________________ Openembedded-core mailing list Openembedded-core@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-core