Diferencia entre API y ABI

API: Interfaz del Programa de Aplicación

Este es el conjunto de tipos/variables/funciones públicas que expone desde su aplicación/biblioteca.

En C/C++ esto es lo que expones en los archivos de encabezado que envías con la aplicación.

ABI: Interfaz Binaria de la aplicación

Así es como el compilador construye una aplicación.
Define cosas (pero no se limita a):

• Cómo se pasan los parámetros a las funciones (registros/pila).
• Oms limpia los parámetros de la pila (caller / callee).
• Donde se coloca el valor de retorno para return.
• Cómo se propagan las excepciones.

En su mayoría me encuentro con estos términos en el sentido de un cambio incompatible con API o un cambio incompatible con ABI.

Un cambio de API es esencialmente donde el código que se habría compilado con la versión anterior ya no funcionará. Esto puede suceder porque agregaste un argumento a una función o cambiaste el nombre de algo accesible fuera de tu código local. Cada vez que cambias un encabezado, y te obliga a cambiar algo en un .c/.archivo cpp, has hecho un cambio de API.

An El cambio ABI es cuando el código que ya ha sido compilado contra la versión 1 ya no funcionará con la versión 2 de una base de código (generalmente una biblioteca). Esto es generalmente más complicado de realizar un seguimiento que el cambio incompatible con API, ya que algo tan simple como agregar un método virtual a una clase puede ser incompatible con ABI.

He encontrado dos recursos extremadamente útiles para averiguar qué es la compatibilidad ABI y cómo preservarla:

• La lista de Cosas que hacer y No hacer con C++ para KDE proyecto
• Ulrich Drepper's Cómo Escribir Bibliotecas Compartidas.pdf (autor principal de glibc)

Estas son mis explicaciones laicas:

• api-piensa en los archivos include. proporcionan interfaz de programación
• abi - think kernel module. cuando se ejecuta en algún núcleo, tienen que acordar cómo comunicarse sin incluir archivos, es decir, como interfaz binaria de bajo nivel

Permítanme dar un ejemplo específico de cómo ABI y API difieren en Java.

Un cambio incompatible con ABI es si cambio un método A#m() de tomar un String como argumento a String... argumento. Esto es no es compatible con ABI porque tienes que recompilar el código que está llamando a eso, pero es compatible con API ya que puedes resolverlo recompilando sin ningún cambio de código en el llamante.

Aquí está el ejemplo deletreado. Tengo mi biblioteca Java con clase A

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

Y tengo una clase que usa esta biblioteca

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

Ahora, el autor de la biblioteca compiló su clase A, yo compilé mi clase Main y todo está funcionando muy bien. Imagine una nueva versión de A comes

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

Si simplemente tomo la nueva clase compilada A y la dejo junto con la clase compilada previamente Main, obtengo una excepción al intentar invocar el método

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

Si recompilo Main, esto está arreglado y todo está funcionando de nuevo.

(A pplication B inary I nterface) Una especificación para una plataforma de hardware específica combinada con el sistema operativo. Es un paso más allá de la API ( A pplication P rogram I nterface), que define las llamadas de la aplicación al sistema operativo. El ABI define la API más el lenguaje de máquina para una familia de CPU en particular. Una API no garantiza la compatibilidad en tiempo de ejecución, pero una ABI sí, porque define el lenguaje de la máquina, o tiempo de ejecución, formato.

Cortesía

Su programa (código fuente) se puede compilar con módulos que proporcionan una API adecuada.

Su programa (binario) puede ejecutarse en plataformas que proporcionan ABI adecuado.

La API restringe las definiciones de tipos, las definiciones de funciones, las macros y, a veces, las variables globales que una biblioteca debe exponer.

ABI restringe lo que una "plataforma" debe proporcionar para que su programa se ejecute. Me gusta considerarlo en 3 niveles:

• Nivel de procesador - el conjunto de instrucciones, el calling convention

• Nivel del núcleo - la convención de llamadas al sistema, la convención especial de rutas de archivo (por ejemplo, los archivos /proc y /sys en Linux), etc.

• Nivel del sistema operativo: el formato del objeto , las bibliotecas de tiempo de ejecución, etc.

Considere un compilador cruzado llamado arm-linux-gnueabi-gcc. "arm" indica la arquitectura del procesador, "linux" indica el núcleo, " gnu " indica que sus programas de destino usan libc de GNU como biblioteca de tiempo de ejecución, diferente de arm-linux-androideabi-gcc que usan libc de Android aplicación.