linux/poky.git/meta/recipes-devtools/binutils/binutils-cross.inc, branch master-next

toolchain: Provide abstraction for recipe specific toolchain selection

2025-06-16T21:26:38+00:00

This change implements a toolchain selection mechanism. Selection is made using a set of variables, primarily PREFERRED_TOOLCHAIN_TARGET which defaults to gcc. It uses the familiar name for toolchain e.g. "gcc" which selects GNU compiler + binutils as default C/C++ toolchain or "clang" which will use LLVM/Clang Compiler. Layers an add their own toolchain definitions too. There are also PREFERRED_TOOLCHAIN_NATIVE and PREFERRED_TOOLCHAIN_SDK which will ulitmately allow selection of the toolchain used for the native/cross and nativesdk/crosssdk compilers. This currently isn't functional but is essential to the patch to ensure things are set to the existing gcc support in those cases. Users would most commonly want to set: PREFERRED_TOOLCHAIN_TARGET ?= "clang" in local.conf or other distro specific global configuration metadata. It is also selectable at recipe scope, since not all packages are buildable with either clang or gcc, a recipe can explicitly require a given toolchain using the TOOLCAHIN variable, e.g. glibc can not be built with clang therefore glibc recipe sets: TOOLCHAIN = "gcc" The TOOLCHAIN variable is distinct from the user preference so recipes with specific requirements can be identified. This also allows different polcies to be be specified for native/SDK cases in the future. (From OE-Core rev: 45bdedd213aff8df3214b95ef2a8551c0abd93a0) Signed-off-by: Richard Purdie

base: Switch virtual/cross-XXX to be under recipe specific providers

2025-01-21T23:09:34+00:00

Currently, providers are set on a global config basis. This change allows for a select set of providers to be configured using BB_RECIPE_VIRTUAL_PROVIDERS on a per recipe basis. This would allow for the selection of virtual/cross-cc as gcc or clang for example. The PROVIDERS are removed from the recipes so that if a version of the dependency accidentally slips through, the build will fail and the user can correct the issue. (From OE-Core rev: 6eeab1a5d7f23917b94c130e417d59afb757b546) Signed-off-by: Richard Purdie

classes/recipes: Switch virtual/XXX-gcc to virtual/cross-cc (and c++/binutils)

2025-01-21T23:09:33+00:00

The idea of the base class dependency is to say "yes, I need a C cross compiler" and this was never meant to be gcc specific. Looking at the codebase, whilst we code triplets into this, it does overcomplicate things as there are only ever limited, "target", "sdk" and the class extended versions like mutlilib. After much thought, we can simplify this to virtual/cross-cc and virtual/nativesdk-cross-cc. This lets us remove the "gcc" specific element as well as removing the over complicated triplet usage. At the same time, change the much less widely used "g++" variant to "c++" for similar reasons and remove the triplet from virtual/XXX-binutils too. Backwards compatibility mappings could be left but are just going to confuse things in future so we'll just require users to update. This simplification, whilst disruptive for any toolchain focused layers, will make improved toolchain selection in the future much easier. Since we no longer have overlapping variables, some code for that can just be removed. The class extension code does need to start remapping some variables but not the crosssdk target recipe names. This patch is in two pieces, this one handles the renaming with the functional changes separate in a second for easier review even if this breaks bisection. (From OE-Core rev: 4ccc3bc8266c327bcc18c9a3faf7536210dfb9f0) Signed-off-by: Richard Purdie

binutils-cross: Disable gprofng for when building cross binutils

2022-08-21T21:51:41+00:00

This does not work in cross settings yet (From OE-Core rev: c9d484092060f7e8431e31c64d98433b4f85c378) (From OE-Core rev: c5cf9795cf9d2290bfa39cd7adfbec9a7777fea0) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie Signed-off-by: Alexandre Belloni Signed-off-by: Richard Purdie

recipes/*-cross recipes: ignore TARGET_ARCH sstate hash

2017-04-12T14:09:58+00:00

"yocto-compat-layer.py --machines" showed that shared packages like gcc-cross-powerpc64 have a sstate signature that depends on TUNEFLAGS. As a result, there are unnecessary rebuilds and potential conflicts in a multiconfig. That's due to the way how TARGET_ARCH is set. Richard Purdie suggested setting TARGET_ARCH[vardepvalue] as fix, which works. It would be shorter to do that in cross.bbclass instead of repeating the relevant line in different recipes, but Richard was concerned about potential side-effects in other usages of cross.bbclass. TARGET_GOARM as used in go.inc is still causing signature differences for go-cross-powerpc64 and machines b4420qds-64b and p5020ds-64b. This needs further investigation. (From OE-Core rev: 39bfa0dd3237cbca47e7fca1075d521f9d073f25) Signed-off-by: Patrick Ohly Signed-off-by: Richard Purdie

binutils: Upgrade to 2.28 release

2017-03-07T20:05:31+00:00

(From OE-Core rev: e9f839d5fe70a222cc7b8942f401ac86a10e6604) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

binutils-cross: Remove exec_prefix from the linker search path

2017-01-31T23:47:33+00:00

We don't put target libs into a native/cross ${exec_prefix} but having this in the default search path means all linker scripts have to be relocated. This is a considerable chunk of files to create multiple copies of for no good reason. Instead, patch out the paths we don't need. (From OE-Core rev: 20816eb5398512652c971a37589a2ca28ffd3d68) Signed-off-by: Richard Purdie

binutils/gcc/gdb: Add TARGET_ARCH to PN for all cross recipes

2014-04-30T15:39:06+00:00

This allows them to co-exist together in the native sysroot, with one set of cross tools per target architecture. (From OE-Core rev: a2c5509520d5c3e082f55844e6545d0309565f8f) Signed-off-by: Richard Purdie

binutils: Add with-sysroot to target binutils

2012-06-21T12:03:04+00:00

Also rearrange the recipes to have common bits in inc files and not include the target bb file everywhere. This lets us add specific options to specific recipes particularly target recipe in this case (From OE-Core rev: f4ed063e32f064e996a4c29760fa4ac49f1ed73c) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie

cross-recipes: Disable nls in gettext bbclass

2011-12-15T14:36:23+00:00

Right now for cross recipes e.g. gcc-cross and binutils-cross we specify --disable-nls .... --enable-nls on configure cmdline the --enable-nls coming from gettext bbclass. So we disable nls for all cross inheriting recipes in gettext bbclass and then we remove the extra --disable-nls in gcc-cross and binutils-cross This patch needs testing. Please help (From OE-Core rev: d66b379f809b9c75981848fcc71ed5de13382bf7) Signed-off-by: Khem Raj Signed-off-by: Richard Purdie