- Jul 07, 2020
-
-
Simon McVittie authored
This assumes either a C11 compiler, or as a fallback, a tolerably new version of gcc. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 12, 2020
-
-
Simon McVittie authored
This is what was documented to happen. Previously, we did not clear the entry if we failed to open the library fd, or if we succeeded but the library was "unacceptable" (wrong ELF class or machine tag). Normally this results in a minor memory leak, and a fd leak if the library is "unacceptable". However, when called from search_ldcache_cb(), it's particularly important that we do this, because search_ldcache() uses the state of the fd field - valid fd or not - to check whether ld_lib_open() succeeded. One practical symptom is that if your container has an x86_64 libfoo.so.0 that compares newer than the provider's libfoo.so.0, and does not have an i386 libfoo.so.0, then capsule-capture-libs would unexpectedly not capture the i386 libfoo.so.0 from the provider either. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jun 03, 2020
-
-
Simon McVittie authored
The pressure-vessel tool used in the Steam Runtime has an increasingly long list of graphics libraries which might be better as a file than on the command-line. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 14, 2019
-
-
Simon McVittie authored
This crashes when tests/capture-libs.pl loads libgobject-2.0.so.0 on Debian 10 'buster' or on Debian unstable: Stack trace of thread 87172: #0 0x00007f6cad431176 g_slice_free1 (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2) #1 0x00007f6cad431bc0 g_slist_remove (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2) #2 0x00007f6cad43bf47 g_once_init_leave (/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.6200.2) #3 0x00007f6cad4f8e24 n/a (/tmp/fpzde0iMLo/host/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.6200.2) I suspect this might be because the version of GLib in /usr and the version in /tmp/.../host/usr both get loaded into the same address space? This reverts commit fff84ffb. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Nov 11, 2019
-
-
Simon McVittie authored
I don't know the right predefined macros to detect these, so they're just comments for possible future reference. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We have no plans to support big-endian 64-bit ARM, but since we have a reasonably comprehensive list here, we might as well include it. Reference: <https://wiki.debian.org/Multiarch/Tuples>, <https://sourceware.org/glibc/wiki/ABIList#aarch64 > Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This was probably copy/paste damage from some other architecture. According to https://sourceware.org/glibc/wiki/ABIList these architectures are 32-bit (or technically 31-bit for s390) and install their ld.so in /lib. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
When two libraries have the same numeric tail we were not able to reliably determine which one was the newer. Now we also check the libraries definitions and the symbols to make a more weighted decision. The order of comparison is currently: compare version definitions > compare numeric tail > one has strictly more symbols If even after these three checks we are still not sure which one to choose, we pick the provider as the default.
-
- Sep 26, 2019
-
-
Simon McVittie authored
On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most shared libraries. However, on Fedora 30 it is a symlink to a versioned name like libgcc_s-9-20190827.so.1. The name used in Fedora happens to be less than libgcc_s.so.1 in strverscmp() order, causing capsule-capture-libs to prefer the Debian/Manjaro libgcc_s.so.1, even if the container is older. This can cause problems if an old Debian-derived container like the Steam Runtime is used on a newer Fedora host, with host graphics drivers imported by using capsule-capture-libs: the container's libgcc_s.so.1 does not satisfy the versioned symbol requirements of the graphics driver, causing loading to fail. Treat a regular file libgcc_s.so.1 as indeterminate order (or "equal"), so that we fall back to the default behaviour, which is currently to take the host version of the library in the case of a tie. This is a stopgap solution: ideally we would consider the versioned symbols exported by both libraries, and take whichever one has a superset of the version definitions exported by the other, if there is a strict superset in either direction (in the case of libgcc, in fact there is). Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This reverts commit faf3daa9, which was merged with an outdated commit message. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Sep 19, 2019
-
-
Simon McVittie authored
On at least Debian, Ubuntu and Manjaro, libgcc_s.so.1 is a regular file, not a symlink to a versioned name (libgcc_s.so.1.2.3) like most shared libraries. However, on Fedora 30 it is a symlink to a versioned name like libgcc_s-9-20190827.so.1. This can cause problems if a Debian-derived container is used on a Fedora host, with host graphics drivers. TODO: it isn't clear whether this change makes any practical difference, because strverscmp("libgcc_s.so.1", "libgcc_s-9-20190827.so.1") == 0 anyway.
-
- Sep 18, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 25, 2019
-
-
Simon McVittie authored
They now all take named options (including the -- pseudo-option) for future expansion, and fail with an error if given too many positional parameters. When libcapsule tools are bundled with a larger project, this should make it easier to check which ones they are. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jul 24, 2019
-
-
Simon McVittie authored
On Red Hat-derived OSs, /usr/lib/dri contains 32-bit drivers (with their 64-bit equivalents in /usr/lib64/dri), but on Arch Linux-derived OSs it contains 64-bit drivers (with their 32-bit equivalents in /usr/lib32/dri). As a result, we have to run both i386-linux-gnu-capsule-capture-libs and x86_64-linux-gnu-capsule-capture-libs against if-exists:path-match:/usr/lib/dri/*.so, ignoring anything we find that is of the other word-size. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 16, 2019
-
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 02, 2019
-
-
Simon McVittie authored
Ideally we should bubble up errors to the caller rather than silently truncating, but if we have to truncate, let's at least be sufficiently explicit about it that gcc 8 doesn't sulk. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Without this, we fall through to the case for DT_BIND_NOW, which will log a misleading debug message before breaking out of the switch. Thanks, gcc 8! Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 30, 2019
-
-
Simon McVittie authored
This was introduced in 2013, and Ubuntu 12.04's glibc 2.15 doesn't have it. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
In Ubuntu 12.04, this is declared in a header that we include. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
On Ubuntu 12.04, this function is declared in a header that we include. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 27, 2018
-
-
Simon McVittie authored
The shared library could conceivably get linked into something at a privilege boundary, but the tools have no such requirement. This means we can reduce our glibc dependencies when not building the actual library. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
This is useful if you want to bundle a complete dependency stack but use the host libc, like the Steam Runtime has traditionally done. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 26, 2018
-
-
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
In particular this is enough to capture the dependencies of the Mesa DRI drivers: $ capsule-capture-libs --dest=lib \ only-dependencies:path-match:"/usr/lib/x86_64-linux-gnu/dri/*.so" $ ls lib libbsd.so.0 libc.so.6 libdl.so.2 libdrm_amdgpu.so.1 # etc. and the drivers themselves: $ capsule-capture-libs --dest=mesa-drivers \ no-dependencies:path-match:"/usr/lib/x86_64-linux-gnu/dri/*.so" $ ls mesa-drivers i915_dri.so # etc. in separate batches. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Apr 24, 2018
-
-
Simon McVittie authored
For Mesa DRI drivers, we will need to capture the dependencies but not the driver itself, because we load the driver itself by setting LIBGL_DRIVERS_PATH instead. I don't have a concrete use-case for no-dependencies:, which is implemented for symmetry. 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>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
We still do this for unadorned wildcards, but explicit is better than implicit. 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
We can set needed[0] to the absolute path to a loadable module, and in fact we will need to do that when collecting the dependencies of a Mesa DRI driver. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Previously, we just used strrchr(), but that didn't actually return the basename as in basename(1): we were comparing strings like "/libc-2.17.so" or "/libglib-2.0.so.0.5600.0". Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
- Jan 03, 2018
-
-
Vivek Das Mohapatra authored
-
- Dec 20, 2017
-
-
Simon McVittie authored
~/.local/share/Steam/ubuntu12_32/steam has a symbol with a weird binding type part way through its symbol table: 46 [OBJECT LOOS/GNU_UNIQUE] size: 0 (0)_ZNSs4_Rep20_S_empty_rep_storageE 0000 (nil) but we can't just stop there, because there are symbols after it that need relocating. I blame C++. Signed-off-by:
Simon McVittie <smcv@collabora.com>
-
Simon McVittie authored
Signed-off-by:
Simon McVittie <smcv@collabora.com>
-