summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/gcc-configure-common.inc
Commit message (Collapse)AuthorAgeFilesLines
* gcc: remove paths to sysroot from configargs.h and checksum-options for ↵Oleksandr Hnatiuk2024-08-031-1/+0
| | | | | | | | | | | | | | | | | | gcc-cross-canadian Apply fixes from gcc-cross (84a78f46d594 and 0ead8cbdfb96) to gcc-cross-canadian. This will improve (but not fix) reproducibility of gcc-cross-canadian. Also move this code to functions to avoid code duplication. [RP: Tweak patch to make the function parameters clear and fix quoting issues ensuring the code exactly matches the original replacements with an additional parameter.] (From OE-Core rev: 350ff7d53f7506de2bc01f0efc569b8294b9afea) Signed-off-by: Oleksandr Hnatiuk <ohnatiuk@cisco.com> Signed-off-by: Denys Dmytriyenko <denys@konsulko.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: remove g77/f77Kai Kang2024-06-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | g77/f77 has been removed from gcc 4.0.0 via commit: * b4117c30610 Makefile.def, [...]: Remove all mention of libf2c. When set FORTRAN = ",f77" it complains with error: | The following requested languages could not be built: f77 | Supported languages are: c,c,c++,fortran,go,lto,m2,objc,obj-c++ So remove g77/f77 from gcc recipes. [1]: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=b4117c30610 (From OE-Core rev: 6469c6a00066af24c87ec5dd7994ebbc610c3782) Signed-off-by: Kai Kang <kai.kang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: don't pass --enable-standard-branch-protectionRoss Burton2023-07-141-1/+0
| | | | | | | | | | | | | | | | | | | | By changing the default code generation of GCC we're inadvertently breaking the GCC test suite, which has ~120K+ more failures when run for aarch64 compared to x86-64. This was because the generated code fragments included the BTI instructions, which the test case wasn't expecting. We can't tell the tests globally to run without branch protection, as that will break the tests which also turn it on. Remove the enabling of branch protection by standard in GCC, we'll enable it in the tune files instead. (From OE-Core rev: bb4b9017db6a893ed054a2d2ad4cc671dec09c42) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Alexandre Belloni <alexandre.belloni@bootlin.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: convert nested overrides leftovers to new syntaxDenys Dmytriyenko2021-08-041-1/+1
| | | | | | | | | Those were missed in previous rounds of automated and manual conversion. (From OE-Core rev: 22f9c7268b542baf6cd8aa0e34c8fb7aa1579e08) Signed-off-by: Denys Dmytriyenko <denis@denix.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Convert to new override syntaxRichard Purdie2021-08-021-12/+12
| | | | | | | | | | | | This is the result of automated script conversion: scripts/contrib/convert-overrides.py <oe-core directory> converting the metadata to use ":" as the override character instead of "_". (From OE-Core rev: 42344347be29f0997cc2f7636d9603b1fe1875ae) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: enable branch protection by standardRoss Burton2021-06-081-0/+1
| | | | | | | | | | | | | | | | Pass --enable-standard-branch-protection. This is an aarch64-specific option (currently) which does nothing on other targets. On aarch64 this generates code uses BTI/PAC instructions to mitigate Return Orientated Programming attacks. This approach is backwards compatible and the code size/performance impact is typically negliable. More details can be found at https://events.static.linuxfound.org/sites/events/files/slides/slides_23.pdf (From OE-Core rev: 84e6064cde02b463066d7b63fcf8baf392491327) Signed-off-by: Ross Burton <ross.burton@arm.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc10: Don't default back to -fcommonJacob Kroon2020-08-261-1/+0
| | | | | | | | | | | | It has been almost 3 months since the upgrade to gcc 10. Switch back to relying on gcc default configuration (-fno-common). This reverts OE-Core commit 951e859b1e8297970278c539e989b8a6d06a9cb3. (From OE-Core rev: 4ee733e1551d3960a23a600eb71a01cf7a51fa06) Signed-off-by: Jacob Kroon <jacob.kroon@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc10: Default back to -fcommonKhem Raj2020-05-141-0/+1
| | | | | | | | | | | For time being change back to -fcommon as default, helps us iron out other issues, eventually this should be removed as we fix the packages to work with -fno-common (From OE-Core rev: 951e859b1e8297970278c539e989b8a6d06a9cb3) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Configure all gccs with --disable-install-libibertyKhem Raj2020-04-261-0/+1
| | | | | | | | | | | | | | | OE uses libiberty from binutils, since its properly compiled as pic archive and applications and other libraries needing libiberty can properly link with it. With this option applied, explicit delete of libiberty headers and libraries is not required in install step, since they wont get installed in first place. (From OE-Core rev: fa8a205c69770d23323c9a06373db958af4b34d3) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure: Enable the use of different symbol versioningAlejandro Enedino Hernandez Samaniego2020-01-191-1/+3
| | | | | | | | | | | | | | | While the gnu style for symbol versioning is the most usual, --enable-symvers[=style] can be provided several values, gnu, gnu-versioned-namespace, darwin, darwin-export, and sun, depending on users needs. Introduce the SYMVERS_CONF variable to allow the user to configure the symbol versioning in shared libraries. (From OE-Core rev: f850931173fc210ed25706fd8fbfe0a310f99dfc) Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandro@enedino.org> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix ldbl-128 support for muslKhem Raj2019-09-031-1/+0
| | | | | | | | | | | | | Let the patch trigger based on target triplet instead of passing via configure, this lets gcc compile for 64bit otherwise it ends up with libgcc build errors error: unable to emulate 'TF' (From OE-Core rev: 2259bf5366a9ff654dfaf15baa5df2d943383ce6) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Remove Java support variablesAdrian Bunk2019-04-161-7/+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: Drop the -initial versions of the compilerRichard Purdie2018-12-261-1/+0
| | | | | | | | | | 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-261-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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: Introduce a knob to configure gcc to default to PIEKhem Raj2017-07-081-0/+3
| | | | | | | | | | | | GCCPIE flag which is empty by default adds "--enable-default-pie" configure option for harderned distros We do not require to add -fpie -pie flag externally anymore (From OE-Core rev: 1c7e195c94764d680a12a49b870f04cd58860f81) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: Drop further remnants of uclibc supportRichard Purdie2017-06-221-2/+0
| | | | | | | | | | | | | | uclibc support was removed a while ago and musl works much better. Start to remove the various overrides and patches related to uclibc which are no longer needed. uclibc support in a layer would still be possible. I have strong reasons to believe nobody is still using uclibc since patches are missing and I doubt the metadata even parses anymore. (From OE-Core rev: ec03023d2165b49a52b83bac1ea2f0bfded7b852) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure/gcc-target: Move arm6/7 config to target onlyRichard Purdie2017-05-161-8/+0
| | | | | | | | | | We only build one gcc-cross per architecture and having target specific flags means gcc-cross would rebuild. These flags are really for the on target case, so they should be set in gcc-target only. (From OE-Core rev: 851937dde81de2a9ef54c5f19a78fb12fb82afd4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: remove True option to getVar callsJoshua Lock2016-12-161-1/+1
| | | | | | | | | | | | | getVar() now defaults to expanding by default, thus remove the True option from getVar() calls with a regex search and replace. Search made with the following regex: getVar ?\(( ?[^,()]*), True\) (From OE-Core rev: 7c552996597faaee2fbee185b250c0ee30ea3b5f) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure: Add mipsisa{32, 64}r6{el, } supportZubair Lutfullah Kakakhel2016-10-071-0/+4
| | | | | | | | | Add support for MIPS Release 6 ISA (From OE-Core rev: 4c694d5bd29c406009332e3bd388e3f6a504d103) Signed-off-by: Zubair Lutfullah Kakakhel <Zubair.Kakakhel@imgtec.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure: Enable initfini-arraySaul Wold2016-09-201-0/+4
| | | | | | | | | | | | | | | | This adds the correct support for initfini-array which replaces .init and .fini with .init-array and .fini-array. There is no appreciable size difference with this change. The change is needed since configure will not correctly detect support when building cross-compilers. (From OE-Core rev: 9f8a075ab46691534e2b22d0a363b3c847394215) Signed-off-by: Haitao Huang <haitao.huang@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: drop --enable-target-optspace from configureAndre McCurdy2016-02-021-8/+0
| | | | | | | | | | | | | | | | | | | | | | | | Configuring gcc with --enable-target-optspace (which causes gcc to append "-g -Os" to the default CFLAGS_FOR_TARGET and so force libgcc etc target libraries to always be optimised for size) dates back to the very first commit in oe-core git in 2005 (for gcc 3.4.3). Configuring gcc with --enable-target-optspace is not done widely elsewhere (it's not used for Ubuntu or Fedora host gcc, the Linaro binary toolchain or in Buildroot since early 2015). Sometime around gcc 4.5.x it caused problems for powerpc and so was disabled for that architecture: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43810 This patch removes --enable-target-optspace completely (ie powerpc is no longer a special case) and allows optimisation of libgcc etc to be controlled directly by the flags present in TARGET_CFLAGS. (From OE-Core rev: 686b266506a1a56fb68ab0f00d658787dd7fe4ce) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* machine/include: drop tune-cortexm*.inc and tune-cortexr4.incAndre McCurdy2016-02-021-2/+0
| | | | | | | | | | | | | | The Cortex M1, M3 and R4 CPU tuning files are poorly tested (if at all). They have no obvious users either inside or outside oe-core. Until OE officially gains support for CPUs without an MMU, these tuning files are probably better maintained outside of oe-core (e.g. in a separate meta-nommu layer). (From OE-Core rev: 7a1445c55de904115b950c8e50432a9f11f02208) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: duplicate armv7a over-ride for armv7veAndre McCurdy2016-01-151-0/+1
| | | | | | | | (From OE-Core rev: 02c3ac6f066ccd1cbb6e457080bf10db5d6abfe0) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: add gcc-runtime ABI fixes for armv7m and armv7rAndre McCurdy2015-12-221-0/+2
| | | | | | | | (From OE-Core rev: 55beb07da9120a2444fcc53bbe1b8f418dafb5aa) Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Update default Power GCC settings to use secure-pltMark Hatle2015-11-161-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | The gcc default, bss-plt, will cause errors when using the prelinker. All other distributions that I am aware of are using the the secure-plt. For an explanation of the differences, the gcc docs: Current PowerPC GCC accepts a `-msecure-plt' option that generates code capable of using a newer PLT and GOT layout that has the security advantage of no executable section ever needing to be writable and no writable section ever being executable. PowerPC ld will generate this layout, including stubs to access the PLT, if all input files (including startup and static libraries) were compiled with `-msecure-plt'. `--bss-plt' forces the old BSS PLT (and GOT layout) which can give slightly better performance. The security of the new PLT and ability to run the prelinker outweigh any performance penalty. The secure-plt is enabled by default. The old bss-plt can be enabled by selecting 'bssplt' in the DISTRO_FEATURES. (From OE-Core rev: 70c55aada1101a5c687cdaa79f370fa4530b39d9) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: remove EXTRA_OECONF_INTERMEDIATERobert Yang2015-07-121-1/+0
| | | | | | | | | The gcc-intermediate had been gone, so remove EXTRA_OECONF_INTERMEDIATE. (From OE-Core rev: 00ffc14c57598e845281e151589292573905b03c) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: remove ac_cv_path_SEDRobert Yang2015-02-081-1/+0
| | | | | | | | | It is not needed any more since sed-native had been dropped. (From OE-Core rev: 289e433f8d0e4b5a710094e3a3c0d8e77e82e50d) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* arch-mips.inc: Change definition of TRANSLATED_TARGET_ARCHMark Hatle2015-01-291-0/+2
| | | | | | | | | | | | | | | | | | | | | | | [YOCTO #7230] In certain system configurations TRANSLATED_TARGET_ARCH will not expand in the right order for gcc-cross-candian-mips64n32 to be generated properly. This will cause SDKs to fail to generate properly. Changing the global definition of TRANSLATED_TARGET_ARCH always expands the ABIEXTENSION, which causes the OVERRIDES to pick it up as well. This effectively defines a new class of overrides for the 'n32'. The side effect is that we need to duplicate some mips64 overrides, and redefine others that were previously 'n32' or 'mips64' exclusive to have the correct semantics. (From OE-Core rev: 4b3a2b703b20583bd107f00a297d972e9bfb514a) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Rework shared workRichard Purdie2014-12-031-0/+1
| | | | | | | | | | | | | | | | | | | | | The current implementation of shared work for gcc is at best confusing. It relies on the fetch/unpack/patch tasks having exactly the same stamps and if this gets broken for some reason, its hard to figure out what the problem is. It also leads to complex code in bitbake. The benefits of shared work for gcc are clear but a better approach is needed. This patch adjusts things so that a single new recipe (gcc-source) provides the fetch/unpack/patch/preconfigure tasks, the rest of gcc simply depends on these tasks and have no fetch/unpack/patch tasks of their own. This means we should get the significant benefits (disk usage/performance) of the single source tree but in a way which has less potential for problems and is easier for people to understand. The cost is an extra recipe/some inc files which is probably a good tradeoff. (From OE-Core rev: ceaa0a448dc5ebddb4f7fb94fb8a503a1c0248c3) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure/gcc-common: Move preconfigure definition to common includeRichard Purdie2014-09-161-10/+0
| | | | | | | | | | | | | | | | | | | | | There is a race where: NOTE: recipe libgcc-initial-4.9.1-r0: task do_configure: Started NOTE: recipe gcc-runtime-4.9.1-r0: task do_preconfigure: Started | checking build system type... /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-deb/build/build/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../config.sub: line 1711: syntax error near unexpected token `;;' | /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-deb/build/build/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../config.sub: line 1711: ` ;;' | configure: error: /bin/bash /home/pokybuild/yocto-autobuilder/yocto-worker/nightly-deb/build/build/tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/libgcc/../config.sub x86_64-linux failed | WARNING: exit code 2 from a shell command. so we need to make sure the preconfigure task executes in all shared work contexts. (From OE-Core rev: 3c30331d6eaf804b83a6d27189a12efc94310e91) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: update compiler architecture to match gcc-runtime (armv6, armv7a)Peter A. Bigot2014-08-151-0/+7
| | | | | | | | | | | | | | | | | | | | | | The gcc-runtime recipe builds the gcc libraries including libstdc++ with $TARGET_CC_ARCH flags, which include -march=FOO flags that affect whether atomic instructions are available. This causes an ABI incompatibility when the compiler by default generates code for less capable architectures. For example, gcc-runtime libraries on a Cortex-A8 are built with a different C++11/C++14 mutex implementation than is used code compiled outside OE and without architecture-specific flags. This commit fixes the problem specifically for ABI issues related to atomic instructions available in ARMV6 and subsequent architectures. Other ABI incompatibilities may remain in other architectures. See: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62100 (From OE-Core rev: 0ba6ab39f187ecd4261f08e768f365f461384a3a) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Abstract long double configuration into python functionKhem Raj2014-08-151-4/+1
| | | | | | | | | | | musl does not support IBM 128 long double for ppc, instead of doing complex overrides move it into a pythong snippet which is easier to read and more compact. (From OE-Core rev: e7011429e40ae96b9c9f1e7f3c6f4c1f1102607f) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sdk: change EXTRA_OECONF_FPU to EXTRA_OECONF_GCC_FLOATPeter A. Bigot2014-08-151-2/+2
| | | | | | | | | | | | This variable is used to ensure the proper version of --with-float=FOO is passed to gcc's configure script. gcc also has a --with-fpu=FOO option that means something different. To avoid confusion, change the names to be consistent. (From OE-Core rev: c17d883fa99b6967d83c3796d22fc0c1dbe704e6) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: recipe whitespace changesPeter A. Bigot2014-08-151-22/+24
| | | | | | | | | | | Consistent use of whitespace in multi-line assignment, with special focus on OECONF modifications. Quotes on separate lines, four-space indentation, one value per line. (From OE-Core rev: d971db8b2259e4c35b871cccf130fba193849560) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common: Address problems with gengtypeRichard Purdie2014-06-171-0/+2
| | | | | | | | | | | | | | | | | | The gengtype patch we apply to gcc aims to ensure that the build and host config headers don't get confused. We're seeing build failures where both headers have been included, likely due to a race over the configuration files. It seems the gengtype-lex.c file isn't being regenerated when it should and the unconditional inclusion of bconfig.h is resulting in these issues. The fix is therefore to remove the file, forcing its regeneration. [YOCTO #6393] (From OE-Core rev: dd649374b30eb2d9980dce6eae95db0563593ef7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Clean up configure_prepend and fix for mingwRichard Purdie2014-06-011-7/+1
| | | | | | | | | | | | | | | | | | | | | The do_configure_prepend was duplicated in gcc-4.X.inc and gcc-configure-common.inc leading to confusion when reading the resulting do_configure task where the file was processed twice. The only difference was the removal of the include line for gcc 4.8/4.9. On mingw were were seeing two issues, firstly that the if statements meant the values we wanted weren't being set, the second that the include paths were still wrong as there was no header path set. To fix the first issue, the #ifdef conditionals were removed, we want to set these things unconditionally. The second issue is addressed by setting the NATIVE_SYSTEM_HEADER_DIR variable here (it was already set in t-oe). (From OE-Core rev: db44be06c75f2ac17a55dd1764471e869e872b8b) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-common: Only apply fpu settings to target gccRichard Purdie2014-05-021-1/+1
| | | | | | | | | | | | | Within the OE build environment, we supply the correct fpu settings. These only need to be spelt out for the on-target gcc. Doing this means the checksums for the core compiler don't depend on the fpu settings. We exclude the compiler tunes for similar reasons, it doesn't need to influence the compiler build. (From OE-Core rev: ce1f3fd20d81545d6d5dfc68f86f9fddf8ac9bbf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Drop ARCH_FLAGS_FOR_TARGET usageRichard Purdie2014-04-301-6/+0
| | | | | | | | | | | | | | | | | As far as I can tell this variable is now completely unneeded. It would only ever get used in target builds and these are now correctly done in the target environment namespace, not any of our cross environments. As such, CC and other variables contain the correct compilers and other tune options and these are correctly picked up when building libgcc, libstdc++ and others. I tried to figure out where else these would make any sense and couldn't find anything. Builds appear fine without them so lets drop the complexity including the patch adding in this flag to gcc. (From OE-Core rev: 5484596f4252e707ff791feedf143a72dbb613f6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-common/gcc-configure-common: Move gnu-configize to its own shared taskRichard Purdie2014-04-301-1/+9
| | | | | | | | | | | | | This command modifies ${S} and can race against other tasks running do_configure and having the scripts disappear from under them. To avoid this move to its own task and work on the shared work directory as a common task. It needs to be a python task to avoid lots of shell exported variables as dependencies. (From OE-Core rev: 55ed9ffbab5118140baac5d0d29dcc919e1f1668) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Globally replace 'base_contains' calls with 'bb.utils.contains'Otavio Salvador2014-04-251-1/+1
| | | | | | | | | | | The base_contains is kept as a compatibility method and we ought to not use it in OE-Core so we can remove it from base metadata in future. (From OE-Core rev: d83b16dbf0862be387f84228710cb165c6d2b03b) Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc/libtool/perl: Fix various path to sed-native problemsRichard Purdie2013-09-261-0/+1
| | | | | | | | | | | | | | | | | | | | If sed-native is built before these programs, hardcoded paths to sed-native can end up in scripts and other parts of the system which may cause issues if they are later used from sstate and sed-native is not installed. To avoid this, this patch changes the global site configuration to specify that plain "sed" is fine to be used. We need to spell this out for gcc since it doesn't see the site files since we don't autoreconf it. We can remove the values from libtool. We tell perl to use "/bin/sed" since it requires a path and the system sed should be just fine for it. [YOCTO #4971] (From OE-Core rev: 2ec171cb188601bf18c6c2895870907024b1c52a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: enable multilib for target gccConstantin Musca2013-02-011-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | - add a task to setup multilib configuration for target gcc - this commit adapts Nitin Kamble's work to gcc 4.7 - use a hash for storing arch-dependent multilib options - patch gcc in order to use the multilib config files from the build directory Tests: root@qemux86-64:~# gcc -m64 t.c -o t root@qemux86-64:~# file t t: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped root@qemux86-64:~# ./t Hello World ! root@qemux86-64:~# gcc -m32 t.c -o t root@qemux86-64:~# file t t: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped root@qemux86-64:~# ./t Hello World ! [YOCTO #1369] (From OE-Core rev: b26819c85881e82ee1b5c68840011e78c321f18e) Signed-off-by: Constantin Musca <constantinx.musca@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-cross: factor out --enable-threads argument into ${GCCTHREADS}Phil Blundell2012-09-261-1/+2
| | | | | | | | | | | This allows BSPs for architectures with no thread support to set (for example) "GCCTHREADS=no" without having to override all the other configure parameters. (From OE-Core rev: 6bb0d37529a82b953d374f2d76c2412d7cee587b) Signed-off-by: Phil Blundell <pb@pbcl.net> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: use --with-long-double-128 on powerpc to comply ↵Matthew McClintock2012-07-111-0/+4
| | | | | | | | | with ABI (From OE-Core rev: 243539efec94e79dade2525d0ab3586eea48c529) Signed-off-by: Matthew McClintock <msm@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: fix collect2 host contamination problem properlyRichard Purdie2012-07-051-4/+5
| | | | | | | | | | | | | We added the autoconf cache line a while back to ensure that configure doesn't poke into some hardcoded host paths looking for things it shouldn't. Applying it as part of do_configure wasn't getting it to the do_compile tasks where much of the configure scripts are run by gcc. This changes it to a simple export to ensure it reaches the places it needs to and truly gets rid of the cross compile badness messages from the logs. (From OE-Core rev: af58d5c3a5c5e632aa20b1d007d47dbbfb4ed6e6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-4.6, gcc-4.7: Add support for building mips64 cross compilerKhem Raj2012-05-211-0/+4
| | | | | | | | | Defaults to n64 ABI (From OE-Core rev: 253f1f3aebd1a90c55efcc6d1f585204e7f3c371) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: Use libc-uclibc overrideKhem Raj2012-04-301-3/+1
| | | | | | | | | Its better than duplicating the overrides (From OE-Core rev: 7159dad19f8cfd3e7e95523da63e91370744da7f) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure: Render --with-local-prefix harmlessKhem Raj2012-04-301-0/+1
| | | | | | | | | | | | | this option by default points to /usr/local no matter what so we cant let it sit on sidelines otherwise it will access host machine's /usr/local which may not be desired. So disable this option. This also helps in making gcc's shared state more consistent (From OE-Core rev: eee3658366e1ae9d3e429b3d3c968938d8d0f00e) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure: Pass distinct target flagsKhem Raj2012-04-301-0/+4
| | | | | | | | | | | | | | | | | When building gcc-cross-canadian libgcc is built using headers from gcc-crosssdk and not the target sysroot because we do not pass proper CFLAGS for target bits so it ends up using CFLAGS that were meant for compiling canadian gcc itself. It does not show up as a problem when building SDK with eglibc because eglibc-nativesdk and eglibc have identical headers. The problem shows up clearly when you try to build uclibc based meta-toolchain since then nativesdk libc and target libc are different (From OE-Core rev: 0e904103e9bd7fdb31bfcc129067511f9f45701b) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-configure-common.inc: Stop gcc looking at build system pathsRichard Purdie2012-04-151-0/+4
| | | | | | | | | | | | | | | | | | | There were puzzling failures when you make a force recompile of any gcc component. The error was in do_configure with cross-compilation badness being detected in config.log files. gcc is different in that many of the config.log files are generated during the do_compile phase. This means this host contamination issue has always been present but only shows up on a rebuild. The fix is to force the appropriate configuration variable to "none required" then gcc won't look in the bad locations. [YOCTO #2279] (From OE-Core rev: e7135f14f3ef37f93f5c28b319464f3d6dd9b8da) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2025-04-24 10:30:56 +0000