linux/poky.git/meta/recipes-devtools/gcc, branch yocto-2.3.2

gcc-common.inc: set CVE_PRODUCT to gcc

2017-08-29T10:57:27+00:00

All recipes which include this are using gcc as product name in NVD like https://nvd.nist.gov/vuln/detail/CVE-2015-5276 (From OE-Core rev: 8e1b34aab4bd390f53945789c91a69883613d778) Signed-off-by: Mikko Rapeli Signed-off-by: Ross Burton (cherry picked from commit bd6f1430334412588c143d8029be39fe814672cd) Signed-off-by: Armin Kuster Signed-off-by: Richard Purdie

bitbake.conf: Add COMPONENTS_DIR for ${STAGING_DIR}-components

2017-05-11T15:55:59+00:00

The path to where to install and find the sysroot components is used in many places. This warrants it to get its own variable. (From OE-Core rev: 70a84b525470f72339568409daf84845904e4cab) Signed-off-by: Peter Kjellerstedt Signed-off-by: Richard Purdie

recipes/*-cross recipes: ignore TARGET_ARCH sstate hash

2017-04-12T14:09:58+00:00

"yocto-compat-layer.py --machines" showed that shared packages like gcc-cross-powerpc64 have a sstate signature that depends on TUNEFLAGS. As a result, there are unnecessary rebuilds and potential conflicts in a multiconfig. That's due to the way how TARGET_ARCH is set. Richard Purdie suggested setting TARGET_ARCH[vardepvalue] as fix, which works. It would be shorter to do that in cross.bbclass instead of repeating the relevant line in different recipes, but Richard was concerned about potential side-effects in other usages of cross.bbclass. TARGET_GOARM as used in go.inc is still causing signature differences for go-cross-powerpc64 and machines b4420qds-64b and p5020ds-64b. This needs further investigation. (From OE-Core rev: 39bfa0dd3237cbca47e7fca1075d521f9d073f25) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

gcc-6.3: backport fix of check for empty string in ubsan.c

2017-04-10T22:00:43+00:00

Building gcc-cross-initial with GCC7 on the host fails due to the comparison of a pointer to an integer in ubsan_use_new_style_p, which is forbidden by ISO C++: ubsan.c:1474:23: error: ISO C++ forbids comparison between pointer and integer [-fpermissive] || xloc.file == '\0' || xloc.file[0] == '\xff' Backport the fix from upstream GCC to enable the build with GCC 7 (From OE-Core rev: 7a7fcbab0365b9501c737dbc02715be14dda72a3) Signed-off-by: Joshua Lock Signed-off-by: Richard Purdie

glibc/gcc/libgcc-initial: Delete do_build tasks for -initial

2017-04-10T22:00:43+00:00

We've had a lot of users running into RSS issues where -initial recipes were being installed into sysroots alongside their counterparts and causing overlapping files issues. In general this was through do_build dependencies. Such dependencies are bad in general and I'd encourage people to compare the taskgraphs with using a more specific dependency like do_populate_sysroot, do_image_complete or do_deploy as often the more specific dependency will result in a much cleaner build. Regardless, we don't want -initial dependencies getting in the way like this and there are cases a do_build dependency could make sense. Deleting the do_build task in these cases makes sense since this is not a build "endpoint" we'd ever want a user to use, its a behind the scenes piece of bootstrappping. Unfortunately to make this work, we need a newer bitbake version which has a bitbake bug fixed. (From OE-Core rev: 04c053d42ab05f77b2d1ca93a0fabae44073d57e) Signed-off-by: Richard Purdie

gcc-target.inc: create symlinks for gcov and gcov-tool

2017-03-17T16:53:05+00:00

Create symlinks for gcov and gcov-tool and that they can be used trivially on target. (From OE-Core rev: 5b5a506a6d81095c967304fe4ec38a4bc3dc1edd) Signed-off-by: Chen Qi Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

gcc: move cc1 binary file to package cpp.

2017-03-17T16:53:05+00:00

The file /usr/libexec/gcc/.../cc1 has been installed in package gcc instead of package cpp, because FILES statements for both packages match the cc1 binary. Move the file to package cpp and add cpp to RDEPENDS_gcc to fix the dependency. Having the cc1 binary in cpp fixes errors such as: "cpp: error trying to exec 'cc1': execvp: No such file or directory". (From OE-Core rev: 4bf84edeb6cf4ba82a21bc7ceb1da4f59d839064) Signed-off-by: Ismo Puustinen Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

gcc: Remove unused patch

2017-03-16T22:11:32+00:00

CVE-2016-4490 applied to gcc < 6.1.1, our version is 6.3 (From OE-Core rev: d8329861bf6f48f6e541a04062b8d1f373dfcd78) Signed-off-by: Jussi Kukkonen Signed-off-by: Richard Purdie

gcc-runtime: Enable libmpx for x86-64

2017-03-10T14:50:11+00:00

Intel MPX was recently enabled on x86 (_append_x86) but that didn't enable it on x86-64. Explicitly enable libmpx on x86-64 too. (From OE-Core rev: 5111bd5e666408dbca7db0e6d664fe0103744253) Signed-off-by: Mikko Ylinen Signed-off-by: Ross Burton Signed-off-by: Richard Purdie

gcc-runtime: Fix QA issue

2017-03-08T11:52:57+00:00

ERROR: gcc-runtime-6.3.0-r0 do_package: QA Issue: gcc-runtime: Files/directories were installed but not shipped in any package: /usr/lib/libmpxwrappers.la Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install. gcc-runtime: 1 installed and not shipped files. [installed-vs-shipped] (From OE-Core rev: 3658da86e57dc87ac3957b05f853a7f1a56bfab2) Signed-off-by: Martin Jansa Signed-off-by: Richard Purdie