summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc
Commit message (Collapse)AuthorAgeFilesLines
* gcc-cross: Clean up fixed-includesRichard Purdie2019-09-011-0/+2
| | | | | | | | | | | | | | | | | | We had interesting failures where building gcc-cross-powerpc with 5.0 kernel headers, then building eudev after moving to 5.2 headers failed. gcc-cross doesn't rebuild when linux-libc-headers changes due to its listing in SIGGEN_EXCLUDE_SAFE_RECIPE_DEPS. This shouldn't matter but fixincludes as adding asm-generic/socket.h to its filtered list which was then replacing the real header with an older version. This mismatch lead to build failures. We trust the Linux kernel headers to be ANSI safe so lets just clear out any headers and trust the originals to be correct. (From OE-Core rev: f0fcaa88b7b2977c2cb35b060747442ee9ff3dcd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Search in OE specific target gcclibdirKhem Raj2019-08-222-7/+7
| | | | | | | | | | | | We put gcclibir to be /usr/lib/<arch>/... and not default usr/lib/gcc/<arch>, therefore make the include search path also look into this directory, this should help in finding gcc headers like omp.h (From OE-Core rev: 121ce09332099ab7ea695a3495daf4f904f69ae5) Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Martin Jansa <martin.jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-9: Upgrade to 9.2Khem Raj2019-08-2147-226/+213
| | | | | | | | | | | BugFix only release see [1] for details [1] https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=9.2 (From OE-Core rev: d00fac5bb9c479b5709ce73ae7fc0a14474a69c9) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-cross-canadian: Drop obsolete shlibs exclusionRichard Purdie2019-08-141-3/+0
| | | | | | | | | | | | | | | | | This is a very old change as and be inferred from the name in the comment. We've since had many changes to pkgdata including separating it to its own sysroot now so the reasons for this blanket exclusion are likely long gone. If the shlib provides were really the problem I'd much rather have a dedicated variable for that too. Removing this fixes missing dependencies on nativesdk-libc and other libs which would then happen automatically. (From OE-Core rev: 096fa15efbcb704451b2f38ceab36508ef64f07e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: Move content from gcclibdir into libdirKhem Raj2019-08-143-23/+15
| | | | | | | | | | | | | | | | | | | | | OE does not use the traditional /usr/lib/gcc prefix to store gcc-runtime it basically is moved into libdir, however some newer files were installed by newer versions of gcc especially libgomp ( omp.h openacc.h ) into gcclibdir, so we have content in both directories, this confuses other tools which are trying to guess the gcc installation and its runtime location, since now we have two directories, the tools either choose one or other and we get inconsistent behavior, e.g. clang for aarch64 uses /usr/lib but same clang for riscv64 chose /usr/lib/gcc This change ensures that OE ends up with single valid location for gcc runtime files Move more common bits into common inc file (From OE-Core rev: e9e5744ba8b0d43c8b874d365f83071ce20bf0a1) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-9.1: add back GLIBC_DYNAMIC_LINKER riscv changesRicardo Salveti2019-07-051-7/+21
| | | | | | | | | | The riscv GLIBC_DYNAMIC_LINKER changes were dropped during the gcc 9.1 update, breaking usrmerge support. (From OE-Core rev: 87a59a79292d2673d084e148a8161a676d87bf18) Signed-off-by: Ricardo Salveti <ricardo@foundries.io> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime.inc: create the correct directory before creating the symlinks in itMartin Jansa2019-06-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * since commit b071a1a209556158bcfcc20e3c8bd4b15373767c Author: Changqing Li <changqing.li@windriver.com> Date: Tue Jun 18 15:46:56 2019 +0800 gcc-runtime: fix C++ header mapping for n32/x32 tune gcc-runtime.do_install is failing with: ln: failed to create symbolic link 'work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux-gnueabi/bits': No such file or directory WARNING: exit code 1 from a shell command. ERROR: Function failed: do_install (log file is located at work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/temp/log.do_install.31049) There is only empty directory without the -gnueabi suffix: work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oe-linux/ and work/aarch64-oemllib32-linux-gnueabi/lib32-gcc-runtime/9.1.0-r0/image/usr/include/c++/9.1.0/arm-oemllib32-linux-gnueabi/ bits ext * make sure to create correct directory (with -${TARGET_OS suffix instead of -linux suffix) before creating the symlinks in it (From OE-Core rev: 41cbf5dc203ba74b06cb4890e1022f3f02fbd6fd) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: fix C++ header mapping for n32/x32 tuneChangqing Li2019-06-191-12/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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 "<path>/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 <changqing.li@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Remove 0006-gcc-disable-MASK_RELAX_PIC_CALLS-bit.patchAdrian Bunk2019-06-074-120/+0
| | | | | | | | | | | | | | | 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 <bunk@stusta.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: CVE-2018-12886Zhixiong Chi2019-06-042-0/+814
| | | | | | | | | | | 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 <zhixiong.chi@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: reduce the variables in symtabZhixiong Chi2019-05-292-0/+95
| | | | | | | | | | | | | | 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 <zhixiong.chi@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-9: Add recipes for gcc 9.1 releaseKhem Raj2019-05-1248-0/+3304
| | | | | | | | | | | 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 <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgfortan: Package target gcc include directory to fixKhem Raj2019-05-121-0/+1
| | | | | | | | | | | | 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 <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-target: Do not set --with-sysroot and gxx-include-dir pathsKhem Raj2019-05-081-2/+0
| | | | | | | | | | | | | | | | | | | | | | 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 <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: fix CVE-2018-18484Anuj Mittal2019-04-302-0/+326
| | | | | | | (From OE-Core rev: ac6af654f50aa6f3057dee0de806f5dfae10e4a8) Signed-off-by: Anuj Mittal <anuj.mittal@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-sanitizers: fix -Werror=maybe-uninitialized issueMingli Yu2019-04-231-0/+3
| | | | | | | | | | | | | | | | | | | | | | | 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 <Mingli.Yu@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Remove Java support variablesAdrian Bunk2019-04-162-8/+1
| | | | | | | | | Java support was removed in upstream gcc 7. (From OE-Core rev: 81551871b183f802ce3c1d0c8fb16479d9671a04) Signed-off-by: Adrian Bunk <bunk@stusta.de> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-cross-canadian: Make baremetal specific code genericKhem Raj2019-04-121-5/+4
| | | | | | | | | | | | | baremetal override is not valid for cross-canadian anymore therefore use the TARGET_OS overrides Fixes e.g. https://github.com/riscv/meta-riscv/issues/117 (From OE-Core rev: 1bc122a044de280d17525c8e5ee66e81775a7d8b) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgcc: Create linux-musleabihf and linux-gnueabihf symlinksKhem Raj2019-04-091-0/+7
| | | | | | | | | | | | | When we have hard-float ABI enabled, certain tools e.g. llvm/clang expects the hf version of tuples for crt files from libgcc, therefore create a symlink to help the cause. This makes clang work with hard-float defaults on target (From OE-Core rev: f58cf0d0ff05636a70330c54f7e537f9480674c4) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-8.3: add back GLIBC_DYNAMIC_LINKER riscv changesRicardo Salveti2019-03-291-2/+16
| | | | | | | | | | The riscv GLIBC_DYNAMIC_LINKER changes were dropped during the gcc 8.3 update, breaking usrmerge support. (From OE-Core rev: 299ec755de5d568f284d98c77863da4636e3fd05) Signed-off-by: Ricardo Salveti <ricardo@foundries.io> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Update to 8.3 latest on 8.x releaseKhem Raj2019-02-2854-823/+464
| | | | | | | (From OE-Core rev: 97866f4518879bdb1977e1a87ec47cc4f9b0e0eb) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgfortran: Set license to GPL-3.0-with-GCC-exceptionSanthosh Nadig2019-02-141-0/+5
| | | | | | | | | | | libgfortran did not have the GCC exception in the same manner as libgcc had. Change-Id: If48ab6e6775da235c8fdd0ca4e835acf1e831252 (From OE-Core rev: 0b4a4b37260e719ae12fb9a8e6556759422bfc92) Signed-off-by: Santhosh Nadig <santhosn@axis.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: Add --cache-file to EXTRA_OECONFRobert Yang2019-01-241-0/+1
| | | | | | | | | | | | | This can save configure time since it runs configure multiple times: $ time bitbake gcc-runtime -cconfigure 60s -> 54s Saved 6s (From OE-Core rev: 48cc7179ffeb89adf1ba5212338b958684e43962) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix riscv multilibs for OE wayKhem Raj2019-01-032-0/+28
| | | | | | | | | | | | | | In OE we do not build mutlib like gcc does it by default, this ensures that mutlilib is virtually disabled for OE, since we hardly use same gcc to build for multiple ABIs This fixes cases in SDK where g++ is not able to find standard c++ include headers (From OE-Core rev: badbeb01dd642d9d647d3760a3ce2aa39c3567da) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* recipes: Drop virtual/libc-for-gccRichard Purdie2018-12-262-2/+1
| | | | | | | | | We no longer have special "libc" for gcc so we can rely on plain virtual/libc and reduce the complexity in the dependencies. (From OE-Core rev: 122217b421f749b5fef52bea44ad6e04bc8f8d3a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Drop the -initial versions of the compilerRichard Purdie2018-12-269-126/+6
| | | | | | | | | | Separated out from the previous commit for clarity, this simply drops all the -inital pieces of gcc which are no longer needed after the previous commit. (From OE-Core rev: d84971928b68efddbdb6344b1021d998c9e26adb) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Drop gcc-cross-initial and use gcc-cross insteadRichard Purdie2018-12-265-10/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We need a libgcc to build glibc. Tranditionally we therefore build a non-threaded and non-shared compiler (gcc-cross-initial), then use that to build libgcc-initial which is used to build glibc which we can then build gcc-cross and libgcc against. Firstly, we can drop the glibc dependency from gcc-cross, *if* we make two changes: a) specify the minimum glibc version to support in a configure option b) create a dummy limits.h file so that later when glibc creates one, the headers structure has support for it. We can do this with a simple empty file Once gcc-cross is libc independent, we can use it to build both libgcc-initial and then later libgcc. libgcc-initial is tricky as we need to imitate the non-threaded and non-shared case. We can do that by hacking the threading mode back to "single" even if gcc reports "posix" and disable libc presence for the libgcc-intial build. We have to create the dummy limits.h to avoid compiler errors from a missing header. glibc will fail to link with libgcc-initial due to a missing "exception handler" capable libgcc (libgcc_eh.a). Since we know glibc doesn't need any exception handler, we can safely symlink to libgcc.a. With those changes, gcc-cross can be used in all places and we only need one build of gcc for each architecture. For some reason ifunc was being disabled on mips prior to these changes but afterwards became enabled but caused assertion failures. This is therefore disabled until we can debug that. (From OE-Core rev: 62b7308b8c4d2b439a15a4f7cbc6f823077bb0be) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: Drop building libmpxKhem Raj2018-12-201-29/+0
| | | | | | | | | | | | libmpx is not supported any longer and infact has been removed completely from gcc-9, see https://github.com/gcc-mirror/gcc/commit/1e42d5c637e1b1f65dfddd0923dfb25676bb56e5 (From OE-Core rev: 547174fc834273af67a2f7e50a3cf6c8e3b900f4) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: Add missing libc dependencyRichard Purdie2018-12-181-5/+1
| | | | | | | | | | | | | | | | | | | For reasons lost in the depths of time, perhaps performane related, we only have a dependency on libc at packaging time. This is too late, as demonstrated by a recent build failure on non-IA builds where the glibc 2.29 upgrade had been removed from the build: ld: recipe-sysroot/usr/lib/../lib/libstdc++.so: undefined reference to `log@GLIBC_2.29' libstdc++ should have been rebuilt but had not as the dependency wasn't present. Add the missing dependency to avoid this problem (and drop the other form of dependency which is no longer needed). (From OE-Core rev: 14c291e1fb6324da46885b69fbd7f01b3c6b053e) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Drop 7.3 since 8.2 is working fine for us2.7_M1Richard Purdie2018-12-1561-4857/+0
| | | | | | | | We've had gcc 8.2 around for long enough that 7.3 can be removed now. (From OE-Core rev: 20aea61385e1a53ac245353899277ba20104ed2f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-7.3, gcc-8.2: Use variable SYSTEMLIBS_DIR instead of hardcoding it for ppc64Serhey Popovych2018-12-154-0/+64
| | | | | | | (From OE-Core rev: d4063951acabae0b69fc195ec1e0f2dcd02a5d01) Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Enable secureplt for powerpc64 target tooSerhey Popovych2018-12-151-1/+1
| | | | | | | (From OE-Core rev: 72c3381ef5b18c784707ef361ee02f07770220f6) Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: More places to patch to disable ldbl 128 for musl on PPCSerhey Popovych2018-12-152-2/+731
| | | | | | | | | | | | | | | | | | | There are four functions using TFmode type (128bit) that isn't available when building with musl. Move each of them from common ppc64-fp.c to individual files referenced from t-float128 that used when ldbl 128 enabled at configure time. For gcc-7.3 if -mfloat128 is given -mfloat128-type must be given too. Exclude ibm-ldouble.c when ldbl 128 isn't enabled at config time. Build and boot tested with musl (no float128) and glibc (float128 and ibm128 on PowerPC64). (From OE-Core rev: dec8e566810525563b33c2877d10db0a70965d6d) Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix preprocessor redefines for header pathesSerhey Popovych2018-12-152-72/+0
| | | | | | | | | | | | | | | | | | | | | When building for powerpc64 using musl as C library we get preprocessor macro redefinition errors since gcc-configure-common.inc adds #define of STANDARD_STARTFILE_PREFIX_1 and STANDARD_STARTFILE_PREFIX_2 to gcc/defaults.h after ones added by a patch that ensures target gcc headers included. Since gcc-configure-common.inc included in every gcc recipe either directly or indirectly, do_configure task is not disabled/deleted for any of them (except gcc-source.inc) and there is no precondition that skips gcc/defaults.h patching in gcc-configure-common.inc::do_configure_prepend() we can just remove conflicting parts of mentioned above patch to have single place where start files prefixes defined in do_configure() task. (From OE-Core rev: 0622a4168aac627b44547f72fe93589cf1050e42) Signed-off-by: Serhey Popovych <serhe.popovych@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Select proper ARC CPU when build for targetAlexey Brodkin2018-11-231-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | By default GCC for ARC is configured with ARC700 CPU. This means when we don't pass "-mcpu=xxx": a) Code will be compiled for ARC700 b) Libs will used for ARC700 And if we happen to run on ARCv2 core like ARC HSxx we won't be able to use target gcc w/o "-mcpu=xxx" which is not very convenient as we want to build "target" toolchain but not canadian-cross. Note the trick here is we set TUNE_PKGARCH in just 2 values, it is either "arc700" for all ARCompact cores (ARC750 & ARC770) and "archs" for all ARCv2 cores (ARC HS38 & HS48), see [1]. This gives us usable defaults. For cross-compilation we use TUNE_CCARGS for fine-tuning depending on which HW features we have on the current target so that we may have HW feature A & B or B & C or A & B & C, see [2]. [1] https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/master/conf/machine/include/tune-arcv2.inc#L4 [2] https://github.com/foss-for-synopsys-dwc-arc-processors/meta-synopsys/blob/master/conf/machine/include/tune-arcv2.inc#L34 (From OE-Core rev: 6d2e44db7ebada41ad1cfc1c98ce9012242ced11) Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgcc/gcc-runtime: Disable thumb mode on armv6Richard Purdie2018-10-183-0/+8
| | | | | | | | | | | Without this the build fails for armv6t targets due to invalid assembler instructions in thumb mode. [YOCTO #12929] (From OE-Core rev: 801141be68e5c754f2cd1d80d13982f037fc03e5) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Remove unnecessary --with-mpfr and --with-mpc when cross compilingMike Crowe2018-10-092-6/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Passing --with-mpfr and --with-mpc when compiling the cross compiler appears to be at best unnecessary, and at worst can cause build failures. Firstly, the paths passed in gcc-cross-canadian are using the undefined ${layout_exec_prefix}. This results in configure passing -I${STAGING_DIR_HOST}/include twice to the compiler when it's doing its test builds. This is mostly pointless since that directory doesn't exist with the default oe-core configuration - the correct path would be -I${STAGING_DIR_HOST}/usr/include. The path for mpfr passed in gcc-cross is correct, but unnecessary since it is just the sysroot default. I've gone back through the history, and it seems that these lines (or similar ones) were originally added way back in 8800d8be25295dd7c7d84dde62c3be4df8e43346 for GCC 4.1.1 in 2006! I asked[1] if anyone knew why this was necessary but received no response, so I can only assume that no-one knows. I've successfully built for various targets with this patch applied and observed no problems. [1] http://lists.openembedded.org/pipermail/openembedded-core/2018-September/155971.html (From OE-Core rev: 2f9f02d5fda9884ccf9ae22ceb00d59b99036a49) Signed-off-by: Mike Crowe <mac@mcrowe.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix specs generation for ARCAlexey Brodkin2018-09-222-0/+45
| | | | | | | | | | | | | | | GCC's built-in spec for LD is missing a space after "--eh-frame-hdr" thus with the next option merged together they are not understood by LD and so LD fails. Back-port from upstream GCC, see: https://github.com/gcc-mirror/gcc/commit/892142379c6b99fe8c3ebdfe0b79e2a435228c1d (From OE-Core rev: 0757187bdbed3025b022a82dd85ee35dc7b71f1f) Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Disable libitm for ARCAlexey Brodkin2018-09-211-0/+1
| | | | | | | | | | The libitm is not supported on ARC, so disable it (From OE-Core rev: 6840f54cbac88e8a8f70384775771c4fda20b9c9) Signed-off-by: Alexey Brodkin <abrodkin@synopsys.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Merge two related patches togetherRichard Purdie2018-09-053-42/+4
| | | | | | | | | These patches may as well be merged together as they affect the same code and things are clearer this way. (From OE-Core rev: 7533c000183a2b447cbabd6ce1b8b75de55b63e7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-7.3: Backport fixes for std::pair high memory usageJoel Stanley2018-07-312-0/+59
| | | | | | | | | | | | | | C++ applications that contain a specfic use of std::pair with tempates cause the build to require many gigabytes of RAM to build. This is a fix that was applied to the upstream GCC 7 branch. Change-Id: I213f96d1d6332e2dce5765482ff3413f1abd7ff8 (From OE-Core rev: 51a09ba2729a840a9f2f87b68c7f50a3e6ac0d04) Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-7.3: Fix build on ppc64le hostsJoel Stanley2018-07-312-0/+38
| | | | | | | | | | | | | | | | When building on ppc64le hosts that have GCC 8 (such as Ubuntu 18.10) the GCC build bootstrap fails. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86162 This is a fix that was applied to the upstream GCC 7 branch. Change-Id: I7796d2a999ec420805dd1c6cf0a1ecba1de5a897 (From OE-Core rev: c17f5e7e954487ad3e97e26c3e0d31443d658d5a) Signed-off-by: Joel Stanley <joel@jms.id.au> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-8: Upgrade to 8.2 releaseKhem Raj2018-07-3053-67/+5
| | | | | | | | (From OE-Core rev: e3f7e684cd619b5fe072179dffd573889e8ba470) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-8: define GLIBC_DYNAMIC_LINKER relative to SYSTEMLIBS_DIR on riscvRicardo Salveti2018-06-281-1/+15
| | | | | | | | | | Refresh 0014-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch to also define GLIBC_DYNAMIC_LINKER relative to SYSTEMLIBS_DIR on riscv. (From OE-Core rev: 12e859dfb70f8aae40edfd88b143b6c771f4e1a6) Signed-off-by: Ricardo Salveti <ricardo@opensourcefoundries.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-8: Enable fp arch extention when fpu is availableKhem Raj2018-06-212-3/+10
| | | | | | | | | | | | | | This is especially needed when defaulting to hard-float ABI Fixes errors e.g. cc1: error: -mfloat-abi=hard: selected processor lacks an FPU Fixes [YOCTO #12795] (From OE-Core rev: 85981cbbf0ce48a6d82bc39248afa9540ca858d8) Signed-off-by: Khem Raj <raj.khem@gmail.com> Cc: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-target.inc: configure gcc for armv7ve targets to default to armv7veAndre McCurdy2018-06-181-5/+6
| | | | | | | | | | | | | | | | | | | | | | Originally these ARM specific EXTRA_OECONF options were applied to both gcc for the target and gcc-cross. That lead to a compromise being made: gcc on the target was configured to default to an ARM architecture which was at least compatible with the target (but not necessarily an exact match) and gcc-cross was configured default to armv7a for both armv7a and armv7ve (to avoid gcc-cross rebuilds when switching between the two). However, when these ARM specific EXTRA_OECONF options were moved from gcc-configure-common.inc into gcc-target.inc (ie they were made to apply only to gcc on the target) the compromise no longer needed to be made. http://git.openembedded.org/openembedded-core/commit/?id=851937dde81de2a9ef54c5f19a78fb12fb82afd4 (From OE-Core rev: 3c368282741e9de1f96988e127b86a6a01b6a26f) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-8: Fix spurious mcpu/march conflict for xscaleKhem Raj2018-06-182-0/+62
| | | | | | | (From OE-Core rev: 00808545041750698f710ef4e0345c80221373b8) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc8: drop stray uClibc specific patchAndre McCurdy2018-06-182-29/+0
| | | | | | | | | | | | The patch was previously removed for gcc7 but came back with gcc8. http://git.openembedded.org/openembedded-core/commit/?id=f71bc69e5b7581c53071055b694bb0dbfe4b4a87 (From OE-Core rev: 5f1b9128bd8693b2309c07cfc2de7b8f77c34da1) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-8: enable build-id in gcc-cross-initialRichard Purdie2018-06-151-0/+1
| | | | | | | | | | | | | | Apply patch from Taras Kondratiuk <takondra@cisco.com> to gcc 8.x too. Normal gcc-cross has build-id feature enabled by default, so most of target binaries has build-id. But libc (glibc, musl) doesn't have build-id, because it is built with gcc-cross-initial. Build-id is a useful feature, so enable it for gcc-cross-initial too. (From OE-Core rev: f24308c95853bec5cfc9f0794b111c6afecbe768) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: enable build-id in gcc-cross-initialTaras Kondratiuk2018-06-151-0/+1
| | | | | | | | | | | | | | Normal gcc-cross has build-id feature enabled by default, so most of target binaries has build-id. But libc (glibc, musl) doesn't have build-id, because it is built with gcc-cross-initial. Build-id is a useful feature, so enable it for gcc-cross-initial too. (From OE-Core rev: ba69701dac785a220feffd6118718b1c9e733548) Signed-off-by: Taras Kondratiuk <takondra@cisco.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-07-04 12:34:22 +0000