The old TARGET_OS check doesn't work, as it only checks for uclibc and musl at
the end, while TARGET_OS is usually "linux-musleabi", uclibc has been deprecated
and new options like "newlib" and "baremetal" were added. Plus it only works for
the target, but not SDK. Switch to simply checking for TCLIBC = glibc.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Ross Burton <ross.burton@arm.com>
To be used by SDK packaging for binutils cross.
This code is upstreamed from meta-arago layer.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Ross Burton <ross.burton@arm.com>
This binary toolchain is also available for aarch64, so support fetching
that too.
Change-Id: I6206d8a9b4221d8461070d0cb7fff40c712c3df0
Signed-off-by: Ross Burton <ross.burton@arm.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
This binary toolchain is also available for aarch64, so support fetching
that too.
Change-Id: I788fcd95c30b97f095593059e85de9a99710be05
Signed-off-by: Ross Burton <ross.burton@arm.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
When building nativesdk or target forms of these recipes more QA tests
are executed, which produce more warnings. As these recipes are quite
special, skip more tests:
- arch, as we ship ilp32 binaries in aarch64 packages
- dev-so, as the entire toolchain is put into a single package
Change-Id: Ib72b224749642c912278f0d5601fe04b30afc25f
Signed-off-by: Ross Burton <ross.burton@arm.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Some of the toolchains are available in more than just x86-64, so move
the COMPATIBLE_HOST assignment out of the include and into the recipes.
Change-Id: I10977593935bc7dc50196132d43541aed585cc18
Signed-off-by: Ross Burton <ross.burton@arm.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
The GFDL license statement isn't a good choice for the GCC license
checksum, instead use Copying.html from the documentation.
Change-Id: I265bb0add795f3de40f49f8c31127ac9215d2566
Signed-off-by: Ross Burton <ross.burton@arm.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
These recipes all used a common include
external-arm-toolchain-x86host.inc, but that name isn't very meaningful:
the recipes are for x86-64, there typically are more than x86-64
binaries available, and it's not for an external toolchain but
integrating a binary toolchain.
Rename the include to arm-binary-toolchain.inc, as they're all the Arm
binary toolchain.
Change-Id: I59f5faa7373686958e226db0aa68e7880d36400e
Signed-off-by: Ross Burton <ross.burton@arm.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Layers are only being tested against dunfell and gatesgarth. Limit the
layer compatibility to only those versions.
Change-Id: Ib4df617d8991b1c9096b8feaad9228174319bf11
Signed-off-by: Jon Mason <jon.mason@arm.com>
Adds Arm Clang recipe to pull down the prebuilt Armcompiler for
compiling for Cortex-A, Cortex-R, and Cortex-M processors from ARM.
This toolchain is required to build Arm trusted-firmware-m with
different optimisations than GCC can provide for M-class processors.
This recipe is based on the gcc-arm-none-eabi-native toolchain.
Change-Id: I0110f899ec6e5b355c5b7661db1f4aa0e254e7e2
Signed-off-by: Gabor Abonyi <gabor.abonyi@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Rename common external-arm-toolchain file, so it can be used by non-gcc
external toolchains too.
Change-Id: I48345dc53bc3d20f33b44fc0224b511f30107036
Signed-off-by: Gabor Abonyi <gabor.abonyi@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Add license.inc file to state license of various packages provided by
pre-built Arm tool-set.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Document usage details for GNU Arm toolchains which could either be built
from source or pre-built.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
OE native and cross compilers (in case of SDK) uses OE TARGET_SYS to
create standard paths to search for libraries and headers during
compilation.
Currently external-arm-toolchain recipe temporarily override TARGET_SYS
with EAT_TARGET_SYS and packages libraries and headers corresponding to
EAT_TARGET_SYS which leads to failures during native and cross compilation
(in case of SDK) such as:
$ $CXX -o hello++ hello.cpp
In file included from hello.cpp:1:
/tmp/armsdk/sysroots/armv7at2hf-neon-oe-linux-gnueabi/usr/include/c++/9.2.1/iostream:38:10: fatal error: bits/c++config.h: No such file or directory
38 | #include <bits/c++config.h>
| ^~~~~~~~~~~~~~~~~~
compilation terminated.
$ $CC hello.c
real-ld: cannot find crtbeginS.o: No such file or directory
So remove temp override of TARGET_SYS and rather package libraries and
headers corresponding to OE TARGET_SYS.
This fixes changes added in commit:
https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=91ea4d017bf0598e49944e76c889e66d58c066ce
Also, update location for unwind.h gcc-arm-common.inc accordingly.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
OE core by default package all libraies/headers installed as
"${libdir}/lib*.so", "${libdir}/*.la" and {includedir} as part of
FILES_${PN}-dev" but in case of external Arm toolchain recipe, multiple
packages are provided which needs to include specific libraries and
headers. And "${PN}-dev" is only meant to pick up remaining dev libraries
and headers that aren't picked up by other packages.
So in order to achieve above objective, re-order PACKAGES list to shift
${PN}-dev towards the end. And since some static libraries needs to be
packaged in ${PN}-dev, so we need to keep ${PN}-staticdev later in order.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Currently external Arm toolchain recipe doesn't provide packages
corresponding to OE glibc locale recipe. So explicitly remove corresponding
libc dependencies until we sort out glibc locale packaging rather than
blocking OE SDK generation which is still useful without glibc locale
packaging.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Use the correct path for the binaries in ${datadir}, otherwise it results in a
single incorrect symlink like gcc-arm-none-eabi-*
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Also use ${BINNAME} and ${PV} variables for automatic substitution.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Compiling on the target using runtime libs from external-arm-toolchain
requires libgcc.a, as libgcc_s.so explains:
/* GNU ld script
Use the shared library, but some functions are only in
the static library. */
GROUP ( libgcc_s.so.1 -lgcc )
Otherwise it results in errors like:
| /usr/lib/gcc/arm-linux-gnueabi/9.2.1/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgcc
| /usr/lib/gcc/arm-linux-gnueabi/9.2.1/../../../../arm-linux-gnueabi/bin/ld: cannot find -lgcc
| collect2: error: ld returned 1 exit status
This already has been fixed before in this commit:
https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=91ea4d017bf0598e49944e76c889e66d58c066ce
But then it got broken/undone here w/o due review:
https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=b43d5f0ce431ba1e242504641266a63293ded5db
Even though it's a static library, we want it to be in libgcc-dev as it's
not optional, but rather required for development.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Merge the majority of the binary toolchain recipes for building on an
x86 host into a common include file.
Also, found and fixed an error with both install commands where the name
was double nested on the copy. For example,
/usr/share/arm-none-eabi/arm-none-eabi/ due to the way it was being
copied.
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Reviewed-by: Diego Sueiro <diego.sueiro@arm.com>
Yocto cve-check currently produces numerous warnings like:
WARNING: gcc-cross-arm-arm-8.3-r2019.03 do_cve_check: gcc:
Failed to compare arm-8.3 < 10.0 for CVE-2019-15847
In turn this means that some potential CVEs are not reported.
This occurs because PV has been prefixed with "arm-", to allow for
multiple gcc implementations.
Fix this by setting CVE_VERSION to the non-prefixed version.
Signed-off-by: Ralph Siemsen <ralph.siemsen@linaro.org>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Adds a recipe to pull down the prebuilt GCC for compiling bare-metal targets
for Aarch64 processors from ARM.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Adds a recipe to pull down the prebuilt GCC for compiling on Cortex-R
and Cortex-M processors from ARM. This toolchain is required to build
Arm Trusted Firmware for the Rockchip rk3399 SoC, since it must compile
some firmware for the M0 coprocessor.
This was originally taken from meta-rockchip, but has been modified from
mailing list feedback.
Signed-off-by: Joshua Watt <JPEWhacker@gmail.com>
Signed-off-by: Jon Mason <jdmason@kudzu.us>
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Fixes following QA issue:
WARNING: external-arm-toolchain-2019.12-r0 do_package_qa: QA Issue: The /usr/share/info/dir file is not meant to be shipped in a particular package. [infodir]
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Fixes following QA issue (normally a warning, but Poky and other distros
may treat it as fatal):
ERROR: external-arm-toolchain-2019.12-r0 do_package: QA Issue: external-arm-toolchain: Files/directories were installed but not shipped in any package:
/usr/libexec
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
external-arm-toolchain: 1 installed and not shipped files. [installed-vs-shipped]
ERROR: external-arm-toolchain-2019.12-r0 do_package: Fatal QA errors found, failing task.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
When TCMODE=external-arm, TARGET_SYS!=EAT_TARGET_SYS and gcc installs extra
binary aliases, which could lead to QA errors:
ERROR: gcc-arm-9.2-r2019.12 do_package: QA Issue: gcc: Files/directories were installed but not shipped in any package:
/usr/bin/arm-poky-linux-gnueabi-arm-none-linux-gnueabihf-g++
/usr/bin/arm-poky-linux-gnueabi-arm-none-linux-gnueabihf-gcc
/usr/bin/arm-poky-linux-gnueabi-arm-none-linux-gnueabihf-gcc-ar
/usr/bin/arm-poky-linux-gnueabi-arm-none-linux-gnueabihf-gcc-ranlib
/usr/bin/arm-poky-linux-gnueabi-arm-none-linux-gnueabihf-gcc-nm
Please set FILES such that these items are packaged. Alternatively if they are unneeded, avoid installing them or delete them within do_install.
gcc: 5 installed and not shipped files. [installed-vs-shipped]
ERROR: gcc-arm-9.2-r2019.12 do_package: Fatal QA errors found, failing task.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
gcc-target.inc expects unwind.h to come from and be staged by libgcc.
When TCMODE="external-arm" libgcc is provided by external-arm-toolchain.bb
And while it stages the necessary unwind.h file, it ends up in slightly
different location, so re-stage it. More details are in the comments.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
The 2 scripts that still have /bin/bash shebang are ldd and tzselect. But
it seems upstream had fixed all bashisms in those scripts in recent years
and OE-Core versions of those scripts use /bin/sh already.
Dropping these unnecessary RDEPENDS on bash actually significantly prunes
dependency tree for simple BSP builds like u-boot, etc.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
There's no need to directly provide binutils-cross-${TARGET_ARCH}, as the
PROVIDES list already contains virtual/${TARGET_PREFIX}binutils and correct
PREFERRED_PROVIDER is set in the corresponding tcmode-external-arm.inc file:
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}binutils = "external-arm-toolchain"
Similar to the compiler:
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc = "external-arm-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}gcc-initial = "external-arm-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}g++ = "external-arm-toolchain"
And similar to glibc:
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}libc-for-gcc = "external-arm-toolchain"
PREFERRED_PROVIDER_virtual/${TARGET_PREFIX}compilerlibs = "external-arm-toolchain"
There shouldn't be any direct dependency on binutils-cross-${TARGET_ARCH}. And
if there is, it needs to be fixed to depend on virtual/${TARGET_PREFIX}binutils
During 8.x upgrade there was an attempt to clean it up:
https://git.linaro.org/openembedded/meta-linaro.git/commit/meta-linaro-toolchain/recipes-devtools/external-arm-toolchain/external-arm-toolchain.bb?id=a8ce3dc47f3be9f98abc6ac98a849f918386cf9f
But unfortunately, it got re-added back w/o reasoning:
https://git.linaro.org/openembedded/meta-linaro.git/commit/?id=bb04bc8c67fd032fe04c47b2163ea5fa6b2ffa86
Also, while at it, fix indentation for glibc-mtrace in PROVIDES list.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
These were there from the very beginning and they were used as crutches to
prop up the build by pointing directly to the external toolchain location,
in case early versions of external-arm-toolchain missed staging/packaging
something from there.
First of all, it is unnecessary to adjust CPPFLAGS and LDFLAGS in this way,
as external-arm-toolchain is supposed to stage everything needed from the
toolchain in internal sysroot.
And second, these settings can be harmful and conflict with component's own
CPPFLAGS/LDFLAGS. For example, OpenCV 4.1 fails to link internal libraries
because of incorrect -Wl,-rpath-link passed down the build.
After dropping these, I was able to verify that everything still builds,
including BSP, Wayland/Weston, Qt5, gstreamer, OpenCV, etc for Aarch64 and
Armv7a platforms.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Diego Sueiro <diego.sueiro@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
In the past, some Linaro toolchain versions were shipped with already stripped
libraries, causing QA issues, hence splitting and stripping was disabled.
This is no longer the case and it is better to split and strip binaries and
libraries normally, generating smaller images, while retaining debug symbols
in corresponding -dbg packages.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
While core layer may be implied, it's still nice to depend on it explicitly
for building gcc and other toolchain components in this layer.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
Reviewed-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Add a new meta-arm-toolchain layer to hold ARM GNU-A toolset recipes
imported from meta-linaro tree, branch: master and commit ID:
504ca3b217c9602b10eda0ec8a9f1055b59e482f.
Change-Id: I5a2907874da2869ab94d7d48e0cf4a1bfe241041
Tested-by: Denys Dmytriyenko <denys@ti.com>
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
