@@ -0,0 +1,56 @@+Upstream-Status: Backport++Backport patch to fix CVE-2014-3564.++http://git.gnupg.org/cgi-bin/gitweb.cgi?p=gpgme.git;a=commit;h=2cbd76f7911fc215845e89b50d6af5ff4a83dd77++Signed-off-by: Kai Kang <kai.kang@windriver.com>+---+From 2cbd76f7911fc215845e89b50d6af5ff4a83dd77 Mon Sep 17 00:00:00 2001+From: Werner Koch <wk@gnupg.org>+Date: Wed, 30 Jul 2014 11:04:55 +0200+Subject: [PATCH 1/1] Fix possible realloc overflow for gpgsm and uiserver+engines.++After a realloc (realloc is also used for initial alloc) the allocated+size if the buffer is not correctly recorded. Thus an overflow can be+introduced by receiving data with different line lengths in a specific+order. This is not easy exploitable because libassuan constructs the+line. However a crash has been reported and thus it might be possible+to constructs an exploit.++CVE-id: CVE-2014-3564+Reported-by: Tomáš Trnka+---+src/engine-gpgsm.c | 2 +-+src/engine-uiserver.c | 2 +-+3 files changed, 5 insertions(+), 2 deletions(-)++diff --git a/src/engine-gpgsm.c b/src/engine-gpgsm.c+index 8ec1598..3a83757 100644+--- a/src/engine-gpgsm.c++++ b/src/engine-gpgsm.c+@@ -836,7 +836,7 @@ status_handler (void *opaque, int fd)+ else+ {+ *aline = newline;+- gpgsm->colon.attic.linesize += linelen + 1;++ gpgsm->colon.attic.linesize = *alinelen + linelen + 1;+ }+ }+ if (!err)+diff --git a/src/engine-uiserver.c b/src/engine-uiserver.c+index 2738c36..a7184b7 100644+--- a/src/engine-uiserver.c++++ b/src/engine-uiserver.c+@@ -698,7 +698,7 @@ status_handler (void *opaque, int fd)+ else+ {+ *aline = newline;+- uiserver->colon.attic.linesize += linelen + 1;++ uiserver->colon.attic.linesize = *alinelen + linelen + 1;+ }+ }+ if (!err)+-- +2.1.4
Backport patch to fix CVE-2015-1345. The issue was introduced with
v2.18-90-g73893ff, and version 2.5.1a is not affected.
Replace tab with spaces in SRC_URI as well.
Signed-off-by: Kai Kang <redacted>
---
.../grep/grep/grep-fix-CVE-2015-1345.patch | 154 +++++++++++++++++++++
meta/recipes-extended/grep/grep_2.21.bb | 3 +-
2 files changed, 156 insertions(+), 1 deletion(-)
create mode 100644 meta/recipes-extended/grep/grep/grep-fix-CVE-2015-1345.patch
@@ -0,0 +1,154 @@+Upstream-Status: Backport++Backport patch to fix CVE-2015-1345.+http://git.savannah.gnu.org/cgit/grep.git/commit/?id=83a95bd++Signed-off-by: Kai Kang <kai.kang@windriver.com>+---+From 83a95bd8c8561875b948cadd417c653dbe7ef2e2 Mon Sep 17 00:00:00 2001+From: Yuliy Pisetsky <ypisetsky@fb.com>+Date: Thu, 1 Jan 2015 15:36:55 -0800+Subject: [PATCH] grep -F: fix a heap buffer (read) overrun++grep's read buffer is often filled to its full size, except when+reading the final buffer of a file. In that case, the number of+bytes read may be far less than the size of the buffer. However, for+certain unusual pattern/text combinations, grep -F would mistakenly+examine bytes in that uninitialized region of memory when searching+for a match. With carefully chosen inputs, one can cause grep -F to+read beyond the end of that buffer altogether. This problem arose via+commit v2.18-90-g73893ff with the introduction of a more efficient+heuristic using what is now the memchr_kwset function. The use of+that function in bmexec_trans could leave TP much larger than EP,+and the subsequent call to bm_delta2_search would mistakenly access+beyond end of the main input read buffer.++* src/kwset.c (bmexec_trans): When TP reaches or exceeds EP,+do not call bm_delta2_search.+* tests/kwset-abuse: New file.+* tests/Makefile.am (TESTS): Add it.+* THANKS.in: Update.+* NEWS (Bug fixes): Mention it.++Prior to this patch, this command would trigger a UMR:++ printf %0360db 0 | valgrind src/grep -F $(printf %019dXb 0)++ Use of uninitialised value of size 8+ at 0x4142BE: bmexec_trans (kwset.c:657)+ by 0x4143CA: bmexec (kwset.c:678)+ by 0x414973: kwsexec (kwset.c:848)+ by 0x414DC4: Fexecute (kwsearch.c:128)+ by 0x404E2E: grepbuf (grep.c:1238)+ by 0x4054BF: grep (grep.c:1417)+ by 0x405CEB: grepdesc (grep.c:1645)+ by 0x405EC1: grep_command_line_arg (grep.c:1692)+ by 0x4077D4: main (grep.c:2570)++See the accompanying test for how to trigger the heap buffer overrun.++Thanks to Nima Aghdaii for testing and finding numerous+ways to break early iterations of this patch.+---+NEWS | 5 ++++++THANKS.in | 1 ++src/kwset.c | 2 +++tests/Makefile.am | 1 ++tests/kwset-abuse | 32 +++++++++++++++++++++++++++++++++5 files changed, 41 insertions(+)+create mode 100755 tests/kwset-abuse++diff --git a/NEWS b/NEWS+index 975440d..3835d8d 100644+--- a/NEWS++++ b/NEWS+@@ -2,6 +2,11 @@ GNU grep NEWS -*- outline -*-++* Noteworthy changes in release ?.? (????-??-??) [?]+++** Bug fixes++++ grep no longer reads from uninitialized memory or from beyond the end++ of the heap-allocated input buffer.++++* Noteworthy changes in release 2.21 (2014-11-23) [stable]++diff --git a/THANKS.in b/THANKS.in+index aeaf516..624478d 100644+--- a/THANKS.in++++ b/THANKS.in+@@ -62,6 +62,7 @@ Michael Aichlmayr mikla@nx.com+Miles Bader miles@ccs.mt.nec.co.jp+Mirraz Mirraz mirraz1@rambler.ru+Nelson H. F. Beebe beebe@math.utah.edu++Nima Aghdaii naghdaii@fb.com+Olaf Kirch okir@ns.lst.de+Paul Kimoto kimoto@spacenet.tn.cornell.edu+Péter Radics mitchnull@gmail.com+diff --git a/src/kwset.c b/src/kwset.c+index 4003c8d..376f7c3 100644+--- a/src/kwset.c++++ b/src/kwset.c+@@ -643,6 +643,8 @@ bmexec_trans (kwset_t kwset, char const *text, size_t size)+ if (! tp)+ return -1;+ tp++;++ if (ep <= tp)++ break;+ }+ }+ }+diff --git a/tests/Makefile.am b/tests/Makefile.am+index 2cba2cd..0508cd2 100644+--- a/tests/Makefile.am++++ b/tests/Makefile.am+@@ -75,6 +75,7 @@ TESTS = \+ inconsistent-range \+ invalid-multibyte-infloop \+ khadafy \++ kwset-abuse \+ long-line-vs-2GiB-read \+ match-lines \+ max-count-overread \+diff --git a/tests/kwset-abuse b/tests/kwset-abuse+new file mode 100755+index 0000000..6d8ec0c+--- /dev/null++++ b/tests/kwset-abuse+@@ -0,0 +1,32 @@++#! /bin/sh++# Evoke a segfault in a hard-to-reach code path of kwset.c.++# This bug affected grep versions 2.19 through 2.21.++#++# Copyright (C) 2015 Free Software Foundation, Inc.++#++# This program is free software: you can redistribute it and/or modify++# it under the terms of the GNU General Public License as published by++# the Free Software Foundation, either version 3 of the License, or++# (at your option) any later version.++++# This program is distributed in the hope that it will be useful,++# but WITHOUT ANY WARRANTY; without even the implied warranty of++# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the++# GNU General Public License for more details.++++# You should have received a copy of the GNU General Public License++# along with this program. If not, see <http://www.gnu.org/licenses/>.++++. "${srcdir=.}/init.sh"; path_prepend_ ../src++++fail=0++++# This test case chooses a haystack of size 260,000, since prodding++# with gdb showed a reallocation slightly larger than that in fillbuf.++# To reach the buggy code, the needle must have length < 1/11 that of++# the haystack, and 10,000 is a nice round number that fits the bill.++printf '%0260000dXy\n' 0 | grep -F $(printf %010000dy 0)++++test $? = 1 || fail=1++++Exit $fail+-- +2.4.1+
@@ -0,0 +1,39 @@+Upstream-Status: Backport++Backport patch to fix CVE-2015-1860++http://code.qt.io/cgit/qt/qt.git/commit/?id=9f2425a++Signed-off-by: Kai Kang <kai.kang@windriver.com>+---+From a1cf194c54be57d6ab55dfd26b9562a60532208e Mon Sep 17 00:00:00 2001+From: Eirik Aavitsland <eirik.aavitsland@theqtcompany.com>+Date: Wed, 11 Mar 2015 09:00:41 +0100+Subject: [PATCH] Fixes crash in gif image decoder++Fuzzing test revealed that for certain malformed gif files,+qgifhandler would segfault.++Change-Id: I5bb6f60e1c61849e0d8c735edc3869945e5331c1+(cherry picked from qtbase/ea2c5417fcd374302f5019e67f72af5facbd29f6)+Reviewed-by: Richard J. Moore <rich@kde.org>+---+src/gui/image/qgifhandler.cpp | 2 +++1 file changed, 2 insertions(+)++diff --git a/src/gui/image/qgifhandler.cpp b/src/gui/image/qgifhandler.cpp+index 5199dd3..49aa2a6 100644+--- a/src/gui/image/qgifhandler.cpp++++ b/src/gui/image/qgifhandler.cpp+@@ -944,6 +944,8 @@ void QGIFFormat::fillRect(QImage *image, int col, int row, int w, int h, QRgb co++void QGIFFormat::nextY(unsigned char *bits, int bpl)+{++ if (out_of_bounds)++ return;+ int my;+ switch (interlace) {+ case 0: // Non-interlaced+-- +2.4.1+
Add recipe for libav 11 release series. According to release log,
"Libav 11 is API-, but not ABI-compatible with the previous major
release."
So make series 11 as default recipe.
Signed-off-by: Kai Kang <redacted>
---
meta/recipes-multimedia/libav/libav_11.3.bb | 4 ++++
1 file changed, 4 insertions(+)
create mode 100644 meta/recipes-multimedia/libav/libav_11.3.bb
From: Jussi Kukkonen <hidden> Date: 2015-05-28 07:14:55
On 28 May 2015 at 04:26, Kai Kang [off-list ref] 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.
Jussi
On 28 May 2015 at 04:26, Kai Kang [off-list ref] wrote:
quoted
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
--Kai
From: Jussi Kukkonen <hidden> Date: 2015-05-28 08:38:45
On 28 May 2015 at 11:18, Kang Kai [off-list ref] wrote:
On 2015年05月28日 15:14, Jussi Kukkonen wrote:
quoted
On 28 May 2015 at 04:26, Kai Kang [off-list ref] wrote:
quoted
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."
For full disclosure, libav 10 is not API-compatible with 9: the
differences aren't big but will certainly require changes in some
applications. Still, I haven't seen anything that would necessitate
keeping two versions.
- Jussi
So it is ok for us to use libav 11 as default. libav 9 recipe could be
removed if no one opposes.
From: Martin Jansa <hidden> Date: 2015-05-28 08:46:45
On Thu, May 28, 2015 at 04:18:24PM +0800, Kang Kai wrote:
On 2015年05月28日 15:14, Jussi Kukkonen wrote:
quoted
On 28 May 2015 at 04:26, Kai Kang [off-list ref] wrote:
quoted
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-split/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/gstreamer1.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/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/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/lib/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/libavutil.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+811db3b957-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/packages-split/libpostproc/usr/lib/libpostproc.so.52.3.0' has relocations in .text [textrel]
On Thu, May 28, 2015 at 04:18:24PM +0800, Kang Kai wrote:
quoted
On 2015年05月28日 15:14, Jussi Kukkonen wrote:
quoted
On 28 May 2015 at 04:26, Kai Kang [off-list ref] wrote:
quoted
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-split/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/gstreamer1.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/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/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/lib/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/libavutil.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+811db3b957-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/packages-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.
--Kai
From: Paul Eggleton <hidden> Date: 2015-05-29 15:28:08
On Friday 29 May 2015 09:36:28 Kang Kai wrote:
On 2015年05月28日 16:47, Martin Jansa wrote:
quoted
On Thu, May 28, 2015 at 04:18:24PM +0800, Kang Kai wrote:
quoted
On 2015年05月28日 15:14, Jussi Kukkonen wrote:
quoted
On 28 May 2015 at 04:26, Kai Kang [off-list ref] wrote:
quoted
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
From: Phil Blundell <hidden> Date: 2015-05-29 22:24:40
On Fri, 2015-05-29 at 16:28 +0100, Paul Eggleton wrote:
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.
PIC is particularly problematic on x86 because it ties up %ebx. This
represents 25% of the available general purpose registers which can
cause a measurable performance loss because of increased spilling, and
in the particular case of libav there is a lot of hand-written assembly
in the codecs which expects to be able to clobber that register. It
certainly used to be the case that this code wouldn't compile at all
under -fpic.
The performance thing does apply to ARM as well but to a slightly lesser
extent. The second problem probably doesn't affect ARM at all. But,
personally, I would disable the textrel check and build without -fpic on
all platforms.
p.
From: Bernhard Reutner-Fischer <hidden> Date: 2015-05-30 13:17:46
On May 30, 2015 12:24:30 AM GMT+02:00, Phil Blundell [off-list ref] wrote:
On Fri, 2015-05-29 at 16:28 +0100, Paul Eggleton wrote:
quoted
Just for background, the reason I disabled the textrel check for x86
in
quoted
libav.inc was that I was able to determine based on quick research
that
quoted
upstream deliberately doesn't enable -fPIC for x86 (32-bit) because
apparently
quoted
it doesn't really work there. I honestly didn't check what the
situation was
quoted
on 32-bit ARM; I probably should have done that at the time.
PIC is particularly problematic on x86 because it ties up %ebx. This
represents 25% of the available general purpose registers which can
cause a measurable performance loss because of increased spilling, and