-
Simon McVittie authored
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>
Simon McVittie authoredOn 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>