Skip to content
Snippets Groups Projects
  1. Jun 24, 2020
  2. Jun 16, 2020
  3. Jun 12, 2020
    • Simon McVittie's avatar
      d/changelog: Update · 488eedd9
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      488eedd9
    • Simon McVittie's avatar
      ld-libs: Always clear ldlibs->needed entry if ld_lib_open() fails · ac3f0295
      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: default avatarSimon McVittie <smcv@collabora.com>
      ac3f0295
  4. Jun 03, 2020
  5. Mar 13, 2020
  6. Mar 12, 2020
    • Simon McVittie's avatar
      CI: Codify how to build on Arch Linux · 1fd9e54b
      Simon McVittie authored
      
      Some libcapsule users and contributors are using Arch Linux or Manjaro
      rather than a Debian derivative.
      
      Many of the tests will be skipped on Gitlab-CI because they need a
      working bubblewrap, which isn't allowed inside unprivileged Docker;
      but this provides "executable documentation" for how to do a build
      and test.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      1fd9e54b
  7. Jan 16, 2020
  8. Jan 15, 2020
  9. Nov 14, 2019
    • Simon McVittie's avatar
      ci: Use smaller CI images · 28e86dd1
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      28e86dd1
    • Simon McVittie's avatar
      Revert "capture-libs: Compare symbols and versions to determine order" · 6d9833be
      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: default avatarSimon McVittie <smcv@collabora.com>
      6d9833be
  10. Nov 11, 2019
  11. Oct 02, 2019
    • Simon McVittie's avatar
      build: Check that the compiler and --host are consistent · 8bf9b114
      Simon McVittie authored
      
      libcapsule's use with biarch containers like the Steam Runtime will
      frequently make it necessary to compile it for both x86_64 and i386.
      
      On recent Debian-derived OSs this is OK, because the toolchain is
      provided as a complete set of cross-compiler-style prefixed tools like
      i686-linux-gnu-gcc; but some OSs, like Arch Linux and very old versions
      of Debian, rely on 'gcc -m32' for their biarch support. This makes it
      very easy to do
      
          ./configure --build=x86_64-linux-gnu --host=i686-linux-gnu
      
      and accidentally produce x86_64 binaries, because there is no
      i686-linux-gnu-gcc. Give the user a hint towards the correct invocation
      in this case, which is:
      
          ./configure --build=x86_64-linux-gnu --host=i686-linux-gnu CC='gcc -m32'
      
      I've implemented this as a reusable macro, in case we want to add it to
      other projects that are likely to be cross-compiled by inexperienced
      cross-compiler users.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      8bf9b114
  12. Sep 26, 2019
    • Simon McVittie's avatar
      Add basic Gitlab-CI using deb-build-snapshot · 610c7004
      Simon McVittie authored
      
      This verifies that libcapsule compiles and works on Debian 9,
      Ubuntu 18.04 and Debian 10.
      
      To use, change your libcapsule fork's CI/CD settings to include:
      
          Custom CI config path: ci/gitlab-ci.yml
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      610c7004
    • Simon McVittie's avatar
      Prepare v0.20190926.0 · da30b75e
      Simon McVittie authored
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      v0.20190926.0
      da30b75e
    • Simon McVittie's avatar
      capture-libs: Treat unversioned libraries as in indeterminate order · d3d888c9
      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: default avatarSimon McVittie <smcv@collabora.com>
      d3d888c9
    • Simon McVittie's avatar
      Revert "WIP: capture-libs: Treat unversioned libraries as in indeterminate order" · 702fc558
      Simon McVittie authored
      
      This reverts commit faf3daa9, which
      was merged with an outdated commit message.
      
      Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
      702fc558
  13. Sep 19, 2019
    • Simon McVittie's avatar
      WIP: capture-libs: Treat unversioned libraries as in indeterminate order · faf3daa9
      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.
      faf3daa9
  14. Sep 18, 2019
  15. Jul 25, 2019
  16. Jul 24, 2019
  17. Apr 16, 2019
  18. Apr 02, 2019
Loading