Integrating the binary Arm GCC toolchain into OE is quite complicated
because the binary release and oe-core's toolchain are arranged slightly
differently, which makes it quite fragile.
As it's obviously a binary release we cannot patch it to fix issues.
Also it has some fairly sizable limitations: for example the kernel
headers are old (from linux 4.19) and the locale packaging is different
so locale package dependencies don't work.
The main historic users of the external toolchain no longer use it, so
remove it. The recipes will remain in the LTS branches for users who
are using it currently, but will not be part of the next release.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Acked-by: Romain Naour <romain.naour@smile.fr>
Acked-by: Sumit Garg <sumit.garg@linaro.org>
Acked-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
The oe-core commit "classes/recipes: Switch virtual/XXX-gcc to
virtual/cross-cc (and c++/binutils)"[1] changes the virtual names that
the toolchain components use, so external-arm-toolchain needs updating
to use these new names.
[1] 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
usrmerge nowaday required by systemd [1] but it broke
external-arm-toolchain in several ways...
When usrmerge is enabled, /lib is no longer part of SYSROOT_DIRS list
while the prebuilt toolchain expect the dynamic loader to be placed in
/lib not /usr/lib.
There is no /lib directory in the per-package sysroot directory
generated to build each package:
[...]/build/tmp/sysroots-components/<target>/<package>/
sysroot-providers/ usr/
But the cross-compiler still generate binaries with dynamic loarder
path set to "/lib/ld-linux-<target>.so*"
strings sanitycheckc_cross.exe | grep ld
/lib/ld-linux-aarch64.so.1
A symlink /lib -> /usr/lib is crated in the final rootfs image.
But this broke the meson-qemuwrapper used when "qemu-usermode"
(MACHINE_FEATURES) is available:
See [2]:
do_write_config:append:class-target() {
# Write out a qemu wrapper that will be used as exe_wrapper so that meson
# can run target helper binaries through that.
qemu_binary="${@qemu_wrapper_cmdline(d, '$STAGING_DIR_HOST', ['$STAGING_DIR_HOST/${libdir}','$STAGING_DIR_HOST/${base_libdir}'])}"
It produce a runtime issue while running a meson sanity check:
meson-qemuwrapper [...]/build/meson-private/sanitycheckc_cross.exe
qemu-aarch64: Could not open '/lib/ld-linux-aarch64.so.1': No such file or directory
Note: The binaries build by the Yocto internal toolchain seems be "patched" [3]
to look at /usr/lib instead of /lib.
We use -Wl,--dynamic-linker to make sure that the cross-compiler
generate binaries using the dynamic loader path defined by usrmerge
for all packages build by Yocto.
[1] https://git.openembedded.org/openembedded-core/commit/?id=802e853eeddf16d73db1900546cc5f045d1fb7ed
[2] https://git.openembedded.org/openembedded-core/tree/meta/classes-recipe/meson.bbclass?h=2024-04.3-scarthgap#n130
[3] https://github.com/openembedded/openembedded-core/blob/scarthgap/meta/recipes-devtools/gcc/gcc/0007-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch
Signed-off-by: Romain Naour <romain.naour@smile.fr>
Acked-by: Denys Dmytriyenko <denys@konsulko.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
EXTERNAL_TOOLCHAIN variable should provide absolute path to external Arm
toolchain install directory. So make that absolute path check explicit.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
The binary Arm compiler is based on GCC 12. Remove this GCC 13-specific
option until the next release.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
The oe_import() function was removed in oe-core when addpylib was
added[1]. However, meta-arm-toolchain doesn't ship any library code so
this call doesn't do anything useful anyway.
[1] 1f56155e91da2030ee0a5e93037c62e1349ba89f
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
oe-core's master branch is diverging from langdale and meta-arm will be
following this, so drop compatibility with langdale in master so we're
free to diverge too.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
In d8e9ee8fd53b7620e72b2dfebb2e8d464b737dbb the finalize method was removed.
Signed-off-by: David Bagonyi <david.bagonyi@gmail.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Enable support for 11.3.rel1 binary toolchain release. Also, update CI
to use it.
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
As far as we know nobody is actually using the Arm Compiler recipe: 6.17
does a network operation on every call to check the license and this
fails with the network isolation that do_compile has in kirkstone, and
6.18 is behind a loginwall so we cannot download it in a recipe.
Unless we have actual users asking for a recipe, remove it from the layer
to avoid confusion.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
This appears to be historical from when the toolchain was in meta-linaro.
It isn't needed anymore, there's one bbappend in meta-arm-toolchain for
grub which is part of oe-core, so will never be dangling.
This variable has a global effect, so leaving it in here has a negative
impact on users.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Arm GCC 11.2 binary release has moved away from keeping libc library
versioning info as libc-{EAT_VER_LIBC}.so. So rather switch to
retrieving libc version by parsing output from "$ ldd --version".
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Reviewed-by: Denys Dmytriyenko <denis@denix.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
The Armcompiler-* licenses are specific to a single release of the
Arm Compiler, so remove them from the layer and use NO_GENERIC_LICENSE
to extract them from the source directly.
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
This change fixes parsing error that occurs when INCOMPATIBLE_LICENSE =
"GPLv3" by defining EAT_BFD_LICENSE, EAT_GDB_LICENSE and EAT_RLE_LICENSE
in license.inc and requiring it in external-arm-sdk-toolchain.bb
Definitions in external-arm-toolchain-versions.inc are made redundant so
they are removed.
Signed-off-by: Timothy Mertz <timothy.mertz@garmin.com>
Signed-off-by: Joshua Watt <Joshua.Watt@garmin.com>
Reviewed-by: Denys Dmytriyenko <denis@denix.org>
Signed-off-by: Jon Mason <jon.mason@arm.com>
We don't test this, and don't expect it to work, so don't claim it does.
Change-Id: I045930e690edba5a5b0b8cb810130c8c6733623f
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Upstream oe-core is preparing to be the Hardknott release, so add
hardknott to our compatible release list.
Once hardknott is public we should remove gatesgarth.
Change-Id: Ia5c59e703910db96a3967a1ecad074ac80d03ee9
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Without exceptional justification there is no good reason for layers to
have a priority other than 5, to match oe-core. If a layer has a
priority higher than oe-core's then recipes in that layer take immediate
preference over those in oe-core and there's no simple way to resolve
this as that is exactly what is meant to happen.
As a concrete example, meta-arm-bsp contains older releases of U-Boot
for platforms that have not yet moved to the latest release in oe-core.
As the priority of meta-arm-bsp is higher, simply adding this layer to a
qemuarm build will immediately downgrade u-boot.
As there is no exceptional justification for the differing priorities,
unify on 5.
Change-Id: I1975753b4a9799cc00310a7c8a6a11c2aef41f65
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Jon Mason <jon.mason@arm.com>
Drop dunfell support from the master branch in anticipation of the
gatestgarth release. All dunfell users should reference the dunfell
branch.
Change-Id: I9c5806f698cca42773aaea1fb49e0dfff437eaf4
Signed-off-by: Jon Mason <jon.mason@arm.com>
Allows re-use of prebuilt ARM toolchain binaries for SDK generation.
This code is upstreamed from meta-arago layer.
Signed-off-by: Denys Dmytriyenko <denys@ti.com>
[Sumit: package headers corresponding to EAT_TARGET_SYS and add PV]
Signed-off-by: Sumit Garg <sumit.garg@linaro.org>
Signed-off-by: Jon Mason <jon.mason@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>
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>
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>
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>
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>
