The --libtool-version-fallback option will cause elfdeps to
try to use the version information in the shared object's filename
for shared objects that don't provide versioned symbols. This
additional information allows rpm to track minor-version
dependencies.

When dlmopen() loads a library, it runs functions with the
__attribute__((constructor)) function attribute, and when they are
closed, it runs functions with __attribute__((destructor)). This
isn't always safe. Some libraries (like gobject) do not support
being opened and closed, and they'll result in a SEGV if they're
opened more than once. That will happen if elfdeps examines a
shared object that is linked to gobject, and then later another
one (or libgobject itself). However, if we fork and then open
only one shared object and then exit, we don't cause that problem.

These tests are not compatible with fakechroot, for two reasons.
While fakechroot supports dlmopen(), it will convert relative paths
to absolute paths, which prevents library path searching.  The test
could be run from the data directory so that the relative path's
absolute path expansion was correct, and dlmopen() will succeed.
However, linkmap->l_name will have the real path, not a chrooted
path, and when that is passed to readlink(), fakechroot will try
to expand a path that already includes the chroot prefix.  So,
even when the library can be loaded with dlmopen(), the symlink
can't be resolved to find the path that contains the version.

from the symlink target, generate ".elf-version/<so>" files
containing the value of the _elf_so_version macro.  These files
are then used by the elfdeps tool to generate the provides and
requires.