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

 --- a/bfd/elf32-arm.c

 +++ b/bfd/elf32-arm.c

 @@ -12408,7 +12408,8 @@ elf32_arm_check_relocs (bfd *abfd, struc

  	  /* If the symbol is a function that doesn't bind locally,

  	     this relocation will need a PLT entry.  */

 -	  root_plt->refcount += 1;

 +	  if (root_plt->refcount != -1)

 +	    root_plt->refcount += 1;

  	  if (!call_reloc_p)

  	    arm_plt->noncall_refcount++;