abicompat1

--app-debug-info-dir | --appd <path-to-app-debug-info-directory>

Set the path to the directory under which the debug information of the application is supposed to be laid out. This is useful for application binaries for which the debug info is in a separate set of files.

--btf

When comparing binaries, extract ABI information from BTF debug information, if present.

--ctf

When comparing binaries, extract ABI information from CTF debug information, if present.

--fail-no-debug-info

If no debug info was found, then this option makes the program to fail. Otherwise, without this option, the program will attempt to compare properties of the binaries that are not related to debug info, like pure ELF properties.

--help

Display a short help about the command and exit.

--ignore-soname

Ignore differences in the SONAME when doing a comparison

--lib-debug-info-dir1 | --libd1 <path-to-lib1-debug-info>

Set the path to the directory under which the debug information of the first version of the shared library is supposed to be laid out. This is useful for shared library binaries for which the debug info is in a separate set of files.

--lib-debug-info-dir2 | --libd2 <path-to-lib1-debug-info>

Set the path to the directory under which the debug information of the second version of the shared library is supposed to be laid out. This is useful for shared library binaries for which the debug info is in a separate set of files.

--list-undefined-symbols | -u

Display the list of undefined symbols of the application and exit.

--no-show-locs

--show-base-names | -b

In the resulting report emitted by the tool, this option makes the application and libraries be referred to by their base names only; not by a full absolute name. This can be useful for use in scripts that wants to compare names of the application and libraries independently of what their directory names are.

--suppressions | --suppr <path-to-suppressions>

Use a suppression specification <#suppr-spec-label> file located at path-to-suppressions. Note that this option can appear multiple times on the command line; all the suppression specification files are then taken into account.

--version | -v

Display the version of the program and exit.

--thread-pool-size <N|N%> | -j <N|N%>

Set the size of the thread pool used by Libabigail for parallel processing. The size is either the number of threads or a percentage of the total number of available cores on the machine. By default, all the available cores of the machine are used for parallel processing.

Note that the environment variable ABIGAIL_THREAD_POOL_SIZE can also be set to similar values. This command line option, if present, supersedes the value of the environment variable.

--weak-mode

This triggers the weak mode of abicompat. In this mode, only one version of the library is required. That is, abicompat is invoked like this:

abicompat --weak-mode <the-application> <the-library>

Note that the --weak-mode option can even be omitted if only one version of the library is given, along with the application; in that case, abicompat automatically switches to operate in weak mode:

abicompat <the-application> <the-library>

In this weak mode, the types of functions and variables exported by the library and consumed by the application (as in, the symbols of the these functions and variables are undefined in the application and are defined and exported by the library) are compared to the version of these types as expected by the application. And if these two versions of types are different, abicompat tells the user what the differences are.

In other words, in this mode, abicompat checks that the types of the functions and variables exported by the library mean the same thing as what the application expects, as far as the ABI is concerned.

Note that in this mode, abicompat doesn't detect exported functions or variables (symbols) that are expected by the application but that are removed from the library. That is why it is called weak mode.

Detecting a possible ABI incompatibility in a new shared library version:

$ cat -n test0.h
     1  struct foo
     2  {
     3    int m0;
     4
     5    foo()
     6      : m0()
     7    {}
     8  };
     9
    10  foo*
    11  first_func();
    12
    13  void
    14  second_func(foo&);
    15
    16  void
    17  third_func();
$
$ cat -n test-app.cc
     1  // Compile with:
     2  //  g++ -g -Wall -o test-app -L. -ltest-0 test-app.cc
     3
     4  #include "test0.h"
     5
     6  int
     7  main()
     8  {
     9    foo* f = first_func();
    10    second_func(*f);
    11    return 0;
    12  }
$
$ cat -n test0.cc
     1  // Compile this with:
     2  //  g++ -g -Wall -shared -o libtest-0.so test0.cc
     3
     4  #include "test0.h"
     5
     6  foo*
     7  first_func()
     8  {
     9    foo* f = new foo();
    10    return f;
    11  }
    12
    13  void
    14  second_func(foo&)
    15  {
    16  }
    17
    18  void
    19  third_func()
    20  {
    21  }
$
$ cat -n test1.h
     1  struct foo
     2  {
     3    int  m0;
     4    char m1; /* <-- a new member got added here! */
     5
     6    foo()
     7    : m0(),
     8      m1()
     9    {}
    10  };
    11
    12  foo*
    13  first_func();
    14
    15  void
    16  second_func(foo&);
    17
    18  void
    19  third_func();
$
$ cat -n test1.cc
     1  // Compile this with:
     2  //  g++ -g -Wall -shared -o libtest-1.so test1.cc
     3
     4  #include "test1.h"
     5
     6  foo*
     7  first_func()
     8  {
     9    foo* f = new foo();
    10    return f;
    11  }
    12
    13  void
    14  second_func(foo&)
    15  {
    16  }
    17
    18  /* Let's comment out the definition of third_func()
    19     void
    20     third_func()
    21     {
    22     }
    23  */
$