> but is the term ABI new No, it is age old. The thing is that it is only "a thing" to embedded native developers and library authors. The general concept is

> but is the term ABI new No, it is age old. The thing is that it is only "a thing" to embedded native developers and library authors. The general concept is that the programming language "API" doesn't define how the dll/o/a/la/lib/so/dylib "loader" look for "symbols" in the file. If you example, I do: enum {FOO, BAR}; and next month I change it to enum {BAZ, FOO, BAR}; then everything will still compile, but if I execute an older program with my library, it still thinks FOO is 0 and BAR is 1 while it's no longer the case. It gets worst for function and type definition. Then when you get into C++, it gets an order of magnitude more complex because almost every code change will somewhat break one or many symbols. This is why there is often "proxies" called PIMPL or d_ptr between the library symbols and the actual implementation code. C++ has no officially standardized way to serialize the object to their symbol names. This is often a pain point and Apple wants to fix this for a decade for has so far failed to get everybody to agree on something. For embedded devs, more problem arise from the fact that the instruction set and C library themselves are not the same for all devices and this also break pre-compilled code. Many platform will often favor "static binaries" over dynamic ones to avoid the consequences of breaking the ABI.