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 -Narup uClibc-0.9.30.1.orig/libc/inet/getaddrinfo.c uClibc-0.9.30.1/libc/inet/getaddrinfo.c

--- uClibc-0.9.30.1.orig/libc/inet/getaddrinfo.c	2009-02-26 21:49:14.000000000 +0900

+++ uClibc-0.9.30.1/libc/inet/getaddrinfo.c	2009-03-06 00:59:23.000000000 +0900

@@ -187,6 +187,8 @@ static unsigned __check_pf(void)

 		}

 		for (runp = ifa; runp != NULL; runp = runp->ifa_next) {

+			if (runp->ifa_addr == NULL)

+				continue;

 #if defined __UCLIBC_HAS_IPV4__

 			if (runp->ifa_addr->sa_family == PF_INET)

 				seen |= SEEN_IPV4;