linux/poky.git/meta/recipes-devtools, branch krogoth-next

pseudo: Work around issues with glibc 2.24

2017-05-18T12:14:22+00:00

There are issues with a change made to RTLD_NEXT behaviour in glibc 2.24 and that change was also backported to older glibc versions in some distros like Fedora 23. This adds a workaround whilst the pseudo maintainer fixes various issues properly. (From OE-Core rev: 21c38a091c4a1917f62a942c4751b0fd11dce340) (From OE-Core rev: 47f5c2a52f93e1984b0269c708ca5218b9fd41ec) Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

pseudo: obey our LDFLAGS

2017-05-18T12:14:22+00:00

(From OE-Core rev: fc04eae73cb99d3783b09d062120a9b7dc95210a) (From OE-Core rev: 92214ca9e14d5dda1dd3e958944e96003ef77422) Signed-off-by: Christopher Larson Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

qemu: Security fix CVE-2016-4952

2017-05-18T12:14:20+00:00

affects qemu < 2.7.0 Quick Emulator(Qemu) built with the VMWARE PVSCSI paravirtual SCSI bus emulation support is vulnerable to an OOB r/w access issue. It could occur while processing SCSI commands 'PVSCSI_CMD_SETUP_RINGS' or 'PVSCSI_CMD_SETUP_MSG_RING'. A privileged user inside guest could use this flaw to crash the Qemu process resulting in DoS. References: ---------- http://www.openwall.com/lists/oss-security/2016/05/23/1 (From OE-Core rev: 3d6b4fd6bc4338b139ebcaf51b67c56cc97ba2ed) Signed-off-by: Adrian Dudau Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

qemu: Security fix CVE-2016-4439

2017-05-18T12:14:20+00:00

affects qemu < 2.7.0 Quick Emulator(Qemu) built with the ESP/NCR53C9x controller emulation support is vulnerable to an OOB write access issue. The controller uses 16-byte FIFO buffer for command and data transfer. The OOB write occurs while writing to this command buffer in routine get_cmd(). A privileged user inside guest could use this flaw to crash the Qemu process resulting in DoS. References: ---------- http://www.openwall.com/lists/oss-security/2016/05/19/4 https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2016-4441 (From OE-Core rev: 1bc071172236ea020cac9db96e33de81950a15ff) Signed-off-by: Adrian Dudau Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

binutils: apply RPATH fixes from our libtool patches

2017-05-18T12:14:19+00:00

We don't autoreconf/libtoolize binutils as it has very strict requirements, so extend our patching of the stock libtool to include two fixes to RPATH behaviour, as part of the solution to ensure that native binaries don't have RPATHs pointing at the host system's /usr/lib. This generally doesn't cause a problem but it can cause some binaries (such as ar) to abort on startup: ./x86_64-pokysdk-linux-ar: relocation error: /usr/lib/libc.so.6: symbol _dl_starting_up, version GLIBC_PRIVATE not defined in file ld-linux.so.2 with link time reference The situation here is that ar is built and as it links to the host libc/loader has an RPATH for /usr/lib. If tmp is wiped and then binutils is installed from sstate relocation occurs and the loader changed to the sysroot, but there remains a RPATH for /usr/lib. This means that the sysroot loader is used with the host libc, which can be incompatible. By telling libtool that the host library paths are in the default search path, and ensuring that all default search paths are not added as RPATHs by libtool, the result is a binary that links to what it should be linking to and nothing else. [ YOCTO #9287 ] (From OE-Core rev: 6b201081b622cc083cc2b1a8ad99d6f7d2bea480) (From OE-Core rev: 29ddf96f8db2ac8d1aabbac21514ab3865603dcd) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

binutils: fix typo in libtool patch

2017-05-18T12:14:19+00:00

There was a clear typo in a function name, correct it. (From OE-Core rev: dcf44e184a807d76463a3bf1b2315e80b9469de3) (From OE-Core rev: 6470e50928ad330a76442541ec5d864701c7fc68) Signed-off-by: Ross Burton Signed-off-by: Richard Purdie minor fixup Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

Revert "file: update SRCREV for 5.25 to fix fetch fail on missing commit"

2017-03-21T22:39:25+00:00

This reverts commit b35225c88ff681a4a903f7fb4612ac768214f539. Upstream restored the original hashes. Signed-off-by: Richard Purdie

file: update SRCREV for 5.25 to fix fetch fail on missing commit

2017-03-20T13:59:38+00:00

Machines that cloned a while ago will have the commit, but new deployments won't because it seems the upstream changed/rebased and the old commit ID has been garbage-collected away. Hence the fetch fails to check out the named commit ID. Both the old (gone) commit, and the "new" commit show the same dates and commit log and point at 5.25, so hopefully this is the right thing to do. A git diff of the two seems to only show a blanket uprev of CVS tags and deletion of a couple autogen'd files, and no real source changes. (From OE-Core rev: adb71e06768adadda7b69c3b5e81ca3ad67237f4) Cc: Christos Zoulas (From OE-Core rev: b35225c88ff681a4a903f7fb4612ac768214f539) Signed-off-by: Paul Gortmaker Signed-off-by: Richard Purdie Signed-off-by: Denys Dmytriyenko Signed-off-by: Richard Purdie

gcc-runtime.inc: Add CPP support for x86-64-x32 tune

2016-11-08T23:47:13+00:00

Using the following setup (as specified in yocto sample code): MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:libx32" DEFAULTTUNE_virtclass-multilib-libx32 = "x86-64-x32" We fail to compile simple CPP programs because CPP cannot find relevant header files, looking for them in a non-existing place. To fix this, we create a symlink of the name CPP expects and point it to the corresponding existing directory. [YOCTO#10354] [YOCTO#10380] (From OE-Core rev: 9f9be229040f4f9a523a1e25afd78d5c3f4efc23) (From OE-Core rev: 979b28c55c3b9b0134dbddbb09e30b9bf0db9231) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

gcc-runtime.inc: add CPP support for mips64-n32 tune

2016-11-08T23:47:13+00:00

This patch fixes the problem where the CPP compiler cannot find include files. The compiler is configured to look for the files in places that do not exist. When querying the CPP for search paths, we observe messages such as these: multilib configuration: MACHINE="qemumips64" require conf/multilib.conf MULTILIBS = "multilib:lib64 multilib:lib32" DEFAULTTUNE = "mips64-n32" DEFAULTTUNE_virtclass-multilib-lib64 = "mips64" DEFAULTTUNE_virtclass-multilib-lib32 = "mips32r2" ignoring nonexistent directory "/sysroots/mips64-n32-poky-linux-gnun32/usr/include/c++/6.2.0/mips64-poky-linux/32 single lib configuration: MACHINE="qemumips64" DEFAULTTUNE = "mips64-n32" ignoring nonexistent directory "/sysroots/mips64-n32-poky-linux-gnun32/usr/include/c++/6.2.0/mips64-poky-linux/ To fix this, create a symlink of the name CPP expects and point it to the corresponding "gnun32" directory. [YOCTO#10142] (From OE-Core rev: 55115f90f909d27599c686852e73df321ad1edff) (From OE-Core rev: fe61e95a3368d0bc0e66958d0e703b1e3c40c9bb) Signed-off-by: Juro Bystricky Signed-off-by: Richard Purdie Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie