每个操作系统都会为运行在该系统下的应用程序提供应用程序二进制接口（Application Binary Interface，ABI）。ABI包含了应用程序在这个系统下运行时必须遵守的编程约定。ABI总是包含一系列的系统调用和使用这些系统调用的方法，以及关于程序可以使用的内存地址和使用机器寄存器的规定。从一个应用程序的角度看，ABI既是系统架构的一部分也是硬件体系结构的重点，因此只要违反二者之一的条件约束就会导致程序出现严重错误。在很多情况下，链接器为了遵守ABI的约定需要做一些重要的工作。例如，ABI要求每个应用程序包含一个程序中各例程使用的静态数据的所有地址表，链接器通过收集所有链接到程序中的模块的地址信息来创建地址表。ABI经常影响链接器的是对标准过程调用的定义

ABI（Application Binary Interface）：应用程序二进制接口，描述了应用程序和操作系统之间，一个应用和它的库之间，或者应用的组成部分之间的低接口。ABI涵盖了各种细节，如：
数据类型的大小、布局和对齐；
调用约定（控制着函数的参数如何传送以及如何接受返回值），例如，是所有的参数都通过栈传递，还是部分参数通过寄存器传递；哪个寄存器用于哪个函数参数；通过栈传递的第一个函数参数是最先push到栈上还是最后；
系统调用的编码和一个应用如何向操作系统进行系统调用；
以及在一个完整的操作系统ABI中，目标文件的二进制格式、程序库等等。
与应用程序接口区别编辑
应用程序接口（Application Programming Interface，API），又称为应用编程接口，就是软件系统不同组成部分衔接的约定。由于近年来软件的规模日益庞大，常常需要把复杂的系统划分成小的组成部分，编程接口的设计十分重要。程序设计的实践中，编程接口的设计首先要使软件系统的职责得到合理划分。良好的接口设计可以降低系统各部分的相互依赖，提高组成单元的内聚性，降低组成单元间的耦合程度，从而提高系统的维护性和扩展性。
ABI不同于API ，API定义了源代码和库之间的接口，因此同样的代码可以在支持这个API的任何系统中编译 ，然而ABI允许编译好的目标代码在使用兼容ABI的系统中无需改动就能运行。 ABI掩盖了各种细节，例如:调用约定控制着函数的参数如何传送以及如何接受返回值；系统调用的编码和一个应用如何向操作系统进行系统调用；以及在一个完整的操作系统ABI中，对象文件的二进制格式、程序库等等。一个完整的ABI，像 Intel二进制兼容标准 (iBCS) ，允许支持它的操作系统上的程序不经修改在其他支持此ABI的操作系统上运行。其他的 ABI 标准化细节包括C++ name decoration和同一个平台上的编译器之间的调用约定，但是不包括跨平台的兼容性。在Unix的操作系统中，存在很多运行在同一件平台上互相相关但是不兼容的操作系统（尤其是80386兼容系统）。有一些努力尝试标准化A I，以减少销售商将程序移植到其他系统时所需的工作。然而，还没有很成功的例子，虽然LSB正在为Linux做这方面的努力。
它描述了应用程序与OS之间的底层接口。ABI涉及了程序的各个方面，比如：目标文件格式、数据类型、数据对齐、函数调用约定以及函数如何传递参数、如何返回值、系统调用号、如何实现系统调用等。
一套完整的ABI（比如：Intel Binary Compatibility Standard (iBCS)），可以让程序在所有支持该ABI的系统上运行，而无需对程序进行修改。

1. ABI 解决什么问题

一个应用程序的运行，需要诸多相关的库文件来支撑的。在Windows当中的库文件是.dll（动态链接库）而Linux当中的库文件是.so（共享对象）。这样编写的程序，是不能跨平台的，为解决这样的问题，ABI应运而生（Application Binary Interface 应用程序二进制接口）。

1. ABI 是什么

每个操作系统都会为运行在该系统下的应用程序提供应用程序二进制接口(ABI)。ABI包含了应用程序在这个系统下运行时必须遵守的变成约定，一系列的系统调用和使用这些系统调用的方法，以及关于程序可以使用的内存地址和使用机器寄存器的规定。

3 . ABI不同于API

应用二进制接口，描述了应用程序和操作系统之间，一个应用和它的库之间，或者应用的组成部分之间的低层接口。

ABI不同于应用程序接口（API），API定义了源代码和库之间的接口，因此同样的代码可以在支持这个API的任何系统中编译，然而ABI允许编译好的目标代码在使用兼容ABI的系统中无需改动就能运行。

ABI掩盖了各种细节，例如:调用约定（控制着函数的参数如何传送以及如何接受返回值）；系统调用的编码和一个应用如何向操作系统进行系统调用；以及在一个完整的操作系统ABI中，目标文件的二进制格式、程序库等等

如何检查你的应用程序的ABI兼容性

首先要获得你share出去的lib的符号表：

$ find . -name ‘.a’|xargs nm -f posix|cut -f1 -d’ ‘|LANG=C sort -u > all_symbols
$ find . -name ‘.so’|xargs nm -f posix -D|cut -f1 -d’ ‘|LANG=C sort -u » all_symbols
$ grep ‘^_Z’ all_symbols | c++filt|sort > demangled_c++_symbols
然后分一下三种情况：
如果你的文件是空的，恭喜你了，你的lib都是C写的，不需要重新编译，是ABI兼容的。

如果你的文件中没有包含std::这样的字符，并且你的函数中没有一个的参数或返回值用到了标准类库中的对象，你的库有90%的就会是ABI兼容的。

如果你的文件中有包含std::这样的字符，或者你的函数中有一个的参数或返回值用到了标准类库中的对象，你的库有90%的就会不是ABI兼容的。

https://gcc.gnu.org/wiki/Cxx11AbiCompatibility
https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi/
接口：它是间“现有实体”层 functionality和consumer的该功能。接口本身不起作用。它只是调用后面的功能。

现在取决于用户是谁，有不同类型的接口。

命令行界面（CLI）命令是现有实体，消费者是用户和功能所在。

functionality: 我的软件功能解决了我们描述这个界面的一些目的。

existing entities: 命令

consumer: 用户

图形用户界面（GUI）窗口，按钮等是现有实体，消费者再次是用户和功能所在。

functionality: 我的软件功能解决了我们描述这个界面的一些问题。

existing entities: 窗口，按钮等..

consumer: 用户

应用程序编程接口（API）函数（或更正确的）接口（在基于接口的编程中）是现有实体，这里的消费者是另一个程序而不是用户，并且该层后面的功能也是如此。

functionality: 我的软件功能解决了我们描述这个界面的一些问题。

existing entities: 函数，接口（函数数组）。

consumer: 另一个程序/应用程序

应用程序二进制接口（ABI）

http://www.sco.com/developers/devspecs/gabi41.pdf