binutils 2.21 doesn't recognise the Cortex-M3 SVC instruction when
assembling with -mcpu=all. This was fixed by the 2.21.53 snapshot and
is needed to build RTOSs such as FreeRTOS.
Signed-off-by: Michael Hope <michael.hope@linaro.org>
Recently, all binutils versions have been renamed after a GPL compliance
issue was found and fixed in binutils;
http://sourceware.org/ml/binutils/2011-08/msg00198.html
Although legacy symlinks have been put in place, we should now use
the new, real version strings.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Recently, all binutils versions have been renamed after a GPL compliance
issue was found and fixed in binutils;
http://sourceware.org/ml/binutils/2011-08/msg00198.html
Old versions are no-longer available since the rename (eg. 2.19 has been
superseeded by 2.19.1, and only 2.19.1a was regenerated).
Remove now-missing versions.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
This patch makes binutils benefit from the TOOLCHAIN_PKGVERSION and
TOOLCHAIN_BUGURL options.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
kconfig bools are disabled by default, so specifying 'default n' is useless and
noisy. This patch removes all occurrences of 'default n'.
Signed-off-by: "Benoît THÉBAUDEAU" <benoit.thebaudeau@advansee.com>
Update help entries for thos variables that accept multiple
arguments with spaces (aka. array-capable variables).
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Make it explicit that a variable is an array bu the name of the variable.
It will be used later when .config gets munged to allow both multiple
arguments and arguments with spaces at the same time to be passed from the
configuration down to the build scripts.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is not capable of building glibc/eglibc, so we have to
force using the BFD linker, ld.bfd.
Offer a blind option that affected components can select to
force use of the BFD linker during the build.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is not capable of building glibc/eglibc. See this thread:
http://sourceware.org/ml/crossgcc/2011-04/msg00010.html
Reported-by: Bill Pringlemeir <bpringle@sympatico.ca>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
The gold linker does currently support only a limited set of architectures:
- x86 (32- and 64-bit)
- ARM
Hide the gold option for other architectures.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Plugins are shared objects, and when building a toolchain statically,
the gcc build system breaks havok (although there is no hard technical
reasons it should not be possible)...
And consequently, do not enable plugin supoprt in binutils.
Reported-by: Thomas Spurden <thomas@ado.is-a-geek.net>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When both gold and ld are installed, add a wrapper that calls
to either gold or ld.
In case the wrapper is installed, we also need to symlink ld.bfd
and ld.gold for the core_cc steps.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
When configured with support for threads, gold can link in
parallel, possibly cooperating with a make jobserver.
Add an option enabling threads.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
gold is a new, optimised, multi-threaded linker with support
for plugins.
Add support for gold starting with binutils 2.21. Although 2.20
also had gold, the configure flags have changed, and supporting
2.20 would be a mess in the code.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
Add BINUTILS_2_21_or_later blind option. It will be used to add
conditional support for building 'gold' on versions that have it.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
sstrip is causing more trouble and grief than tolerable.
It is broken at least on PPC. It does not build on non-ELF
systems (eg. mingw32, MacOS-X...). Plus, it is easy to
install.
Hide it behind OBSOLETE.
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@anciens.enib.fr>
sstrip is now alone in its 'tools' menu, and we will probably never gain
any other 'tool'. Besides, sstrip is just strip, but a little bit more
agressive, so it deserves going to the 'binary utilities' menu.
The companion libraries on the target are required only for internal use by
binutils and gdb. The user should not have to know about this, so hide the
option.