[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] ABI vs. API



On Wed, Feb 04, 2004 at 12:20:48PM -0700, Monique Y. Herman wrote:
> I'm a bit confused, I guess.  What's the difference between an API
> (Application programmer interface) and an ABI (application binary
> interface)?  In both cases, they seem to be libraries used by developers
> to do stuff.

Neither is really a library as such, at least not in itself.

An API is the source code interface to a library. So, for instance, this
is an API, together with the description of what the functions do, how
you're allowed to use them, and what the arguments and return values
mean:

       #include <stdio.h>

       FILE *fopen(const char *path, const char *mode);
       FILE *fdopen(int fildes, const char *mode);
       FILE *freopen(const char *path, const char *mode, FILE *stream);

An ABI is the interface to a library as seen by compiled code. To figure
out the ABI for the above, you need to know things like which way round
the bytes in an int go, how long a pointer is, and where the arguments
go on the stack when you're calling a function. More complicated and
library-specific ABIs include things like the way elements in a struct
are laid out.

When people talk about APIs and ABIs, they're often talking about
compatibility. In general, if you try to change an interface then you
can get away without breaking programs built against the old interface
if you only add things: so you can (sometimes) add elements to the *end*
of a struct, or you can add new functions, that sort of thing. Sometimes
the ABI is broken but not the API: for example, you might turn a
function into a macro that's a wrapper around some new code, which would
mean that old binaries would break but you can still compile source code
written for the old version.

When a library's ABI changes in a backwards-incompatible way, the soname
(e.g. libc.so.6) of the library has to change. If it changes but in a
backwards-compatible way, then in Debian we change
/var/lib/dpkg/info/<library-package>.shlibs to indicate this, so that
programs built against the new version depend on the last time when new
binary interfaces were introduced.

Changing a library's API in a backwards-incompatible way is in general
bad form because it means that developers of programs using the library
have to change their source code to port the programs to the new
library. However, it does happen sometimes in the case of major
libraries, such as some of those in GNOME and KDE.

Cheers,

-- 
Colin Watson                                  [cjwatson@flatline.org.uk]



Reply to: