An error occurred while fetching folder content.

Simon McVittie
authored
We currently arrange for the overridden libraries to be used by setting the LD_LIBRARY_PATH, but this fails in two cases: - If we want to use the scout LD_LIBRARY_PATH Steam Runtime inside a newer container (approximating how Steam games currently run in practice), it will reset the LD_LIBRARY_PATH instead of prepending to it. - Games also sometimes overwrite the LD_LIBRARY_PATH instead of prepending to it. We can avoid all that by arranging for our directories in /overrides to be in the default search path for ld.so, by editing ld.so.conf and running ldconfig, like Flatpak does (T14481). However, if we do that, we cannot reliably force a resolution order: ldconfig considers the OS ABI tag, which exists on some libraries and in particular on the versions of glibc and Mesa in scout, to be more important than directory search order. See also: https://bugs.freedesktop.org/show_bug.cgi?id=26663 If we don't remove the unwanted version of glibc, we also run the risk of encountering mismatched copies of glibc and ld.so, leading to an immediate crash. This is particularly likely to happen if we use bwrap to enter the partially-set-up container. Because we have a temporary mutable copy of the sysroot, we can solve this easily by deleting the overridden libraries. That way, there can be no confusion: the only remaining implementation of each SONAME is the one we wanted :-) Note that after removing the overridden libraries, we will be unable to execute code in the sysroot without mounting /overrides/lib and setting up the LD_LIBRARY_PATH to point into it: for example, in the common case where we have taken libc from the host, the mutable sysroot no longer contains libc.so.6. This is why it's so important that a previous commit avoided the call to readlink(1) inside the container for the mutable case. Signed-off-by:Simon McVittie <smcv@collabora.com>
Name | Last commit | Last update |
---|