- Aug 17, 2021
-
-
Simon McVittie authored
We are using --copy-runtime mode in production, it's the only thing that can work in Flatpak, and it's currently the only thing that will work on Ubuntu 20.04 and older Debian due to their use of /sbin/ldconfig.real (see !358), so we should try harder to make use of it. The only time we should not be copying the runtime is when we don't have a variable directory to copy it into, or when explicitly told not to for testing purposes. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
build-aux: Move sysroot convenience scripts to here See merge request !360
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We already have a REUSE-compliant copy of the GPL version 3 in LICENSES/GPL-3.0-or-later.txt. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
populate-depot.py: Update from SteamLinuxRuntime v0.20210806.0 See merge request !359
-
Simon McVittie authored
During CI testing, we know we are working with a pressure-vessel relocatable tarball, so let's specify that explicitly. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Originally part or all of these commits: * steamlinuxruntime@8b0b5a03 "populate-depot: Remove unused support for loading JSON from a file" * steamlinuxruntime@084f4e11 "populate-depot: Add more explicit versions of --pressure-vessel" * steamlinuxruntime@392878db "Add support for downloading a standalone pressure-vessel release" * steamlinuxruntime@4e2a5628 "scout-on-soldier: Fail if toolmanifest.vdf has not been reloaded" * steamlinuxruntime@ae46edab "populate-depot: Use a standalone pressure-vessel release by default" * steamlinuxruntime@b3f00ee2 "populate-depot: Use latest scout build for LD_LIBRARY_PATH runtime" * steamlinuxruntime@5eb43c40 "populate-depot: Store LD_LIBRARY_PATH version in layered scout runtime" * steamlinuxruntime@a10a407e "populate-depot: Have an overall version number for the depot as a whole" all written by me. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- 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>
-