linux/poky.git/meta/recipes-devtools/gcc, branch uninative-2.6

gcc-runtime: fix C++ header mapping for n32/x32 tune

2019-06-19T11:46:44+00:00

The SDK was unable to find the C++ header pieces correctly since it's using a generic compiler, not one specifically targeting the multilib vendor prefix and default tune. This adds the right mapping to ensure SDKs work as expected. And fix problem in below configurations: multilib configuration 1: MACHINE="qemumips64" MULTILIBS ?= "multilib:lib32 multilib:libn32" DEFAULTTUNE_virtclass-multilib-lib32 ?= "mips" DEFAULTTUNE_virtclass-multilib-libn32 ?= "mips64-n32" MULTILIB_GLOBAL_VARIANTS_append = " libn32" require conf/multilib.conf ignoring nonexistent directory "/sysroots/mips64-poky-linux/usr/include/c++/8.2.0/mips64-poky-linux/32 multilib configuration 2: MACHINE="qemumips64" MULTILIBS = 'multilib:lib64 multilib:lib32' DEFAULTTUNE = 'mips64-n32' DEFAULTTUNE_virtclass-multilib-lib64 = 'mips64' DEFAULTTUNE_virtclass-multilib-lib32 = 'mips32r2' require conf/multilib.conf For this configuration: for target gcc-runtime, need to create symlink like mips64-poly-linux --> mips64-poky-linux-gnu32 for target lib64-gcc-runtime, need to create symlink like mips64-poly-linux/32 --> mips64-pokymllib64-linux in order to avoid conflict during populate_sdk, create symlink for subfoler bits/ext for target gcc-runtime, this is ugly, but seems no better way to cover all kinds of configuration. single lib configuration: MACHINE="qemumips64" DEFAULTTUNE = "mips64-n32" (From OE-Core rev: b071a1a209556158bcfcc20e3c8bd4b15373767c) Signed-off-by: Changqing Li Signed-off-by: Richard Purdie

gcc: Remove 0006-gcc-disable-MASK_RELAX_PIC_CALLS-bit.patch

2019-06-07T08:11:48+00:00

This was added 9 years ago as a workaround for a problem with gcc 4.5 on mips. Building webkitgtk works for me without it for qemumips. Debian also builds webkitgtk for 32/64 bit big/little endian mips without using this workaround. (From OE-Core rev: 7af322a995a9385f7f452c2988188de98db300c2) Signed-off-by: Adrian Bunk Signed-off-by: Richard Purdie

gcc: CVE-2018-12886

2019-06-04T22:09:25+00:00

Backprot CVE patch from the upstream: https://github.com/gcc-mirror/gcc.git [commit f98495d] https://nvd.nist.gov/vuln/detail/CVE-2018-12886 (From OE-Core rev: 889ad561093c14da5fc161b137e95e46f3f9af3f) Signed-off-by: Zhixiong Chi Signed-off-by: Richard Purdie

gcc: reduce the variables in symtab

2019-05-29T11:54:12+00:00

Backport the patch from upstream: https://github.com/gcc-mirror/gcc.git [commit beb921e] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=269925 Add the premark_used_variables function, meanwhile do not mark not premarked external variables in prune_unused_types_walk. (From OE-Core rev: 5f2119a309096aa8cbae666c37521b0c93da53d0) Signed-off-by: Zhixiong Chi Signed-off-by: Richard Purdie

gcc-9: Add recipes for gcc 9.1 release

2019-05-12T08:04:26+00:00

Add maintainer entry for gcc-source-9.1.0 Delete entry for gcc-source-7.3.0 (From OE-Core rev: bbf32e24608cd9479cf26f52aa14a42411b418c5) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

libgfortan: Package target gcc include directory to fix

2019-05-12T08:04:26+00:00

ERROR: libgfortran-9.1.0-r0 do_package: QA Issue: libgfortran: Files/directories were installed but not shipped in any package: /usr/lib/gcc/x86_64-poky-linux/9.1.0/include /usr/lib/gcc/x86_64-poky-linux/9.1.0/include/ISO_Fortran_binding.h (From OE-Core rev: 8493fe87e241bb7aeb9075683d2e44dd1e2bc334) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc-target: Do not set --with-sysroot and gxx-include-dir paths

2019-05-08T11:15:17+00:00

These options are not needed on target infact since the defaults would be good enough for compiler to find the relevant headers and libraries from compiler runtime with gcc9 it starts to strip the sysroot from gxx-include-dir which means it tries to look for gxx headers in localdir ignoring nonexistent directory "usr/include/c++/9.0.1" ignoring nonexistent directory "usr/include/c++/9.0.1/arm-yoe-linux-gnueabi" ignoring nonexistent directory "usr/include/c++/9.0.1/backward" instead of sysroot Removing these options make it behave normal (From OE-Core rev: 2996640fb3577a3c28a22f1e25eae15e8e3d46b1) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

gcc: fix CVE-2018-18484

2019-04-30T11:05:23+00:00

(From OE-Core rev: ac6af654f50aa6f3057dee0de806f5dfae10e4a8) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

gcc-sanitizers: fix -Werror=maybe-uninitialized issue

2019-04-23T22:30:19+00:00

When DEBUG_BUILD = "1" added in local.conf, there comes below build error when "bitbake gcc-sanitizers": | ./../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c: In function 'elf_is_symlink': | ../../../../../../../../../work-shared/gcc-8.3.0-r0/gcc-8.3.0/libsanitizer/libbacktrace/../../libbacktrace/elf.c:772:21: error: 'st.st_mode' may be used uninitialized in this function [-Werror=maybe-uninitialized] | return S_ISLNK (st.st_mode); After commit[16643b0322 bitbake.conf: Use -Og in DEBUG_OPTIMIZATION] introduced, "-Og" added to compiler when debug build enabled. Per https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00315.html, the gcc upstream thinks the warning is a false positive and suggests to use -O2 rather than -Og or -O1 when compiling that file, so pass -Wno-error to compiler when -Og is used to silence the error. (From OE-Core rev: d8d657f082d4a86f93ce810e5d99eb5c93333d8a) Signed-off-by: Mingli Yu Signed-off-by: Richard Purdie

gcc: Remove Java support variables

2019-04-16T10:10:02+00:00

Java support was removed in upstream gcc 7. (From OE-Core rev: 81551871b183f802ce3c1d0c8fb16479d9671a04) Signed-off-by: Adrian Bunk Signed-off-by: Richard Purdie