Sorry, but that is not technically correct. The compiled software
only includes the API if it is not stripped and includes the symbol table. The
judge
understands this which is why he said ABI not API.
So much
wrong here that one does not know where to begin. An API (at least the most
common incarnation) is a contract between reasonably independently developed
and/or maintained caller and callee of a library. There is no necessity to
actually copy headers, and consequently order of parts is arbitrary, memory
layout is arbitrary, symbol table content is arbitrary except for those
components part of the API proper (and not supplementary and/or for internal
purposes).
An ABI, in contrast, is a mapping between programming language
concepts and machine language. Basically, every compiler can have his own ABI.
For interoperability of libraries, it makes sense if compiler manufacturers can
agree on an ABI.
Another ABI is the system call ABI of an operating system
or kernel. I think that there was (is?) at one time support for the Linux ABI
in FreeBSD, meaning that FreeBSD users were able to run binaries intended for
running on Linux. Closely related to that is the _format_ of a binary, even
though it is conceivable to support different formats (ELF, a.out, COFF ...) via
different loaders in the operating system as long as the result can use the same
system call ABI.
So the ABI, more or less, defines the medium, and the API
defines the various kinds of messaging that can happen over it.
Both are, in
essence, descriptions. There is no leeway in how the actual call interfaces and
interchange data look when being compiled, but the descriptions can take a
number of forms, and so can the actual symbol tables and implementations behind
it. [ Reply to This | Parent | # ]
|
