arm-linux-gnu-gcc Vs arm-linux-gcc

If you only want to compile programs that run on their own on a processor (“bare metal” system), then all that matters is to have a compiler that produces instructions for that particular processor. “For ARM” is almost enough information, but not quite: you would also need to specify the version of the instruction set. Most ARM processors today are based on the same version (ARMv7) but even inside that there are many complications — some features (e.g. floating point, vector instructions) are optional and you need to specify whether to use them, and ARMv7 has in fact two instruction sets (“normal” ARM, and Thumb). Most distributions of GCC for ARM target ARMv7 with optional features and Thumb enabled by options.

If you want to compile programs that interact with other programs, then all the programs involved need to be able to communicate. Making system calls and, even more so, making library calls requires that the caller and the callee agree on the binary representation of data (e.g. endianness) and on how to pass data around (which registers to use for function arguments, how function calls affect the stack, etc.). The specification of how this works is called an ABI (application binary interface).

The general naming convention for GCC cross-compilers is CPU-VENDOR-SYSTEM-gcc (where the part before -gcc matches the system type of configure), but there is some fuzz about the VENDOR-SYSTEM part. Cross-compilers for ARM are usually called arm-VENDOR-OS-LIBC-ABI-gcc with some of the parts omitted. For example, arm-acme-linux-gnu-gnueabi-gcc would be GCC for ARM (v7 by default), for ACME's distribution of Linux, set to link against Glibc, using the gnueabi ABI. arm-linux-gnu-gcc indicates a compiler set to link against Glibc on Linux, with an unspecified ABI. arm-linux-gcc doesn't specify which libc is targeted.