1. 11 Nov, 2019 1 commit
    • Ludovico de Nittis's avatar
      capture-libs: Compare symbols and versions to determine order · fff84ffb
      Ludovico de Nittis authored
      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.
      fff84ffb
  2. 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
  3. 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
  4. 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
  5. 18 Sep, 2019 2 commits
  6. 25 Jul, 2019 1 commit
  7. 24 Jul, 2019 2 commits
  8. 16 Apr, 2019 1 commit
  9. 02 Apr, 2019 10 commits
  10. 30 Jan, 2019 17 commits