1. 14 Nov, 2019 2 commits
    • Simon McVittie's avatar
      ci: Use smaller CI images · 28e86dd1
      Simon McVittie authored
      Signed-off-by: Simon McVittie's 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: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      6d9833be
  2. 11 Nov, 2019 4 commits
  3. 02 Oct, 2019 1 commit
    • 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: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      8bf9b114
  4. 26 Sep, 2019 4 commits
    • 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: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      610c7004
    • Simon McVittie's avatar
      Prepare v0.20190926.0 · da30b75e
      Simon McVittie authored
      Signed-off-by: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      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: Simon McVittie's 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: Simon McVittie's avatarSimon McVittie <smcv@collabora.com>
      702fc558
  5. 19 Sep, 2019 1 commit
    • 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
  6. 18 Sep, 2019 2 commits
  7. 25 Jul, 2019 1 commit
  8. 24 Jul, 2019 2 commits
  9. 16 Apr, 2019 1 commit
  10. 02 Apr, 2019 10 commits
  11. 30 Jan, 2019 12 commits