Разница между API и ABI

API: прикладной программный интерфейс

Это набор общедоступных типов/переменных/функций, которые вы открываете из своего приложения/библиотеки.

В C/С++ это то, что вы показываете в файлах заголовков, которые вы отправляете с приложением.

ABI: Application Binary Interface

Вот как компилятор создает приложение.
Он определяет вещи (но не ограничивается ими):

• Как параметры передаются в функции (регистры/стек).
• Кто очищает параметры из стека (вызывающий/вызываемый).
• Если для возврата возвращается возвращаемое значение.
• Как распространяются исключения.

В основном я встречаю эти термины в смысле несовместимого с API изменения или ABI-несовместимого изменения.

Взаимодействие API по существу там, где код, который был бы скомпилирован с предыдущей версией, больше не будет. Это может произойти, потому что вы добавляете аргумент функции или изменяете имя чего-либо, доступного вне вашего локального кода. Каждый раз, когда вы меняете заголовок, и это заставляет вас что-то менять в файле .c/.cpp, вы внесли изменение API.

Изменение ABI - это код, который уже был скомпилирован против версии 1, больше не будет работать с версией 2 базы кода (обычно это библиотека). Это, как правило, сложнее отслеживать, чем несовместимые с API изменения, поскольку нечто такое же простое, как добавление виртуального метода в класс, может быть несовместимым с ABI.

Я нашел два чрезвычайно полезных ресурса для выяснения того, что такое совместимость с ABI и как его сохранить:

• Список Do и Dont с С++ для проекта KDE
• Ульрих Дреппер Как писать общие библиотеки .pdf (основной автор glibc)

это объяснения моего непрофессионала:

• api - думаю include файлы. они предоставляют программный интерфейс
• abi - думаю, модуль ядра. когда вы запускаете его на каком-то ядре, они должны согласиться с тем, как обмениваться данными без включенных файлов, т.е. как низкоуровневый двоичный интерфейс

( A pplication B inary I nterface) Спецификация конкретной аппаратной платформы в сочетании с операционной системой. Это один шаг за пределы API ( A pplication P rogram I nterface), который определяет вызовы из приложения в операционную систему. ABI определяет API плюс машинный язык для конкретного семейства процессоров. API не обеспечивает совместимость во время выполнения, но ABI делает это, потому что он определяет формат машины или формат времени исполнения.

Предоставлено

Позвольте мне привести конкретный пример того, как ABI и API отличаются в Java.

Несовместимое изменение ABI заключается в том, что я изменяю метод A # m() от принятия a String в качестве аргумента аргументу String.... Это не совместимо с ABI, потому что вам нужно перекомпилировать код, который его вызывает, но он совместим с API, так как вы можете его решить, перекомпилировав без каких-либо изменений кода в вызывающем абоненте.

Вот пример, изложенный. У меня есть Java-библиотека с классом A

// Version 1.0.0
public class A {
    public void m(String string) {
        System.out.println(string);
    }
}

И у меня есть класс, который использует эту библиотеку

public class Main {
    public static void main(String[] args) {
        (new A()).m("string");
    }
}

Теперь автор библиотеки скомпилировал свой класс A, я скомпилировал свой класс Main, и все это хорошо работает. Представьте, что появилась новая версия A

// Version 2.0.0
public class A {
    public void m(String... string) {
        System.out.println(string[0]);
    }
}

Если я просто возьму новый скомпилированный класс A и вытащу его вместе с ранее скомпилированным классом Main, я получаю исключение при попытке вызвать метод

Exception in thread "main" java.lang.NoSuchMethodError: A.m(Ljava/lang/String;)V
        at Main.main(Main.java:5)

Если я перекомпиляю Main, это исправлено и все снова работает.

Ваша программа (исходный код) может быть скомпилирована с помощью модулей, которые предоставляют правильный API.

Ваша программа (двоичная) может работать на платформах, которые обеспечивают надлежащую ABI.

API ограничивает определения типов, определения функций, макросы, иногда глобальные переменные, которые должна раскрывать библиотека.

ABI ограничивает то, что "платформа" должна обеспечить для вашей программы для запуска. Мне нравится рассматривать его на 3 уровнях:

• уровень процессора - набор команд, соглашение о вызове

• уровень ядра - соглашение о системном вызове, специальное соглашение о пути к файлу (например, файлы /proc и /sys в Linux) и т.д.

• Уровень ОС - формат объекта, библиотеки времени выполнения и т.д.

Рассмотрим кросс-компилятор с именем arm-linux-gnueabi-gcc. "arm" указывает на архитектуру процессора, "linux" указывает на ядро, "gnu" указывает, что его целевые программы используют GNU libc как библиотеку времени исполнения, отличную от arm-linux-androideabi-gcc, которая использует реализацию libc для Android.