GitLab

Signed-off-by: Simon McVittie <smcv@collabora.com>

This is mainly to give me a version number I can use in other packages'
dependencies.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This gives capsule-capture-libs a source of library-specific knowledge.
For example, if we know that:

  * libgcc_s.so.1 is installed with an unhelpful name, but it uses
    versioned symbols the way you'd hope;
  * libdbus-1.so.3 is installed with a helpful libtool-style name,
    but has private symbols that defeat our current simplistic
    comparisons

then we can express that as:

    [Library libgcc_s.so.1]
    CompareBy=versions;symbols;

    [Library libdbus-1.so.3]
    CompareBy=name;

A runtime that contains a known set of libraries would be a good place
to put library-specific knowledge about those libraries. For example,
the maintainers of the Steam Runtime know what libraries it contains,
and are well-placed to compare those libraries with their counterparts
in mainstream distributions.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This will let us select the comparator to use for individual libraries.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Instead of asserting that the default behaviour is as desired, we now
assert that --compare-by=versions,name,symbols behaves the way it ought
to, and that the default behaviour is unchanged. It looks as though
applying --compare-by=versions,name,symbols indiscriminately could break
more than it fixes.
Signed-off-by: Simon McVittie <smcv@collabora.com>

This is primarily useful for testing and experimenting. Using versions
by default in preference to filenames (--compare-by="versions,name")
looks like it might be viable, but is a destabilising change that we
should test more before considering a change of defaults.

Meanwhile, counting symbols as a fallback (--compare-by="...,symbols")
does not look as safe as we had hoped, because if a library maintainer
has cleaned up their ABI by hiding private symbols without adding any
new symbols, we will sort libraries in exactly the wrong order - and
in reality, that seems to be what has happened in several libraries,
for example libX11.so.6 and libXfixes.so.3.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This is a piece of necessary infrastructure for exposing this as a
command-line option, or even as per-library metadata. We were originally
going to do the equivalent of "versions,name,symbols" unconditionally,
but it looks as though that could break more than it fixes, so let's
be a bit more cautious.
Signed-off-by: Simon McVittie <smcv@collabora.com>

We can pass other state through this, such as the comparators to be
used to compare libraries.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

When two libraries have the same numeric tail we were not able to reliably
determine which one was the newer. In particular, many distributions
install libgcc_s.so.1 as a regular file, rather than a symlink to a
versioned name, so library_cmp_by_name() can't work.

These functions let us also check the library's version-definitions and
the individual symbols, to make a more nuanced decision.

Implementation originally by Ludovico de Nittis, adapted by Simon
McVittie to fit the same signature as library_cmp_by_name() so that
we can call the comparison functions via function pointers, to set up
different comparison weights for each library if necessary. This version
also includes Simon's changes to ignore uninteresting symbols for the
purposes of library comparison, with a list of uninteresting symbols
that are part of various architectures' ABIs, taken from dpkg-gensymbols.
Co-authored-by: Ludovico de Nittis <ludovico.denittis@collabora.com>
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This will let us unit-test it more easily. While I'm moving it,
re-indent it in libcapsule's coding style (4 rather than 2 space
indents).
Signed-off-by: Simon McVittie <smcv@collabora.com>

Inspired by g_ptr_array_free(., FALSE) and g_bytes_unref_to_array(),
this lets us convert a ptr_list into a raw array suitable for use
with qsort() and bsearch().
Signed-off-by: Simon McVittie <smcv@collabora.com>

This assumes either a C11 compiler, or as a fallback, a tolerably new
version of gcc.
Signed-off-by: Simon McVittie <smcv@collabora.com>

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=964457Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

When building with things like AddressSanitizer, we want to apply
instrumentation to the libcapsule library itself, the libcapsule
tools, and the unit tests. However, we do not want to instrument the
tiny libraries that are used as test fixtures, because giving them a
dependency on libasan.so.5 would confuse libcapsule when testing them.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This is what was documented to happen.

Previously, we did not clear the entry if we failed to open the
library fd, or if we succeeded but the library was "unacceptable"
(wrong ELF class or machine tag). Normally this results in a minor
memory leak, and a fd leak if the library is "unacceptable".

However, when called from search_ldcache_cb(), it's particularly
important that we do this, because search_ldcache() uses the state
of the fd field - valid fd or not - to check whether ld_lib_open()
succeeded.

One practical symptom is that if your container has an x86_64
libfoo.so.0 that compares newer than the provider's libfoo.so.0,
and does not have an i386 libfoo.so.0, then capsule-capture-libs
would unexpectedly not capture the i386 libfoo.so.0 from the provider
either.
Signed-off-by: Simon McVittie <smcv@collabora.com>

The pressure-vessel tool used in the Steam Runtime has an increasingly
long list of graphics libraries which might be better as a file
than on the command-line.
Signed-off-by: Simon McVittie <smcv@collabora.com>

The file descriptor pointing to the jobserver is not passed through
the test script, so passing through a MAKEFLAGS environment variable
that refers to it is just going to confuse us.
Signed-off-by: Simon McVittie <smcv@collabora.com>

The linker used in Steam Runtime 1 'scout', which is from several years
ago, doesn't seem to like a symbol being made an alias for a versioned
symbol of the same name. Rename the symbol so that only the versioned
aliases get the same basename.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Some libcapsule users and contributors are using Arch Linux or Manjaro
rather than a Debian derivative.

Many of the tests will be skipped on Gitlab-CI because they need a
working bubblewrap, which isn't allowed inside unprivileged Docker;
but this provides "executable documentation" for how to do a build
and test.
Signed-off-by: Simon McVittie <smcv@collabora.com>

This demonstrates the behaviour we want from !23.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Some tests for capsule-capture-libs will need to compile shared
libraries, even if libcapsule itself is not built.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Arch Linux's perl complains that system() is an undefined function.
I'm not sure why, because it's a standard library facility (and
unlike C system(), it takes a list of arguments rather than using
the shell), but in any case it's easy to avoid.
Signed-off-by: Simon McVittie <smcv@collabora.com>

I occasionally compile libcapsule with clang for better diagnostics.
Redefining typedefs is a C11 feature, which clang 8 won't allow in
C99 mode.
Signed-off-by: Simon McVittie <smcv@collabora.com>

--resolve-ld.so would ideally be the equivalent of realpath or
readlink -f, but in fact it only has special handling for symlinks in
the last position in the pathname (like AT_SYMLINK_NOFOLLOW and
O_NOFOLLOW), leading to different results on at least Arch Linux.

The pressure-vessel utility for which this option was added does not
actually use it any more, so fixing this is not a high priority right now.
Signed-off-by: Simon McVittie <smcv@collabora.com>

This test asserted that libz.so.1 was in /lib/*-linux-gnu* or
/usr/lib/*-linux-gnu*, but on non-Debian operating systems it could
equally well be in /usr/lib32, /usr/lib, /usr/lib64 or even /usr/libx32.
Signed-off-by: Simon McVittie <smcv@collabora.com>

Signed-off-by: Simon McVittie <smcv@collabora.com>

This crashes when tests/capture-libs.pl loads libgobject-2.0.so.0 on
Debian 10 'buster' or on Debian unstable:

    Stack trace of thread 87172:
    #0  0x00007f6cad431176 g_slice_free1 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2)
    #1  0x00007f6cad431bc0 g_slist_remove (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2)
    #2  0x00007f6cad43bf47 g_once_init_leave (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2)
    #3  0x00007f6cad4f8e24 n/a (/tmp/fpzde0iMLo/host/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6200.2)

I suspect this might be because the version of GLib in /usr and the
version in /tmp/.../host/usr both get loaded into the same address
space?

This reverts commit fff84ffb.
Signed-off-by: Simon McVittie <smcv@collabora.com>