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

Original patch from: ../4.3.2/280-c99-complex-ugly-hack.patch

-= BEGIN original header =-

Original patch from gentoo: gentoo/src/patchsets/gcc/4.3.1/uclibc/90_all_303-c99-complex-ugly-hack.patch

-= END original header =-

diff -durN gcc-4.3.3.orig/libstdc++-v3/configure gcc-4.3.3/libstdc++-v3/configure

--- gcc-4.3.3.orig/libstdc++-v3/configure	2008-07-07 21:49:54.000000000 +0200

+++ gcc-4.3.3/libstdc++-v3/configure	2009-01-27 22:25:39.000000000 +0100

@@ -38935,6 +38935,9 @@

 cat >>conftest.$ac_ext <<_ACEOF

 /* end confdefs.h.  */

 #include <complex.h>

+#ifdef __UCLIBC__

+#error ugly hack to make sure configure test fails here for cross until uClibc supports the complex funcs

+#endif

 int

 main ()

 {