- Aug 09, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
pressure-vessel: Fix regression regenerating ld.so.cache on Ubuntu and older Debian See merge request !358
-
Simon McVittie authored
In Ubuntu and older versions of Debian, /sbin/ldconfig is a shell script that wraps /sbin/ldconfig.real. To make it possible to run /sbin/ldconfig, we have to map /sbin/ldconfig.real into the container too. Resolves: T29764 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Before !338 (T14481), we relied on the LD_LIBRARY_PATH as our way to find libraries from the graphics stack provider (host system or Flatpak runtime), both /overrides/lib/MULTIARCH and /overrides/lib/MULTIARCH/aliases. However, this was not robust against games that (incorrectly) reset the LD_LIBRARY_PATH in their startup scripts, such as Dead Cells, Evoland Legendary Edition and Shenzhen I/O. Since !338, we maintain three separate library search paths: 1. The LD_LIBRARY_PATH that is used to run pv-adverb is the same as before. (This is getenv("LD_LIBRARY_PATH") in pv-adverb code.) 2. Library directories that contain libraries named by their SONAME (/overrides/lib/MULTIARCH) are prepended to ld.so.conf, after which we invoke ldconfig to regenerate ld.so.cache. This means games that reset the LD_LIBRARY_PATH will effectively still search /overrides/lib/MULTIARCH, as a result of the usual logic that reads ld.so.cache. (This is global_ld_so_conf_entries in pv-adverb code.) 3. Library directories that contain libraries not named by their SONAME (/overrides/lib/MULTIARCH/aliases) still need to be in the LD_LIBRARY_PATH, because ld.so.cache only lists libraries by their SONAMEs, so we still need to put these library directories in the LD_LIBRARY_PATH before invoking the actual game. (This is opt_set_ld_library_path in pv-adverb code.) This worked fine on systems like Debian 11 and Arch, but is unnecessarily fragile: if running ldconfig failed, there was no fallback, and the game would simply not launch correctly. In particular, ldconfig can fail to run on Ubuntu and old Debian systems (prior to Debian 9), as a result of a workaround involving /sbin/ldconfig being made a shell script wrapper around /sbin/ldconfig.real. We can mitigate this failure by falling back to the old (pre-!338) logic if ldconfig fails, with a warning. Games like Dead Cells will still not launch successfully in this mode, but better-behaved games (including most native Linux titles and all Proton titles) will survive. A subtlety here is that when we fall back, we need to find both /overrides/lib/MULTIARCH and /overrides/lib/MULTIARCH/aliases in the LD_LIBRARY_PATH; so we discard search paths 2 and 3, and keep using search path 1 for the actual game, not just pv-adverb. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We can make it easier to diagnose ldconfig failures by including the stderr from the failing ldconfig command in our error message. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 06, 2021
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Fix test failures with --no-copy-runtime See merge request !357
-
Simon McVittie authored
We still regenerate ld.so.cache to limit the number of code paths, but we can't completely rely on it in this case for the reasons given in the comment. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Instead of being overly specific, let's assert that what we want to be true is true. We want to see /overrides/lib/MULTIARCH in either the ld.so.conf or the LD_LIBRARY_PATH, and /overrides/lib/MULTIARCH/aliases in the LD_LIBRARY_PATH specifically. If /overrides is not a symbolic link, then we want to find exactly /overrides/lib/MULTIARCH in those places. If it is a symbolic link, then we might see either /overrides/lib/MULTIARCH or /usr/lib/pressure-vessel/overrides/lib/MULTIARCH; which one of those we get is an implementation detail, but it must exist. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
pv-runtime: Never bind-mount /etc/ld.so.cache, /etc/ld.so.conf See merge request !356
-
Simon McVittie authored
bind_runtime_ld_so() is called whenever bwrap != NULL, and it makes /etc/ld.so.cache, /etc/ld.so.conf into symlinks to /run/pressure-vessel/ldso/ so that we can regenerate ld.so.cache in the adverb. This is done whether we have a mutable sysroot or not. This resolves an automated test failure when running with --no-copy-runtime. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
pv-runtime: Refactor how we deal with regenerating ld.so.cache Closes #74 See merge request !355
-
Simon McVittie authored
pressure-vessel: Remap preloadable modules better See merge request !337
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is a bit complicated, because there are two reasonable things that people might use LD_PRELOAD for, and in this mode it's particularly important to distinguish between them. One is to inject arbitrary code, like MangoHud or fakeroot. In this case, we want to take the loadable module from the namespace in which the user initiated pv-wrap. We can do this the same way we deal with the ${LIB} and ${PLATFORM} dynamic string tokens: load it once per ABI, pass a separate option to pv-adverb for each one, and let pv-adverb recombine them. The other is to work around libraries not being loaded soon enough, like the way people sometimes use LD_PRELOAD="libpthread.so.0 libGL.so.1" to force an optirun library to be loaded. In this case, we absolutely do not want to import the host library of that name into the container unconditionally, because if we do, it will sabotage our careful efforts to get the correct instance of libpthread.so.0 to be chosen. In this case, assume that the user meant "take whatever libpthread.so.0 you would naturally load, and preload it into each executable". Resolves: https://github.com/ValveSoftware/steam-runtime/issues/435 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The PvRuntime already provides pv-wrap with a pre-configured pv-adverb command-line, so we can repurpose that to include the necessary command-line options to regenerate the ld.so.cache the way we want it. Resolves: #74 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This partially resolves <https://github.com/ValveSoftware/steam-runtime/issues/435 >, for the case where MangoHud was built with `-Dld_libdir_abs=true`, as in the upstream `build.sh` or upstream binary releases. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We need to do this as highest-priority, since it invalidates the cleverer reasoning that we should be applying to LIB and PLATFORM. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This doesn't make any practical difference yet, but it sets us up to be able to carry out finer-grained processing based on the loadable_flags. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
FlatpakExports isn't going to export relative paths anyway. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In reality, we have a FlatpakExports if and only if we are not creating a Flatpak subsandbox. If a caller somehow passes in a FlatpakExports while creating a subsandbox, it's harmless to tell it what to export. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Most of this code can be shared between the Flatpak and non-Flatpak code paths, avoiding internal duplication. In future, we will also want to call into append_preload_internal() when we split up something like /usr/$LIB/mangohud/libMangoHud.so or /opt/plat-$PLATFORM/mypreload.so into a separate path per supported architecture: in such cases, we will still have to rewrite /usr into /run/host/usr, and add /opt/plat-*/mypreload.so to the FlatpakExports. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We need to remap these into something that can be loaded successfully in the container, but we don't yet. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
PreloadModule is no longer used in pv-adverb, because we needed a different data structure there. Do a similar transformation here. This turns it inside out: instead of what's conceptually map<variable=LD_AUDIT or LD_PRELOAD, values=array<string>> we now have array<struct<variable=LD_AUDIT or LD_PRELOAD, string>> which is a bit easier to deal with in practice. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This has almost full branch coverage. We don't currently cover the case where STEAM_COMPAT_CLIENT_INSTALL_PATH is not set, but that's trivial anyway (we treat all paths as not matching it). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
An entry in LD_PRELOAD may be a bare SONAME like "libMangoHud.so", or a path containing special tokens like "/usr/$LIB/libMangoHud.so", or a literal path. Only literal paths are going to physically exist on disk. For a path containing special tokens, we can still try to remap it, for example /usr/$LIB/libMangoHud.so to /run/host/usr/$LIB/libMangoHud.so. This is imperfect (if the host and container glibc disagree on the meaning of $LIB, then we won't load it correctly), but it's better than nothing. A subsequent commit will improve the handling of paths that contain special tokens. For a bare SONAME, we just pass it through as-is for now, as though it was a relative path. This is also imperfect, but better than nothing. Another reason to want to make this change is that it allows us to unit-test this function: it's difficult to make assertions about the behaviour of a function that touches areas of the filesystem that are not under the control of the unit tests. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This allows mock environment variables to be used during unit testing. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This reduces the size of wrap.c, which is something we should be careful to keep under control. It also allows us to unit-test this code. Code changes made while factoring this out: * `flatpak_subsandbox` and `opt_remove_game_overlay` go via flags * `adverb_preload_argv` becomes `argv` * `return` instead of `continue` since pv_wrap_append_preload() is only one loop iteration Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
runtime: When copying the runtime, generate a new /etc/ld.so.cache See merge request !338
-
This avoids relying on the LD_LIBRARY_PATH as a way to get the overridden libraries into place. Co-authored-by:
Simon McVittie <smcv@collabora.com> Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
Simon McVittie authored
Revert "pressure-vessel: Add support for the env var STEAM_COMPAT_FLAGS" See merge request !351
-
Ludovico de Nittis authored
Flag most G_OPTION_ARG_CALLBACK options with G_OPTION_FLAG_FILENAME See merge request !354
-