On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular
file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most
shared libraries.

However, on Fedora 30 it is a symlink to a versioned name like
libgcc_s-9-20190827.so.1. The name used in Fedora happens to be less
than libgcc_s.so.1 in strverscmp() order, causing capsule-capture-libs
to prefer the Debian/Manjaro libgcc_s.so.1, even if the container is
older. This can cause problems if an old Debian-derived container like the
Steam Runtime is used on a newer Fedora host, with host graphics drivers
imported by using capsule-capture-libs: the container's libgcc_s.so.1
does not satisfy the versioned symbol requirements of the graphics driver,
causing loading to fail.

Treat a regular file libgcc_s.so.1 as indeterminate order (or "equal"),
so that we fall back to the default behaviour, which is currently to
take the host version of the library in the case of a tie.

This is a stopgap solution: ideally we would consider the versioned
symbols exported by both libraries, and take whichever one has a superset
of the version definitions exported by the other, if there is a strict
superset in either direction (in the case of libgcc, in fact there is).

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