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

http://sourceware.org/ml/binutils/2007-07/msg00401.html

http://sourceware.org/bugzilla/show_bug.cgi?id=4970

diff -durN binutils-2.20.1.orig/configure binutils-2.20.1/configure

--- binutils-2.20.1.orig/configure	2010-03-03 14:59:02.000000000 +0100

+++ binutils-2.20.1/configure	2010-08-17 19:32:05.000000000 +0200

@@ -6466,6 +6466,7 @@

   *-*-mingw* | *-*-cygwin ) RPATH_ENVVAR=PATH ;;

   *) RPATH_ENVVAR=LD_LIBRARY_PATH ;;

 esac

+RPATH_ENVVAR="cant_touch_this_nah_nah_nah"

 # On systems where the dynamic library environment variable is PATH,

 # gcc/ will put dynamic libraries into a subdirectory to avoid adding