- Aug 05, 2024
-
-
Simon McVittie authored
This will allow the output of capsule-capture-libs (and in principle other tools) to be piped to a log handler such as `logger --prio-prefix`, `systemd-cat --level-prefix=true` or `srt-logger --parse-level-prefix` which will filter or format the messages according to their severity. As currently implemented, fatal errors are emitted as LOG_ERR, warnings are LOG_WARNING, and all debug messages are LOG_DEBUG. A facility such as LOG_USER is not included: this is optional for logger(1), and not allowed for systemd-cat(1) and srt-logger. steamrt/tasks#444 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In a couple of places this requires explicitly emitting the stringified value of errno, because we have equivalents of warnx() and errx(), but not warn() and err(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These mimic the behaviour of errx() and warnx(), but will benefit from future enhancements to capsule_log(). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This allows them to be distinguished from messages logged by some other executable invoked around the same time, and makes `capsule_log( LOG_WARNING, ... )` a drop-in substitute for `warnx()`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This will let us change the behaviour of all diagnostic messages at once, by changing only capsule_logv(). For now, the syslog-style severity is accepted but ignored. Subsequent commits will make use of this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We don't enforce a specific error message, but we do assert that there's no output on stdout, and an error message prefixed with the program name on one of the lines of stderr. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 20, 2024
-
-
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
This makes the information from doc/Building-libcapsule.txt more discoverable, and adds more. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- May 16, 2024
-
-
Simon McVittie authored
Because libcapsule uses non-recursive make, G_TEST_SRCDIR and G_TEST_BUILDDIR are set to the top-level directory of the source/build tree. When running the test suite "as-installed", the equivalent for both is `${libexecdir}/installed-tests/libcapsule`. This matters because we locate the "version 1" and "version 2" libraries during testing as `${builddir}/tests/version{1,2}`, which is incorrect (a duplicate `tests/`) if the `${builddir}` is set to the `tests` subdirectory rather than the top-level directory. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Steam Runtime 1 'scout' only has 1.11 as its default version, and that's too old for AM_TESTS_ENVIRONMENT to be respected. It does have 1.15 available, so make sure we have at least that version one way or another. At the moment this is mitigated by the fact that scout only has GLib 2.32, which is too old, and we use --with-glib=auto to skip building and running the one test that uses GLib (utils.t) when building on scout - which happens to be the only test where correct handling of AM_TESTS_ENVIRONMENT was strictly required. However, if we backport a newer GLib into scout, we'll start running that test, and therefore we'll need it to work. steamrt/tasks#112 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Mar 05, 2024
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
The ld_libs data structure is pre-allocated at maximum size instead of using dynamic memory allocation, in an effort to avoid use of malloc() during critical-path interactions with basic shared library infrastructure. This makes it about 1 MiB, so if users have reduced RLIMIT_STACK from its post-1995 default of 8 MiB for whatever reason, it doesn't take many levels of recursion to exceed that limit. The symptom for a stack overflow is particularly un-diagnosable (instead of exiting unsuccessfully with an error message, the program will just segfault), so allocate this data structure on the heap instead, which gives us the opportunity to log "libcapsule: out of memory". The equivalent data structures within libcapsule itself are still allocated on the stack, to avoid introducing new memory allocation inside a critical section. Resolves: https://github.com/ValveSoftware/steam-runtime/issues/653 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In zlib 1.3 (2023), the version is exactly libz.so.1.3, with no third version component. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 28, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Some parts of libcapsule are sufficiently low-level to want to avoid calling malloc(), instead using PATH_MAX-sized buffers and an assumption that paths are, in practice, smaller than that. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 26, 2023
-
-
Simon McVittie authored
libcrypt.so.1 is build-time optional since glibc 2.28, and is not built by default since 2.38. In newer distributions like Debian >= 11 and Ubuntu >= 20.04, it's usually replaced by libxcrypt, either compiled to be a drop-in replacement for glibc's libcrypt.so.1 (as in Debian, and therefore the Steam Runtime), or with its own SONAME libcrypt.so.2 and optionally a secondary build as libcrypt.so.1 (as in Arch). Because libxcrypt implements a superset of the glibc libcrypt.so.1 ABI, adding some functions and symvers of its own, it is backward- but not forward-compatible: it's OK to use libxcrypt libcrypt.so.1 as a replacement for glibc libcrypt.so.1, but it is not OK to do the opposite. This means it would be incorrect for us to use a system copy of glibc libcrypt.so.1 (perhaps from glibc 2.32 or newer) as a replacement for a container's libxcrypt libcrypt.so.1, even if the system copy of glibc is strictly newer than the container's glibc (for example, Steam Runtime 3 'sniper' is based on Debian 11, so it comes with glibc 2.31 and libxcrypt). Unlike libpthread, libdl and librt, symbols from `libcrypt.so.1` were never absorbed into `libc.so.6`, so we don't have to apply the reasoning seen in 4c2e3e3b "capture-libs: Add a special case to support glibc 2.34+". In practice we've always got away with it in the past, but it's something that could cause a crash or incompatibility. I'm now looking into the possibility of backporting libxcrypt into Steam Runtime 1 and 2 (steamrt/tasks#332), which makes it more important to get this right. Accordingly, exclude libcrypt.so.1 from that special treatment, and instead set it up to be compared separately using the same comparators we use for glibc: by public symvers, then by public symbols, and as a last resort by name. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
These are only directly used within their translation unit, therefore don't need to be extern. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Just for completeness, we're not going to support any of these any time soon. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 02, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Now that the tests pass on merged-/usr systems, we can use a more modern Debian suite. Normally I'd use the latest Debian stable (Debian 12), but that seems to have a false positive for a printf argument to %s being NULL, causing the asan/ubsan builds to fail; so use Debian 10 and 11 as our representatives of older systems, together with Debian 13 prereleases as our representative of a modern system. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, we were assuming that the symlink created by capsule-capture-libs would point to the `realpath()` of a library, possibly with a `--link-target` prefix. However, it actually only resolves the symlink representing the SONAME: it will resolve `libz.so.1` to `libz.so.1.2.13`, but unlike Perl `abs_path()` or C `realpath()`, it will not necessarily resolve symlinks in the directory hierarchy leading up to that point. For example, on a merged-/usr system like Debian >= 12, /lib is a symbolic link to usr/lib. The realpath() of `libz.so.1` is something like `/usr/lib/MULTIARCH/libz.so.1.2.13`, but because both `/lib/MULTIARCH` and `/usr/lib/MULTIARCH` appear in `/etc/ld.so.conf.d`, it is undefined whether capsule-capture-libs will output `/lib/MULTIARCH/libz.so.1.2.13` or `/usr/lib/MULTIARCH/libz.so.1.2.13`. Relax the expectations of this test so we only say that the symlink points to some reasonable `$libdir`, followed by the `basename()` of the `realpath()` of `libc.so.6`. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
`warn(fmt, args)` is equivalent to (pseudocode) `warnx(fmt + ": %s", args, strerror(errno))`. In contexts where we do not have a useful value for errno, or where we are showing an error message that should already contain a previous result of strerror, we should use warnx() instead. This avoids showing a misleading errno which might have been set for some unrelated reason. Prompted by jupiter/tasks#887. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Aug 01, 2023
-
-
Simon McVittie authored
glibc searches /lib:/usr/lib as a hard-coded fallback, but we don't expect to get there when searching for dependencies in practice: on OSs that have dedicated 32- and 64-bit directories (such as Red-Hat-style multilib, Arch-style multilib and Debian-style multiarch), those directories are searched indirectly as part of ld.so.cache. Mentioning that this is a fallback makes it a little bit more obvious that it isn't an error that we were not searching /usr/lib32, /usr/lib64 or /usr/lib/MULTIARCH when looking for a library of the appropriate word size. While I'm here, deduplicate the end of the message a bit. Suggested-by: Emil Velikov Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
If one of these happens, then something odd is going on and we should diagnose it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This avoids having to turn on noisier options that CAPSULE_DEBUG=tool to see this. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Debian 9 is way past end-of-life and has now been removed from the main Debian mirrors, causing CI to fail. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 27, 2023
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 06, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Ludovico de Nittis authored
Add a stricter version of `soname:`, where a library is considered to be a match only if its DT_SONAME is exactly what capture-libs was asked to look into. This can be used as a protection against misconfigured systems where two incompatible libraries have been symlinked. E.g. if there is an unexpected symlink `libudev.so.0 -> libudev.so.1`, with `soname:libudev.so.0` we will import `libudev.so.0` inside the container even if its DT_SONAME is `libudev.so.1`. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com>
-
- Jun 23, 2022
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 22, 2022
-
-
Simon McVittie authored
Some non-FHS operating systems like NixOS are heavily reliant on DT_RUNPATH. Unlike the old DT_RPATH, DT_RUNPATH is relatively simple to implement: if an object libdependent depends on another object libdependency, only the DT_RUNPATH of libdependent is used to search for libdependency (the DT_RUNPATHs of "larger" libraries or the executable are ignored). DT_RPATH is not implemented here, because it's more difficult: we would have to do what ld.so does, which is to build up a stack with the object that loaded the object that loaded (etc.) the object that loaded the one we are currently considering, and walk all the way up the stack looking for RPATHs. Helps: https://github.com/ValveSoftware/steam-runtime/issues/511 Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 26, 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
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Oct 25, 2021
-
-
Ludovico de Nittis authored
The flag `CAPTURE_FLAG_EVEN_IF_OLDER` is not supposed to be considered pertinent if we are checking a library dependency. For this reason when we evaluate if a library dependency is a glibc sub-lib, we should skip checking if `CAPTURE_FLAG_EVEN_IF_OLDER` is set. This fixes an issue when capturing libraries with the pattern `gl:`, while using an host system with glibc <= 2.33 and a container with glibc >= 2.34. In this situation we were wrongly choosing `libpthread.so.0` from the provider and `libc.so.6` from the container. Signed-off-by:
Ludovico de Nittis <ludovico.denittis@collabora.com> Co-authored-by:
Simon McVittie <smcv@collabora.com>
-