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

# Compute MIPS-specific values

CT_DoArchTupleValues() {

    # The architecture part of the tuple, override only for 64-bit

    if [ "${CT_ARCH_64}" = "y" ]; then

        CT_TARGET_ARCH="mips64${target_endian_el}"

    else

        # The architecture part of the tuple:

        CT_TARGET_ARCH="${CT_ARCH}${target_endian_el}"

    fi

    # Override CFLAGS for endianness:

    case "${CT_ARCH_ENDIAN}" in

        big)    CT_ARCH_ENDIAN_CFLAG="-EB";;

        little) CT_ARCH_ENDIAN_CFLAG="-EL";;

    esac

    # Override ABI flags

    CT_ARCH_ABI_CFLAG="-mabi=${CT_ARCH_mips_ABI}"

    CT_ARCH_WITH_ABI="--with-abi=${CT_ARCH_mips_ABI}"

}