I don't understand why the ABI is important context of developing user-space applications. Is the set of system calls for an operating system considered an ABI? But if so then aren't all the complexities regarding system calls encapsulated within standard libraries?
So then is ABI compatibility only relevant for running statically linked applications on different platforms, since the system calls would be embedded into the binary?
System calls also follow an ABI - the syscall interface differs from operating system to operating system.
Statically linking your application and the standard library into it will tie it into one syscall ABI. For instance, FreeBSD allows using the Linux syscall ABI only through an emulation module.
An ABI defines a set of alignment, calling convention, and data types that are common to a system. This makes an ABI awfully important if you're doing any sort of dynamic linking; as without it code from one application has no way of calling code provided by another.
So, no. ABI compatibility is relevant for all dynamic linking (less so for static).
Its worth emphasizing again that a system's ABI affects inter-application work as well as application-to-operating-system work.
The ABI is more than what system calls are available. It also usually describes the actual way arguments are passed to functions and how structures and objects are laid-out in memory. Without a consistent ABI, code built by different compilers might not be able to call each other -- if you call foo(a,b) and one compiler pushes a and b on the stack while another passes those in registers, you've got an ABI clash.
Incompatible ABI is why even though OSX, Linux, Solaris, Windows and *BSD all run on Intel x86 CPUs, a simple POSIX-only hello world program compiled on one OS that does not use any vendor specific or proprietary system calls and/or libraries generally cannot run on one OS when compiled for another OS*.
ABI is not really important to programmers as such because we already instinctively know that you cannot run a Windows app on Macs. Even non-programmers (except Hollywood screenwriters) know this. It is important to compiler writers when they need to target a particular environment.
* note: Some OSes like Linux and BSD support foreign ABI so that a simple Linux command line program can sometimes be executed on BSD without modification. And there are of course emulation layers like wine.
Don't forget in C++ the way name mangling is implemented forms part of the ABI
Only when you want your binary to be run on other environment without recompilation, then there are some places you may need take ABI into account:
you may call a third library in your program, and the third library may varies on different environment. (so only the ABI you can trust)
the syscall to os. (if you static linked the syscall to your binary instead dynamically link to libc)
Actually, most developer need not take ABI into account, only the binary loader/tool developer need know more about it.
"ABI" (see Wikipedia) is an umbrella term for all the assumptions an operating system makes about data formats. This includes the layout of executable files and that of any data structure in memory given its C definition.
The term also generally covers formatting requirements between programs written in the same language. Each language has particular features that might result in different conventions within executable formats and memory structures, but all must ultimately generate executables compatible with the OS and data structures compatible with the processor's instruction set.
ABI doesn't matter much if you only care about compiling standard-conformant code. It matters a little when you violate the standard and do unportable things like casting a long * to a char *. It's yet more important when writing a large body of assembly code. Writing something like a linker or a debugger, it can come to embody the bulk of work to be done.