| Age | Commit message (Collapse) | Author |
|---|
|
The arm toolchain has a "-gnueabi" suffix, but aarch64 doesn't,
this makes multilib sdk doesn't work, for example:
MACHINE = qemuarm64
require conf/multilib.conf
MULTILIBS = "multilib:lib32"
DEFAULTTUNE_virtclass-multilib-lib32 = "armv7at-neon"
$ bitbake core-image-minimal -cpopulate_sdk
Then extract SDK, the
environment-setup-armv7a-vfp-neon-pokymllib32-linux-gnueabi
doesn't work since:
* The CC is arm-pokymllib32-linux-gnueabi-gcc
which doesn't exist, the patch for cross-canadian.bbclass
fixes problem.
* Need aarch64-poky-linux/usr/lib/arm-poky-linux-linux-gnueabi
which doesn't exist, the patch for libgcc-common.inc fixes the
problem.
[YOCTO #8616]
Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
Robert Yang
Juro Bystricky
Richard Purdie
Mark Hatle