Skip to content
Snippets Groups Projects
  • Simon McVittie's avatar
    5b403eb2
    runtime: Remove overridden libraries from mutable sysroot · 5b403eb2
    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: default avatarSimon McVittie <smcv@collabora.com>
    5b403eb2
    History
    runtime: Remove overridden libraries from mutable sysroot
    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: default avatarSimon McVittie <smcv@collabora.com>