summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc
Commit message (Collapse)AuthorAgeFilesLines
* recipes-devtools: fix segfault in lib32-gcc with "." multilib_dirPaul Gortmaker2014-06-292-0/+67
| | | | | | | | | | | | | | | | | | 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>
* gcc-cross-canadian: Add configure-target-libgccMark Hatle2014-06-251-3/+10
| | | | | | | | | | | | 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>
* 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-013-41/+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, uclibc: Add/Fix Upstream-Status in patchesKhem Raj2014-06-011-1/+1
| | | | | | | (From OE-Core rev: 68a0e34260f884f6fb39aae2d0bad035b2b1d177) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: add patch to fix errors with Decimal64 typeAlexandru-Cezar Sardan2014-05-292-0/+99
| | | | | | | | | | [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>
* gcc: remove usage of FILESPATHPetter Mabäcker2014-05-132-4/+4
| | | | | | | | | | | | 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>
* gcc: Handle uclibc linker relocation for multilib supportRichard Purdie2014-05-083-99/+143
| | | | | | | | | 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>
* python3/gcc/autoconf: Fix Upstream-Status in some patches I authoredRichard Purdie2014-05-071-1/+1
| | | | | | (From OE-Core rev: 337798fa5c0a1d1e745a143f6a9f398b07f0628f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Add 4.9 recipesKhem Raj2014-05-0654-0/+6325
| | | | | | | | | (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>
* gcc-common: Ensure checksums don't change to match old behaviourRichard Purdie2014-05-031-1/+1
| | | | | | | | | | | | | | | 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>
* Add texinfo.bbclass; recipes that use texinfo utils at build-time inherit it.Max Eliaser2014-05-021-1/+1
| | | | | | | | | | | | | 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>
* gcc-common: Only apply fpu settings to target gccRichard Purdie2014-05-023-2/+4
| | | | | | | | | | | | | 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-cross: Drop TARGET_CC_ARCHRichard Purdie2014-05-021-1/+1
| | | | | | | | | 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>
* gcc: Drop ARCH_FLAGS_FOR_TARGET usageRichard Purdie2014-04-304-11/+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-302-1/+12
| | | | | | | | | | | | | 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>
* gcc-target: Limit compile to host targets, don't build runtimes.Richard Purdie2014-04-301-0/+8
| | | | | | | | | | | | | | 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>
* binutils/gcc/gdb: Add TARGET_ARCH to PN for all cross recipesRichard Purdie2014-04-3010-11/+20
| | | | | | | | | 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>
* Globally replace 'base_contains' calls with 'bb.utils.contains'Otavio Salvador2014-04-252-2/+2
| | | | | | | | | | | 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>
* Globally replace oe.utils.contains to bb.utils.containsOtavio Salvador2014-04-251-2/+2
| | | | | | | | | | | BitBake has the exact same code as oe.utils.contains so there's no reason to duplicate it. We now rely on the bb.utils.contains code for metadata. (From OE-Core rev: 93499ebc46547f5bf6dcecd5a786ead9f726de28) Signed-off-by: Otavio Salvador <otavio@ossystems.com.br> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-cross-initial: Separate out libgcc-initialRichard Purdie2014-04-253-2/+29
| | | | | | | | | | Its useful to separate out the native (cross) binaries from the target compilation. We already do this for libgcc, this now takes the same approach for -initial. (From OE-Core rev: 8a2aaf8b6bdca2d28c0047093c7f668750d57666) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-cross: Improve handling of unwind.hRichard Purdie2014-04-253-2/+3
| | | | | | | | | | | | | | Rather than building the whole of libgcc to obtain the unwind.h header file, simply configure it and then install the file. This avoids copying chunks of data around when we don't need to and building the same thing twice. After doing this we need to make sure the target build directory exists in the libgcc case since it will no longer be created automatically. (From OE-Core rev: 459e4dc25462771038459567c22e87d4cd38b117) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgcc: Spit out common code into libgcc-common.incRichard Purdie2014-04-252-131/+137
| | | | | | | | | Prepare the ground for the creation of libgcc-initial by splitting common libgcc code into a libgcc-common.inc file. (From OE-Core rev: 7c9f4a22d5c14d768be872beb9fc798163d6d204) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Convert to use hardlinkdirRichard Purdie2014-04-254-6/+4
| | | | | | (From OE-Core rev: 204bc1f39030a3c0dd3eadadabb013aca8bb9cc6) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Fix a race over unwind.hRichard Purdie2014-04-102-0/+34
| | | | | | | | | There are two places unwind.h is installed, even by the Makefile's admission. Disable one of them to prevent build failure races. (From OE-Core rev: d3b02218dcfedda8e4efb43b8fa6d13af8d91f78) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: enable multilib setup for powerpc64 archAlexandru-Cezar Sardan2014-04-041-0/+2
| | | | | | | (From OE-Core rev: 99fadf2ff9f4379121fde6477383e7574519fba4) Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-target: remove infodirMartin Jansa2014-04-041-0/+4
| | | | | | | | | | | | * it uses autotools but doesn't call autotools_do_install * fixes QA warning: gcc-4.8.2: The /usr/share/info/dir file is not meant to be shipped in a particular package. (From OE-Core rev: 0b62f8b012d8a128f34bd85a26aa97ea939cbf64) Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: changed multilib options handlingAlexandru-Cezar Sardan2014-04-011-4/+20
| | | | | | | | | | | | | Duplicate parameters in the tune args are repeated in the MULTILIB_OPTIONS variable. This leads to incorrect configurations if the order of the parameters is bad. (Eg. "mhard-float m32/mhard-float m64" leads to an incorrect config) This patch finds the common parameters and removes the duplicates. (From OE-Core rev: 90dc31c24adfa8e916a9c475ae1afc58ad179dfb) Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: Build libatomicCosmin Paraschiv2014-03-211-1/+11
| | | | | | | | | | | GCC 4.8 includes a new runtime library, libatomic, which supports atomic operations not supported by hardware or the OS. Build it, so other packages can link against it, if needed. (From OE-Core rev: a4dd6dfccee0be50d3addce3dd1bf903e051ad5a) Signed-off-by: Cosmin Paraschiv <cosmin.paraschiv@freescale.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-cross: don't use oe.path.relativeRoss Burton2014-03-072-2/+2
| | | | | | | | | | | Instead of using oe.path.relative, use the Python Standard Library function os.path.relpath. (From OE-Core rev: 90c3a0401c566e26d89a5c0410b2a51fe27b95b2) Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgcc: make sure symlinks are created in a valid directoryAlexandru-Cezar Sardan2014-03-071-1/+1
| | | | | | | | | | | | | | When adding extra symlinks, we have to make sure that the directory that the links are created in is valid. Added a check for this. This is an incremental addition to commit 97f2a81d6796ddaf7bbaab86c2ab9039673c732c (From OE-Core rev: ea297e807f4f84c281e0f8c6c4470ee3f3fa949b) Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Add upstream fix for gcc bug 58595Tom Zanussi2014-03-072-1/+134
| | | | | | | | | | | | Fix for internal compiler error hit when building lttng-tools_4.2.0: kernel-consumer.c:324:1: internal compiler error: in gen_movsi, at config/arm/arm.md:5539 (From OE-Core rev: ec1d5bdf4cc0a7a3e4747b42b7b95805752bea07) Signed-off-by: Tom Zanussi <tom.zanussi@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Enable SPE & AltiVec generation on powepc*linux target.Alexandru-Cezar Sardan2014-02-283-1/+66
| | | | | | | | | | | | | | | [ADT bug #5761] -- https://bugzilla.yoctoproject.org/show_bug.cgi?id=5761 Also this patch adds symlinks to libgcc such that a GCC configured by passing the target parameter without LIBCEXTENSION and ABIEXTENSION specifiers to find the correct startup files from a libgcc configured with these variables. (From OE-Core rev: 97f2a81d6796ddaf7bbaab86c2ab9039673c732c) Signed-off-by: Alexandru-Cezar Sardan <alexandru.sardan@freescale.com> Signed-off-by: Saul Wold <sgw@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Include patch scheduled for GCC 4.8.3 to fix epilogue on ARMHolger Hans Peter Freyther2014-01-312-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | GCC 4.8.0, 4.8.1 and 4.8.2 can generate broken epilogues for the ABI used by the kernel. Apply the patch that is included for GCC 4.8.3 from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854. The issue was found on Yocto/Dora and the patch should be backported to this branch. A kernel built with Dora's GCC 4.8.1 misbehaved on: while true; do (for i in `seq 1 100`; do echo "Log message... $RANDOM"; done) | logger; done busybox's syslogd would from time to read a huge negative value and then exit, strace would get stuck waiting on a syscall. After this patch it appears to work better. (From OE-Core rev: 3004eb3b7ee5fd8dfe9c4e5749b4e125d0bd4b59) Signed-off-by: Holger Hans Peter Freyther <holger@moiji-mobile.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Drop 4.7.2 version since 4.8 is stable nowRichard Purdie2014-01-0255-8067/+0
| | | | | | | | | We've had 4.8 around for a while now, I'm not aware of any issues with it so we can drop the older 4.7 version. (From OE-Core rev: 15685dccd37f7636bbdd56af04a9dbc9b7595612) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Basic recipe formatting fixesPaul Eggleton2014-01-022-2/+2
| | | | | | | | | Fix statement indenting and spacing issues that I happened to notice. (From OE-Core rev: d11e297b007aba625b398c52952ec929c3b02b83) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* Replace one-line DESCRIPTION with SUMMARYPaul Eggleton2014-01-022-2/+2
| | | | | | | | | | | | | | A lot of our recipes had short one-line DESCRIPTION values and no SUMMARY value set. In this case it's much better to just set SUMMARY since DESCRIPTION is defaulted from SUMMARY anyway and then the SUMMARY is at least useful. I also took the opportunity to fix up a lot of the new SUMMARY values, making them concisely explain the function of the recipe / package where possible. (From OE-Core rev: b8feee3cf21f70ba4ec3b822d2f596d4fc02a292) Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sstate: Convert to use ':' as a filename sperator and use SSTATE_SWSPEC globallyRichard Purdie2013-12-201-1/+1
| | | | | | | | | | | | | | | | | | | Currently the code has problems differentiating between "gcc-cross" and "gcc-cross-initial" sstate files. We could add in a ton of special casing but tests show this isn't scaling well. Using a more unique separator resolves the issue. The choice of which separator to use is a hard one. We need something which isn't commonly used in PN, PV, PR, *_OS and *_ARCH which rules out '-', '_' and it needs to work ok with webservers/http which makes ';' and '%' harder. The change also sets SSTATE_SWSPEC globally since writing out differently named siginfo files for the fetch/unpack/patch tasks is a waste of diskspace, the hashes match for all PN in the majority of cases and if they don't, its not a big issue as the hash is different. This makes the results from sstate debugging more understandable. (From OE-Core rev: 6f823a23c5f1d0ffa0a27db1c1bc1907de788505) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* sstate/gcc: Fix shared workdir handling for siginfo filesRichard Purdie2013-12-181-0/+1
| | | | | | | | | | | | | | | | | | | | | For a shared workdir, any one of the fetch/unpack/patch tasks may run yet the PN and architecture fields in SSTATE_PKGSPEC may differ. This makes looking up the appropriate siginfo file near impossible. I've tried several different ways of resolving this and this is the neatest solution I could find, its still rather ugly. I believe the usefulness of better sstate debugging outweighs the ugliness of the code. This patch also changes the sstate_checkhashes() code to look for siginfo files rather than the actual sstate packages themselves. This means the function can be used in other contexts to find info files for tasks that may not have sstate data. It is assumed that sstate mirrors will have both files available. This is done to allow bitbake to query whether tasks have matching signatures in sstate directories or not. (From OE-Core rev: 068e4289b597699cbff2dfde44ba833af4535281) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-4.7/gcc: disable sdt from configure.ac to keep compatibility with configureRobert Yang2013-12-181-5/+39
| | | | | | | | | | | | | | | | | We had disabled the sdt from configure, let's also disable it from confgure.ac to keep them compatible. BTW, the libstdc++-v3 of gcc-4.7 doesn't use the sdt, so we don't need to edit libstdc++-v3/configure as gcc-4.8. NOTE, this commit edit the patch gcc-4.7/disablesdt.patch directly. [YOCTO #5657] (From OE-Core rev: 452c6afc3883b0304e06eb1764614348fb6599c8) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-4.8/libstdc++-v3: disable sdtRobert Yang2013-12-181-6/+74
| | | | | | | | | | | | | | | | | | | | | | We may meet such an error when building gcc/libstdc++-v3: gcc-4.8.1/libstdc++-v3/libsupc++/unwind-cxx.h:41:21: fatal error: sys/sdt.h: No such file or directory We already have a patch to disable the sdt for gcc, we also need disable it for libstdc++-v3. BTW, we need edit both configure.ac and configure to make them keep compatible. NOTE, this commit edit the patch gcc-4.8/0031-Disable-sdt.patch directly. [YOCTO #5657] (From OE-Core rev: 32854af3cc6c0626620e827dc1915f61c51250b8) Signed-off-by: Robert Yang <liezhi.yang@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-crosssdk.inc: Fix missing dependencies (such as libmpc-native)Richard Purdie2013-12-161-1/+1
| | | | | | | | Without this sstate builds can fail with missing dependencies. (From OE-Core rev: f92ebf78d94cb8f4010f8d444d1d0336c1fb1341) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Allow fortran to build successfully in 4.8Richard Purdie2013-12-054-1/+84
| | | | | | | | | | | | | | | | | | | | gcc 4.8 fortran presents some challenges: * libquadmath headers need to be in the libexec include dir. It turns out to be easiest just to manually do this. * libgfortran configure needs libquadmath to be compiled. This means a separate recipe is needed (the alternative is gross hacks) * the libtool uses to link libgfortran doesn't have our improved rpath handling and puts bogus RPATHS into the libraries. We can avoid this by tweaking libtool with sed. This patch resolves those issues. Any user of fortran does need to DEPEND on libgfortran in order to trigger it to build but this shouldn't be a major issue. (From OE-Core rev: a5e7ee5770b9e0cf719c573efffd874440f74289) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* classes/recipes: More optimal DISTRO_FEATURES referencesRichard Purdie2013-12-051-2/+2
| | | | | | | | | Using the contains function results in more optimal sstate checksums resulting in better cache reuse as we as more consistent code. (From OE-Core rev: 9c93526756e7cbbff027c88eb972f877bcb1f057) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-cross-canadian: Fix fortran buildRichard Purdie2013-12-021-0/+1
| | | | | | | | | When fortran was enabled, builds were failing due to a extra files. For now we can remove these and avoid the build failure. (From OE-Core rev: 2e60ef7fe63974e443a9ddc25c5eb4249ec37963) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* base/gcc-common: Ensure umask setting is consistent for shared workdirRichard Purdie2013-11-291-0/+1
| | | | | | | | | | | | | gcc has cross and target components with a shared workdir. The unpack umask settings need to match for all of these. We need to use strings in each case to ensure the sstate code matches them correctly. This patch tweaks various things to ensure the change adding the unpack umask change doesn't break the compiler builds. (From OE-Core rev: 67162438ee9c402b23c32853af9d313949eb6e4a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Upgrade to 4.8.2Khem Raj2013-11-222-97/+5
| | | | | | | | | | | | | The details for bug fixes between 4.8.1 and 4.8.2 is here http://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&resolution=FIXED&target_milestone=4.8.2 Remove the patches that were applied upstream (From OE-Core rev: 3e5922a2ed250361e76ea616baba2f8d9332e20f) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-common: Enable building multiarch mips gccLei Liu2013-11-121-0/+1
| | | | | | | | | | | | | | MIPS gcc is not configured with multiarch enabled. This causes compiler generates local label with $ prefix, which is specified in default o32 abi. It is not recognized as local symbol by n64 assembler, so we get a lot of unexpected external symbols. We should configure MIPS gcc with --enable-targets=all, as for other archs. (From OE-Core rev: c210393b3e0c54606493e311d7c2040efebc4dcd) Signed-off-by: Lei Liu <lei.liu2@windriver.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cross-canadian: Handle powerpc linux verses linux-gnuspeRichard Purdie2013-10-301-1/+4
| | | | | | | | | | | | | | | | | PowerPC toolchains can use the OS "linux" or "linux-gnuspe". This patch links them together so the one cross-canadian toolchain can support both. GCC_FOR_TARGET is set for the GCC recipe as otherwise configure can pick up an incorrect value. [YOCTO #5354] (From OE-Core rev: a1d6331238982b0c5d39b0a18794f6654b00d46a) 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: Fix strange C++ repo issuesRichard Purdie2013-10-142-0/+54
| | | | | | (From OE-Core rev: 9f6c4edf40963d1f3fb9f7e2d2b7a866aa1afe57) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-14 14:50:41 +0000