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

--- gcc-4.2.1-stock/gcc/config/alpha/linux-unwind.h	2005-06-24 20:22:41.000000000 -0500

+++ gcc-4.2.1/gcc/config/alpha/linux-unwind.h	2007-09-01 20:21:34.000000000 -0500

@@ -29,6 +29,9 @@ Boston, MA 02110-1301, USA.  */

 /* Do code reading to identify a signal frame, and set the frame

    state data appropriately.  See unwind-dw2.c for the structs.  */

+/* Don't use this if inhibit_libc is set

+   The build for this target will fail trying to include missing headers */

+#ifndef inhibit_libc

 #include <signal.h>

 #include <sys/ucontext.h>

@@ -80,3 +83,4 @@ alpha_fallback_frame_state (struct _Unwi

   fs->retaddr_column = 64;

   return _URC_NO_REASON;

 }

+#endif /* inhibit_libc */