summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc
AgeCommit message (Collapse)Author
2015-04-17gcc-target: Don't install target gcc libdir filesRichard Purdie
Installing /usr/lib/gcc/* means we'd have two copies, one from gcc-cross and one from here. These can confuse gcc cross where includes use #include_next and builds track file dependencies (e.g. perl and its makedepends code). For determinism we don't install this to the sysroot, ever and rely on the copy from gcc-cross. [YOCTO #7287] (From OE-Core rev: 15b3324b769dc92e1b0d4b9da9fbfccbc8dde9dd) (From OE-Core rev: e80025efbfc8e8df01950045975d103b6d7f87b4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-04-17gcc-runtime: Remove libgfortran data from receipeDaniel Dragomir
Remove libgfortran packages from PACKAGES list as long as libgfortran has separate receipe since commit 5bde5d9b39ea67f19a1a6aedd0c08c6cfedcbe5f gcc: Allow fortran to build successfully in 4.8 Otherwise, when fortran support will be enabled in the compiler, both lingfortran and gcc-runtime receipes will create the same files and will try to install them. This will cause errors: ERROR: The recipe libgfortran is trying to install files into a shared area when those files already exist. Those files and their manifest location are: ... Please verify which recipe should provide the above files. (From OE-Core rev: 872342fa3d08edede4a0105ac3ddb0f2ae3224b4) (From OE-Core rev: de2aa7a56790581406f219339c9022638cd47494) Signed-off-by: Daniel Dragomir <daniel.dragomir@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-11gcc/libgcc-common.inc: Add missing 'fakeroot' to two tasksMark Hatle
Without the fakeroot flag the two tasks may create files or symbolic links that end up being owned by the user and not root:root as expected. (From OE-Core rev: 7e9fd9d34a540fdfc1243d059d1f13f1d09864d2) (From OE-Core rev: 86bee4a8d187bebe7f82d8ea1069ee610caac151) 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> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-02-11gcc: ensure target gcc headers can be includedPaul Eggleton
There are a few headers installed as part of gcc-runtime (omp.h, ssp/*.h). Being installed from a recipe built for the target architecture, these are within the target sysroot and not cross/nativesdk; thus they weren't able to be found by gcc with the existing search paths. Add support for picking up these headers under the sysroot supplied on the gcc command line in order to resolve this. Thanks to Richard Purdie for giving me a number of pointers during fixing this issue. Fixes [YOCTO #7141]. (From OE-Core rev: 5c87bb9ac2b35b3f8cf2b7d3e4507e7013115162) (From OE-Core rev: ce3f7777fd1d057f399f3f5df8df620e7eaf6cc2) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-06gcc: stub do_fetch instead of removing itRoss Burton
Whilst gcc doesn't have any source to fetch, it still needs a fetch task so that a world fetch can run without errors. So instead of deleting the fetch task, stub it. (From OE-Core rev: 8e68ebbddc2bc41eb6cb607c51d6a80c54c4199d) (From OE-Core rev: ebe7b52c90b8cc7626f93d6771412848825905ce) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-06gcc: Rework shared workRichard Purdie
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) (From OE-Core rev: 6e9af42063c4135d3e72406a22d762425e5bebfd) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-31gcc-4.9: fix the compile failure of 'defaults.h' not foundHongxu Jia
While compiling gcc-crosssdk-initial-x86_64 on some host, there is occasionally failure that test the existance of default.h doesn't work. ... | tmp/work-shared/gcc-4.9.1-r0/gcc-4.9.1/gcc/calls.c:1240: error: 'STACK_CHECK_MAX_VAR_SIZE' was not declared in this scope ... The reason is tm_include_list='** defaults.h' rather than tm_include_list='** ./defaults.h' So we add the test condition for this situation. (From OE-Core rev: fec684512c6f934d7a847b0c9f5151da81426910) (From OE-Core rev: 174b7c3fe0240ff6d897b5418a8bc020086f7ba1) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-31gcc: Fix intermittent failures during configureMark Hatle
If configure or any of the components it uses from the shared work directory change, do_configure may fail. An existing do_preconfigure was created to handle these conditions, but a 'sed' operation was missed, and a call to gnu-configize was also missed. (From OE-Core rev: 21c2cfff14442cf224e3568bdbb9bcd4070be247) (From OE-Core rev: cb7548feaeb07eca4855223ff2fa6676882b6424) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-12-31gcc: backport two patches to fix ICE in dwarf2out_var_locationJackie Huang
The first patch fixes the ICE in dwarf2out_var_location, at dwarf2out.c. r212171: * except.c (emit_note_eh_region_end): New helper function. (convert_to_eh_region_ranges): Use emit_note_eh_region_end to emit EH_REGION_END note. * jump.c (cleanup_barriers): Do not split a call and its corresponding CALL_ARG_LOCATION note. But it introduced a regression issue: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63348 so backport the fix for the regression as well: r215613: PR rtl-optimization/63348 * emit-rtl.c (try_split): Do not emit extra barrier. (From OE-Core rev: de52db1b1b0dbc9060dddceb42b7dd4f66a7e0f3) (From OE-Core rev: 0447732a7884ef49c7afbc2b408848e969666516) Signed-off-by: Jackie Huang <jackie.huang@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Armin Kuster <akuster808@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-11gcc: backport patch for gcc bug 61144Saul Wold
This fixes gcc bug 6144, which in my case exhibited itself as a kernel module that failed to load. This was because static platform_data structures were being corrupted with the optimiser being set to any value other than -O0. Originally-submitted-by: Peter Urbanec <openembedded-devel@urbanec.net> (From OE-Core rev: 365221f7285c0e392f573deaab3b1e00b12bc293) Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-10-06gcc-runtime: Add linux-gnuspe symlink to fix c++ headersRichard Purdie
Some architectures can mix different TARGET_OS values, in most cases we just use one but in the ppc case, can use two different values. In this case, to use one toolchain with both, we need to ensure the symlinks exist. This isn't ideal but does fix the ppc toolchains for the release, after which better ways of handling this can be investiaged. Without this, failures in the C++ toolchain are seen. (From OE-Core rev: 112641117f1152bad8a806f1aa872a67575d5316) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-09-16gcc-configure/gcc-common: Move preconfigure definition to common includeRichard Purdie
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>
2014-09-01recipes: Remove references to eglibcKhem Raj
change use of eglibc related variabled to glibc equivalents (From OE-Core rev: fd15d6e0c8da75951a91d4467eda23c229b1026d) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc-cross-initial: Put limits.h in gccdir/includeKhem Raj
musl e.g. is configured to not use fixed-include which is an improvement btw. but libgcc-initial configure has tests which probe for limits.h and since we put it in include-fixed/ dir and that dir does not appear in gcc's internal default search path the configure tests for CPP detection fail and libgcc-initial can not be compiled. (From OE-Core rev: 3bdc225a9e622e9d594944833964fe396200db01) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: update compiler architecture to match gcc-runtime (armv6, armv7a)Peter A. Bigot
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>
2014-08-15gcc: backport patch affecting Linux kernel buildsPeter A. Bigot
A long-standing bug in gcc turns out to cause problems with unpatched Linux versions due to improved optimization enabled by gcc 4.9. The upstream fix missed the gcc-4.9.1 cut-off. It's also been applied upstream to the 4.8 branch so is being added for OE's 4.8 as well. (From OE-Core rev: 06f911894a367f395139c2b0d6c2ba6371398478) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: Abstract long double configuration into python functionKhem Raj
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>
2014-08-15sdk: change EXTRA_OECONF_FPU to EXTRA_OECONF_GCC_FLOATPeter A. Bigot
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>
2014-08-15gcc-target: make --enable-clocale consistent with gcc-runtimePeter A. Bigot
(From OE-Core rev: 9ec30be63ad6d991646a7ce0ee22acdad7a81184) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: remove outdated configuration optionPeter A. Bigot
--enable-libunwind-exceptions was removed from gcc at release 3.4.3 about ten years ago. (From OE-Core rev: 285d3579727177e6962d7ad16677429e7dec65f4) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc-4.9: Ensure c++ includes are in /usr/include/c++/${BINV}Peter A. Bigot
Apply to gcc 4.9 the recent fix to the --with-gxx-include-dir override. Original OE-Core rev: 5a2ff3e8f7cd7a47a5ab4e581847ecc4df87fca (From OE-Core rev: 5fec278316fa9466241b9134c4553bad6db1c1a9) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: remove inappropriate patchPeter A. Bigot
0037-gcc-4.8-PR56797.patch was originally added as an OE backport during 4.8.0. Upstream merged it in 4.8.1, and it was present in 4.9.0. The original patch still applies to 4.9.1 (and presumably 4.8.2), but now is modifying store_multiple_sequence instead of load_multiple_sequence (the two functions are nearly identical). It may or may not be necessary in store_multiple_sequence, but absent a bug report upstream supporting its application in this case, or a least an updated comment and upstream status in the patch, I think this patch should be dropped. (From OE-Core rev: c89443e0f98249b9f9ea33f686c27babe35fd024) Signed-off-by: Peter A. Bigot <pab@pabigot.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-15gcc: recipe whitespace changesPeter A. Bigot
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>
2014-08-15gcc-cross-initial: Use good old bfd linker by defaultKhem Raj
We already indicate our intentions to use ld.bfd by specifying it in configure using --with-ld which works ok unless here where we manually create symlinks to binutils-cross components, when we use ld-is-gold feature default ld points to gold and this symlinking has to be aware of the fact that we configured binutils and gcc-cross to use gold as default ld but gcc-cross-initial uses BFD ld This would be visible when using gold and rebuilding eglibc (From OE-Core rev: 77cab553ee6caa940e21cca46ff134f84e65c171) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-02gcc: Fix gcc-multilib-config comparisonMark Hatle
Fix an issue on a multilib configuration that contains more then 1 multilib. I.e. on MIPS64: DEFAULTTUNE = "mips64" MULTILIBS = "lib32n:mips64_n32 lib32:mips32" While normally you'd use 'libn32', the above is legal. With the startswith code, the system will look to expand the 'lib32' element and find the 'lib32n' instead, and will result in a warning: lib32 doesn't have a corresponding tune. Skipping... (From OE-Core rev: ced919f6013fc0dbb8b8f75f87a8c0a4f416b1fe) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-02gcc: Upgrade 4.9.0 -> 4.9.1Khem Raj
Drop patches which are already available in 4.9.1 (From OE-Core rev: b2ecf4065fa5930b896b8790d153389e400eb0ec) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-08-02gcc-4.9.inc: fix parallel building failureHongxu Jia
The gcc-ar.o, gcc-nm.o, gcc-ranlib.o and errors.o included config.h which was a generated file. But no explicity rule to clarify the dependency. There was potential building failure while parallel make. For gcc-ar.o, gcc-nm.o and gcc-ranlib.o, they were compiled from one C source file gcc-ar.c, we add them to ALL_HOST_BACKEND_OBJS, so the '$(ALL_HOST_OBJS) : | $(generated_files)' rule could work for these objects. For errors.o, it is part of gengtype, and the gengtype generator program is special: Two versions are built. One is for the build machine, and one is for the host. We refered what gengtype-parse.o did (which also is part of gengtype). [YOCTO #6568] (From OE-Core rev: aea4b2d58856226c471922dfa40650cba2f5a36a) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25gcc-4.9.inc: fix parallel building failureHongxu Jia
In subdir 'gcc', Most C source files included config.h which was generated by a rule. But no related prerequisites was added to the C source compiling rule. There was potential building failure while makefile enabled parallel. The C source compiling rule used suffix rule '.c.o', but the suffix rule doesn't support prerequisites. https://www.gnu.org/software/make/manual/html_node/Suffix-Rules.html We used the pattern rule '%.o : %.c' to instead, and add the config.h as its prerequisite We also moved the '%.o : %.c' rule down to the 'build/%.o :' rule, which makes '%.o : %.c' rule doesn't override 'build/%.o :'. [YOCTO #6568] (From OE-Core rev: 86c2483f0fe05fb763d280ae22d70e54cb4bb0bc) Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-25gcc-multilib: Simply/fix MULTILIB_OPTIONS handlingRichard Purdie
MULTILIB_OPTIONS takes the parameters which trigger a given multilib to be selected. It supports *one* option per multilib, '/' separated. Spaces separate options used to generate additional multilib combinations. Adding in all of CFLAGS to this is therefore clearly a really bad idea but how do we fix things? The best option I've come up with so far is a list of whitelist variables to use to trigger the multilibs. Its populated with the standard multilibs we support, anyone setting up an advanced multilib can populate the variable with the correct trigger parameters. This has the advantage of simplifying the code and allowing us to remove the code filtering blocks since there is no longer option duplication. Testing after this change shows a much improved sdk toolchain functionality. (From OE-Core rev: 29202cd1b9d2e5d56e5b9f7a596e44e229c90492) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-19gcc: update *LIBC_* linker relocation reglexTing Liu
* GLIBC_DYNAMIC_LINKER64 reglex does not work for rs6000/linux64.h, update it. * it turns out that UCLIBC_DYNAMIC_LINKER reglex will strip the 32/64 chars from UCLIBC_DYNAMIC_LINKER64/UCLIBC_DYNAMIC_LINKER32, add '\b'. my two PCs: Centos 6.5 (python 2.7.5) and Fedora 13 (python 2.7.3) (From OE-Core rev: a0b408191d64804df1748163060313af31433ac8) Signed-off-by: Ting Liu <ting.liu@freescale.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-07-10gcc: Ensure c++ includes are in /usr/include/c++/${BINV}Richard Tollerton
It was observed that code using STLport 4.6 fails to compile under the SDK with the following error message: .../includes/cstddef:38:46: fatal error: ../4.7.2/cstddef: No such file or directory STLport 4.6 (screwily) assumes that the C++ system headers live in a gcc-versioned subdirectory, for gcc>=3.0; cf http://sourceforge.net/p/stlport/code/ci/STLport-4.6-patch/tree/stlport/config/stl_gcc.h#l269. This assumption is *almost always* valid, because that matches the default setting of --with-gxx-include-dir. We can match that behavior by appending "/${BINV}" to our own --with-gxx-include-dir settings. Natinst-CAR-ID: 446449 Natinst-Reviewboard-ID: 57209 Acked-by: Ken Sharp <ken.sharp@ni.com> Acked-by: Ben Shelton <ben.shelton@ni.com> (From OE-Core rev: 5a2ff3e8f7cd7a47a5ab4e581847ecc4df87fca3) Signed-off-by: Richard Tollerton <rich.tollerton@ni.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-29recipes-devtools: fix segfault in lib32-gcc with "." multilib_dirPaul Gortmaker
When enabling a lib32-gcc in a 64 bit build, without doing any other configuration, the mutilib dir is unspecified, which is represented internally in gcc as "." and as such uncovers an invalid free on a non-malloc'd pointer. As suggested by the gcc folks, simply make sure the "." case is also stored in a malloc'd pointer, so that the intended runtime behaviour of the code remains unchanged. Patch has been accepted by upstream maintainers of gcc. (From OE-Core rev: bf1473d0c1b099b8d919835cc430b99606134aab) Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-25gcc-cross-canadian: Add configure-target-libgccMark Hatle
While we're not going to package the libgcc component as part of the SDK, we do need to generate it to get the unwind, and quadmath headers. Without this change it is not possible to build eglibc or other components that require these headers with the SDK toolchain. (From OE-Core rev: e67b24401a366b20644510703c7140be975869ea) Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-06-17gcc-configure-common: Address problems with gengtypeRichard Purdie
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>
2014-06-01gcc: Clean up configure_prepend and fix for mingwRichard Purdie
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>
2014-06-01gcc, uclibc: Add/Fix Upstream-Status in patchesKhem Raj
(From OE-Core rev: 68a0e34260f884f6fb39aae2d0bad035b2b1d177) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-29gcc: add patch to fix errors with Decimal64 typeAlexandru-Cezar Sardan
[OE-core bug #6270] - https://bugzilla.yoctoproject.org/show_bug.cgi?id=6270 (From OE-Core rev: 8f8ef80131d4aa62a4b106d365a5e7b6273c766d) Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan-KZfg59tc24xl57MIdRCFDg@public.gmane.org> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-13gcc: remove usage of FILESPATHPetter Mabäcker
Fixes [YOCTO #4497] Usage of FILESPATH is discouraged, since it can make recipes harder to bbappend. Instead FILESEXTRAPATHS should be used to extend the path. (From OE-Core rev: 879ff7e931a80fd090db4485b6b6dee8e4c71d30) Signed-off-by: Petter Mabäcker <petter@technux.se> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-08gcc: Handle uclibc linker relocation for multilib supportRichard Purdie
We need to handle the UCLIBC_* linker variables in the same way as we do the GLIBC_* ones to allow uclibc multilib to work properly. (From OE-Core rev: 025ec5958b7e1fd71caa0079ec3c573126b30886) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-07python3/gcc/autoconf: Fix Upstream-Status in some patches I authoredRichard Purdie
(From OE-Core rev: 337798fa5c0a1d1e745a143f6a9f398b07f0628f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-06gcc: Add 4.9 recipesKhem Raj
(From OE-Core rev: f051216ea373f166016b15bbd2a2a6f136430372) (From OE-Core rev: d4573cb750bfde488682244d30266dfe675bac06) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-03gcc-common: Ensure checksums don't change to match old behaviourRichard Purdie
There is a fix about to go into bitbake to ensure that datastores being accessed with a name other than "d" are correctly reflected in checksums. This will cause this function to add in a number of dependencies we don't want. These do need to be properly unravelled in due course but would only really affect multilib builds. For now therefore just exclude the variables as per the old behaviour. (From OE-Core rev: cbc41a573dd3a073e7b862ca9d763ce815e8f927) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-02Add texinfo.bbclass; recipes that use texinfo utils at build-time inherit it.Max Eliaser
The class itself currently does nothing. The idea is to mark all recipes that make use of the texinfo utilities. In the future, this class could be used to suppress the generation/formatting of documentation for performance, explicitly track dependencies on these utilities, and eliminate Yocto's current dependency on the host system's texinfo utilities. (From OE-Core rev: e6fb2f9afe2ba6b676c46d1eb297ca9cc532d405) Signed-off-by: Max Eliaser <max.eliaser@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-05-02gcc-common: Only apply fpu settings to target gccRichard Purdie
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>
2014-05-02gcc-cross: Drop TARGET_CC_ARCHRichard Purdie
Since we no longer build target libs within gcc-cross, we can drop the TARGET_CC_ARCH flags and hence make it independent of tune. (From OE-Core rev: 74d8866814aec520822518cc4cb8a942f7069bf7) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-30gcc: Drop ARCH_FLAGS_FOR_TARGET usageRichard Purdie
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>
2014-04-30gcc-common/gcc-configure-common: Move gnu-configize to its own shared taskRichard Purdie
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>
2014-04-30gcc-target: Limit compile to host targets, don't build runtimes.Richard Purdie
Currently the gcc builds are building copies of the target libraries that we never use (it isn't installed in do_install). This is a rather pointless waste of cpu time. Instead just compile the host targets. Comparing the package output of this compared to a previous build shows that the unwind.h header is missing since its provided by gcc. Fix this simply by copying it in. (From OE-Core rev: 19448a50c106684ee7e3862f759418c982363a29) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-30binutils/gcc/gdb: Add TARGET_ARCH to PN for all cross recipesRichard Purdie
This allows them to co-exist together in the native sysroot, with one set of cross tools per target architecture. (From OE-Core rev: a2c5509520d5c3e082f55844e6545d0309565f8f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-25Globally replace 'base_contains' calls with 'bb.utils.contains'Otavio Salvador
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>
generated by cgit 1.2.3-korg (git 2.39.0) at 2024-05-03 21:28:44 +0000