summaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/gcc/libgcc-common.inc
Commit message (Collapse)AuthorAgeFilesLines
* tclibc-newlib: Adds a new TCLIBC variant to build with newlib as C libraryAlejandro Enedino Hernandez Samaniego2018-06-151-0/+5
| | | | | | | | | | | | | | | | | | | | | | This patch adds the posibility to build using TCLIBC=newlib. It allows users to build baremetal applications with the use of a C library. Newlib is a lightweight C library meant to be used on embedded systems, it is meant to be easily portable for new platforms and to provide basic functionality on them, by design, it provides stubs for some of these core functions declared as weak, so they can be built correctly and then linked against some other library which provides specifics about the platform being used if need be, libgloss takes care of these in some cases, but it can also be extended, this patch also allows the user to easily add other libraries to it by adding them to NEWLIB_EXTENDED for this specific reason. (From OE-Core rev: 9f0570351a7b0877aa50efff5fe9a9ef368cb38f) Signed-off-by: Alejandro Enedino Hernandez Samaniego <alejandr@xilinx.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Clean up unnecessary variable confusionRichard Purdie2017-01-261-6/+3
| | | | | | | | | | | | | | SDKPKGSUFFIX could only really be "nativesdk" and TARGET_SYS never contains that so the code manipulating TARGET_SYS is pointless. I suspect this once worked against MULTIMACH_TARGET_SYS which would be a different question but it no longer does. Its been cut and pasted everywhere. This patch cleans up the variable references to make things a little more readable. (From OE-Core rev: 5599cb72d17bce2ba6e2be16ef64d9a388bcfb25) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: Split builddir saving into its own sstate taskRichard Purdie2017-01-261-1/+2
| | | | | | | | | | | | | | | | | | When we stashed the gcc build directory for use in generating the various runtimes we were being lazy and just used the staging directory. With recipe specific sysroots this means we're copying a large chunk of data around with the cross compiler which we don't really need in most cases. Separate out the data into its own task and inject this into the configure step. We have to do that here since autotools will wipe out ${B} if it thinks we're rebuilding and we therefore have to time its recreation after that. This also takes the opportunity to remove some pointless (as far as I can tell) conditionals from the do_install code. (From OE-Core rev: dcf15ccf3cc9d55e77228ba8d526f967fc9791b4) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgcc-common: Don't apply symlinks for nativesdkRichard Purdie2016-12-221-0/+3
| | | | | | | | | | nativesdk-libgcc doesn't need a symlink into the target space and if we do this sstate installation of the recipe can fail depending on whether it races with the cross-canadian toolchains. (From OE-Core rev: b2c1e1fe4221862e0dbf5d08960f0d0228e47c72) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* meta: remove True option to getVar callsJoshua Lock2016-12-161-19/+19
| | | | | | | | | | | | | 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>
* libgcc-common.inc: Fix broken symlinks for multilib SDKJuro Bystricky2016-10-091-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | This patch fixes broken "32" symlinks for multilib settings: MACHINE = "qemuarm64" require conf/multilib.conf MULTILIBS = "multilib:lib32" DEFAULTTUNE_virtclass-multilib-lib32 = "armv7a" and MACHINE = "qemux86-64" require conf/multilib.conf MULTILIBS = "multilib:libx32" DEFAULTTUNE_virtclass-multilib-libx32 = "x86-64-x32" [YOCTO#8642] [YOCTO#10380] (From OE-Core rev: 2810671a0f96776c135137f27a5ca52194ddd692) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* cross-canadian/libgcc-common: Fixes for arm multilibRichard Purdie2016-09-301-4/+7
| | | | | | | | | | | | | | | | | | | | | | | Arm is unusual in that we force it to "linux-gnueabi" and "linux" doesn't build. This was causing problems for multilib configurations which were assuming "linux" was the default compiler rather than linux-gnueabi. This change does two things, ensures symlinks are generated for linux-gnueabi and also adapts the libgcc code to account for the difference on arm. It still needs to immediately expand/save TARGET_VENDOR but we defer deciding what TARGET_OS should be until we know TARGET_ARCH (which the multilib code may change). [YOCTO #8642] Note that sanity tests of a 32 bit arm multilib still break due to issues with the kernel headers on a mixed bit system. This looks to be a general headers issue for the platform though and a different type of bug. (From OE-Core rev: bcddc3e7eff138add031bc9c9728be5a42fa62ef) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgcc: remove duplicate configure optionsAndre McCurdy2016-07-121-7/+0
| | | | | | | | | | | | | The original fix [1] was made redundant by the followup [2]. [1] http://git.openembedded.org/openembedded-core/commit/?id=d774bb2d10f2c05900f87dcc53f073433ca02121 [2] http://git.openembedded.org/openembedded-core/commit/?id=d7799a17d5e802db3f8d16bdc824aae81538e675 (From OE-Core rev: 2f6e42068a0af01034e738daa6a7ce1a3bcb434d) 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>
* libgcc: Ensure that gcc configure options are passed to libgcc tooKhem Raj2016-05-131-1/+1
| | | | | | | | | | | | libgcc uses certain options from EXTRA_OECONF as well, curently we are ignoring them, as a result we do not configure libgcc to match cross gcc in some cases e.g. ppc/musl should have used 64bit long doubles but it went for 128-ldbls which is default, works on glibc but not on musl (From OE-Core rev: d7799a17d5e802db3f8d16bdc824aae81538e675) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgcc: Ensure that gcc configure options are passed to libgcc tooKhem Raj2016-05-131-0/+7
| | | | | | | | | | | | libgcc uses certain options from EXTRA_OECONF as well, curently we are ignoring them, as a result we do not configure libgcc to match cross gcc in some cases e.g. ppc/musl should have used 64bit long doubles but it went for 128-ldbls which is default, works on glibc but not on musl (From OE-Core rev: d774bb2d10f2c05900f87dcc53f073433ca02121) Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc: use relative path for configure scriptHongxu Jia2016-02-281-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The absolute path (/path/to/configure) caused __FILE__ to be an absolute path. If 'assert' invoked, it uses __FILE__, and build path would be in elf files. In assert.h ... .# define assert(expr) \ ((expr) \ ? __ASSERT_VOID_CAST (0) \ : __assert_fail (__STRING(expr), __FILE__, __LINE__, __ASSERT_FUNCTION)) ... Which triggered buildpaths QA issue: ... | libgcc-5.3.0: File work/core2-64-poky-linux/libgcc/5.3.0-r0/packages-split/ libgcc-dev/usr/lib64/x86_64-poky-linux/5.3.0/libgcc.a in package contained reference to tmpdir [buildpaths] ... Use relative path to run configure can fix the problem. [YOCTO #7058] (From OE-Core rev: b806e4c004a7e10461fe7428fc130a5aa2528039) 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>
* libgcc-common.inc: overrides for libc-baremetalJuro Bystricky2015-08-301-0/+6
| | | | | | | | | | | | Added TCLIBC="baremetal" specific overrides. (From OE-Core rev: 044f989b34e46f919e6b28860d7a1b396b2c3808) (From OE-Core rev: 53153b9fd1ba56ca3df19d895d365054a5ecd50f) Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Ross Burton <ross.burton@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* libgcc: Fix symlink handling in cross-arch multilib casesRichard Purdie2015-08-011-13/+13
| | | | | | | | | | | | | | | | | | | | | The symlink being generated needs to match both the current arch (e.g. mips or mips64) but also use the underlying TARGET_SYS without multilib extensions to TARGET_VENDOR or extensions to TARGET_OS. The way multilib changes TARGET_VENDOR meant this code did not have a way of removing that change. The method of removing some TARGET_OS suffixes was also not working. By using immediate expansion to run this code, we can run before the multilib code changes it and get the original values. We then use the *current* TARGET_ARCH value in case this does get changed by the multilib since we need to point at the right compiler (32 bit one for 32 bit code). (From OE-Core rev: 89cd6c244b6bc0a8cb52ec84d378d5b305df030f) Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
* gcc/libgcc-common.inc: Add missing 'fakeroot' to two tasksMark Hatle2015-01-291-2/+2
| | | | | | | | | | | | 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) 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: Rework shared workRichard Purdie2014-12-031-0/+2
| | | | | | | | | | | | | | | | | | | | | 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>
* 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-cross: Improve handling of unwind.hRichard Purdie2014-04-251-0/+1
| | | | | | | | | | | | | | 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-251-0/+135
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>
generated by cgit v1.2.3-54-g00ecf (git 2.39.0) at 2024-11-14 11:11:23 +0000