summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/gcc-runtime.inc
Commit message (Collapse)AuthorAgeFilesLines
* gcc-runtime.inc: provide libquadmathIoan-Adrian Ratiu2016-01-201-1/+3
| | | | | | | | | | | libgfortran's build fails with "ld: cannot find -lquadmath" unless libquadmath is added to gcc-runtime's RUNTIMETARGET (From OE-Core rev: 80333155db8fa53fb52898c4312daa656de89c3b) Signed-off-by: Ioan-Adrian Ratiu <adrian.ratiu@ni.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: switch to removal override syntax to modify CXXFLAGSJoshua Lock2016-01-191-1/+1
| | | | | | | | | | | | The use of immediate expansion can cause issues when trying to override variables, further the removal override syntax is clearer than oe_filter_out () — switch to using removal override syntax instead. (From OE-Core rev: 19995268da27af93af6f718fab0434178a1079ce) Signed-off-by: Joshua Lock <joshua.g.lock@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc5: Upgrade gcc-5.2 -> gcc-5.3Khem Raj2015-12-221-2/+2
| | | | | | | | | | | | Minor bugfix upgrade to gcc 5.3 for detailed list of fixes in 5.3 see https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED&list_id=132738&resolution=FIXED&target_milestone=5.3 (From OE-Core rev: 8b664a7d6bba89a8221d7fd1a52915fef0002d71) 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-runtime: Add multilib C++ header mappingRichard Purdie2015-09-281-0/+3
| | | | | | | | | | | The SDK was unable to find the C++ header pieces correctly since its using a generic compiler, not one specifically targeting the multilib vendor prefix. This adds in the right mapping to ensure multilib SDKs work as expected. This fixes multilib SDK automated tests. (From OE-Core rev: 823ce9555ee78aa460d0560b8fd9b309cfd36997) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: Remove libgfortran data from receipeDaniel Dragomir2015-01-231-15/+0
| | | | | | | | | | | | | | | | | | | | | | | 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) 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>
* gcc runtime: specify license on a per package basisJoe Slater2014-12-191-0/+31
| | | | | | | | | | | | | It can be alarming to attempt to exclude GPLv3 from an image but find that libstdc++ and libgcc still show it. We indicate the license for each package to show libraries that really are just GCC-3.0-with-GCC-exception. (From OE-Core rev: 5db535a91edea439c14e75726acd23e64bb1e2ea) Signed-off-by: Joe Slater <jslater@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: poison default sysroot pathRichard Purdie2014-10-301-1/+1
| | | | | | | | | | | | | | | | | | | Various pieces of the code assume that the --sysroot option gets passed into the compiler tools. By having a "sane" default, we don't always spot when this occurs and this can later show up as breakage in sstate, or in usage of the external toolchain. We've long since talked about poisoning the default such that it will break unless the correct option is specified. This patch does just that. If this patch causes something to fail to build, it most likely means the various compiler flags and commands are not correctly being passed through to the underlying piece of software and that there is a real problem that needs fixing, its not the fault of this patch. (From OE-Core rev: 04b725511a505c582a3abdf63d096967f0320779) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-runtime: Add linux-gnuspe symlink to fix c++ headersRichard Purdie2014-10-061-0/+3
| | | | | | | | | | | | | | 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>
* gcc: remove outdated configuration optionPeter A. Bigot2014-08-151-1/+0
| | | | | | | | | | --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>
* gcc: recipe whitespace changesPeter A. Bigot2014-08-151-75/+78
| | | | | | | | | | | 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: Ensure c++ includes are in /usr/include/c++/${BINV}Richard Tollerton2014-07-101-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* gcc: Drop ARCH_FLAGS_FOR_TARGET usageRichard Purdie2014-04-301-2/+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>
* binutils/gcc/gdb: Add TARGET_ARCH to PN for all cross recipesRichard Purdie2014-04-301-1/+1
| | | | | | | | | 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>
* gcc: Convert to use hardlinkdirRichard Purdie2014-04-251-1/+1
| | | | | | (From OE-Core rev: 204bc1f39030a3c0dd3eadadabb013aca8bb9cc6) 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: Allow fortran to build successfully in 4.8Richard Purdie2013-12-051-1/+1
| | | | | | | | | | | | | | | | | | | | 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>
* gcc-runtime: Add packaging for libgfortran (and also tweak others)Richard Purdie2013-09-061-5/+26
| | | | | | | | | Add packaging for libgfortran and libquadmath as well as tweak the packaging for libmudflap since it was broken. (From OE-Core rev: 8a726d14a345ef35c6d8d8e369bf3691cee879bf) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc-*-runtime.inc: Fold configuration into gcc-runtime.incRichard Purdie2013-08-231-0/+145
(From OE-Core rev: 9cdfd55de8dbdea3d5e5ed25fbc67d1f198a069a) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-12 00:38:15 +0000