aboutsummaryrefslogtreecommitdiffstats
path: root/meta/recipes-devtools/binutils/binutils-cross.inc
AgeCommit message (Collapse)Author
2017-04-12recipes/*-cross recipes: ignore TARGET_ARCH sstate hashPatrick Ohly
"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. Signed-off-by: Patrick Ohly <patrick.ohly@intel.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-03-07binutils: Upgrade to 2.28 releaseKhem Raj
Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2017-01-31binutils-cross: Remove exec_prefix from the linker search pathRichard Purdie
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. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2014-04-30binutils/gcc/gdb: Add TARGET_ARCH to PN for all cross recipesRichard Purdie
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>
2012-06-21binutils: Add with-sysroot to target binutilsKhem Raj
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 Signed-off-by: Khem Raj <raj.khem@gmail.com> Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-12-15cross-recipes: Disable nls in gettext bbclassKhem Raj
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 Signed-off-by: Khem Raj <raj.khem@gmail.com>
2011-11-29Introduce multiarch DISTRO_FEATUREJulian Pidancet
This patch introduces a distro feature which enables gcc to produce both 32bit and 64bit code, and enables binutils to operate on both 32bit and 64bit binaries. It differs from multilib toolchains in that it does not require to compile a version of the libc for each architecture variant. However, the code produced for the secondary architecture will not be linkable against the libc. v2: - Renamed the feature name from "biarch" to "multiarch". The GCC installation manual claims that the mips-linux can be made a tri-arch compiler (http://gcc.gnu.org/install/configure.html) - For x86_64, the compiler is made bi-arch by default, so nothing has to be done in particular. - I analyzed the gcc/config.gcc from GCC sources and added in this patch all the architectures that could be made biarch with the version of gcc currently used in OE, which are powerpc, and sparc, in addition to x86. mips and s390 will probably be supported in future versions of gcc. For x86 and sparc, only the --enable-targets=all option is valid to make this work (this option doesn't have any other side effects than making the compiler bi-arch). For powerpc, I used the --enable-targets=powerpc64 option (although 'all' also works). Note: - Untested on powerpc and sparc. But I believe it works the same as with x86. - gcc in meta-toolchain is also made multiarch. Signed-off-by: Julian Pidancet <julian.pidancet@gmail.com>
2011-10-10gcc/binutils: Disable NLS/gettext dependenciesRichard Purdie
We force the C locale when running builds for determinstic error messages. We therefore have no need to NLS support in binutils cross or gcc cross. We also don't need the standard base/autotools dependencies for our toolchain components since we don't autoreconf these. This patch turns off nls and cleans up some of the dependencies resulting in a slightly less convoluted set of build dependencies. Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
2011-06-30binutils: allow distro to select gold as default linkerPhil Blundell
But ensure that gcc-cross-intermediate always uses ld.bfd since (e)glibc won't build with gold. Signed-off-by: Phil Blundell <philb@gnu.org>
2010-12-23binutils*.inc: Recipe format cleanupScott Garman
Cleanup some simple whitespace / line break issues. Signed-off-by: Scott Garman <scott.a.garman@intel.com>
2010-10-01binutils: Update the poison patchMark Hatle
[BUGID #374] Previously the poison directories patch was present, but not enabled due to the lack of the configure option being set, and also the fact configure itself was not being patched. Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
2010-08-27Major layout change to the packages directoryRichard Purdie
Having one monolithic packages directory makes it hard to find things and is generally overwhelming. This commit splits it into several logical sections roughly based on function, recipes.txt gives more information about the classifications used. The opportunity is also used to switch from "packages" to "recipes" as used in OpenEmbedded as the term "packages" can be confusing to people and has many different meanings. Not all recipes have been classified yet, this is just a first pass at separating things out. Some packages are moved to meta-extras as they're no longer actively used or maintained. Signed-off-by: Richard Purdie <rpurdie@linux.intel.com>