binutils/binutils: simplify gold dependencies

In preparation of adding a new kernel-type, Yann D. came up
with a change in semantic on binutils/gold availability.

So far, it was architectures' responsibility to declare that
they did support binutils/gold or not. It makes much more sense
that binutils/gold declares its own availability depending on
the current architecture; after all, architectures have no way
to know wether gold supports them, while gold does know it.

Signed-off-by:Yann Diorcet <diorcet.yann@gmail.com>
[yann.morin.1998@free.fr: split up original patch for self-contained changes]
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
Message-Id: <d3d1d51f399e6d2c1163.1353320546@macbook-smorlat.local>
Patchwork-Id: 199971

diff -durN gcc-4.2.3.orig/gcc/config/arm/linux-eabi.h gcc-4.2.3/gcc/config/arm/linux-eabi.h

--- gcc-4.2.3.orig/gcc/config/arm/linux-eabi.h	2007-09-01 17:28:30.000000000 +0200

+++ gcc-4.2.3/gcc/config/arm/linux-eabi.h	2008-05-25 23:47:36.000000000 +0200

@@ -47,7 +47,8 @@

 #define SUBTARGET_CPU_DEFAULT TARGET_CPU_arm10tdmi

 #undef SUBTARGET_EXTRA_LINK_SPEC

-#define SUBTARGET_EXTRA_LINK_SPEC " -m armelf_linux_eabi"

+#define SUBTARGET_EXTRA_LINK_SPEC	\

+	" %{mlittle-endian:-m armelf_linux_eabi} %{mbig-endian:-m armelfb_linux_eabi}"

 /* Use ld-linux.so.3 so that it will be possible to run "classic"

    GNU/Linux binaries on an EABI system.  */