diff options
| author | Richard Purdie <richard.purdie@linuxfoundation.org> | 2016-09-28 15:59:34 +0100 |
|---|---|---|
| committer | Richard Purdie <richard.purdie@linuxfoundation.org> | 2016-09-29 00:32:58 +0100 |
| commit | bcddc3e7eff138add031bc9c9728be5a42fa62ef (patch) | |
| tree | 73ff6048272e25222116d624f7bcd7fadd550754 /meta/recipes-devtools/python/python-3.5-manifest.inc | |
| parent | 2e15b478343c6703c37b9a45e61c9de200d98027 (diff) | |
| download | openembedded-core-bcddc3e7eff138add031bc9c9728be5a42fa62ef.tar.gz openembedded-core-bcddc3e7eff138add031bc9c9728be5a42fa62ef.tar.bz2 openembedded-core-bcddc3e7eff138add031bc9c9728be5a42fa62ef.zip | |
cross-canadian/libgcc-common: Fixes for arm multilib
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>
Diffstat (limited to 'meta/recipes-devtools/python/python-3.5-manifest.inc')
0 files changed, 0 insertions, 0 deletions