summaryrefslogtreecommitdiff
path: root/meta/recipes-devtools/gcc/libgcc-common.inc
AgeCommit message (Collapse)AuthorFiles
2016-10-08libgcc-common.inc: Fix broken symlinks for multilib SDKJuro Bystricky1
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] Signed-off-by: Juro Bystricky <juro.bystricky@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-09-29cross-canadian/libgcc-common: Fixes for arm multilibRichard Purdie1
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-07-12libgcc: remove duplicate configure optionsAndre McCurdy1
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 Signed-off-by: Andre McCurdy <armccurdy@gmail.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2016-05-13libgcc: Ensure that gcc configure options are passed to libgcc tooKhem Raj1
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 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-05-13libgcc: Ensure that gcc configure options are passed to libgcc tooKhem Raj1
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 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2016-02-28gcc: use relative path for configure scriptHongxu Jia1
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] Signed-off-by: Hongxu Jia <hongxu.jia@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2015-08-30libgcc-common.inc: overrides for libc-baremetalJuro Bystricky1
Added TCLIBC="baremetal" specific overrides. (From OE-Core rev: 044f989b34e46f919e6b28860d7a1b396b2c3808) 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>
2015-07-31libgcc: Fix symlink handling in cross-arch multilib casesRichard Purdie1
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). Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2015-01-28gcc/libgcc-common.inc: Add missing 'fakeroot' to two tasksMark Hatle1
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. Signed-off-by: Mark Hatle <mark.hatle@windriver.com> Signed-off-by: Ross Burton <ross.burton@intel.com>
2014-12-03gcc: Rework shared workRichard Purdie1
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-30binutils/gcc/gdb: Add TARGET_ARCH to PN for all cross recipesRichard Purdie1
This allows them to co-exist together in the native sysroot, with one set of cross tools per target architecture. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-25gcc-cross: Improve handling of unwind.hRichard Purdie1
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-25libgcc: Spit out common code into libgcc-common.incRichard Purdie1
Prepare the ground for the creation of libgcc-initial by splitting common libgcc code into a libgcc-common.inc file. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>