Skip to content
Snippets Groups Projects
  • Simon McVittie's avatar
    74499151
    Build a shim libcurl that can dispatch to runtime or system copies · 74499151
    Simon McVittie authored
    
    This works around ABI divergence from upstream in the libcurl in
    Debian/Ubuntu between about 2005 and 2018, which unfortunately includes
    the time at which Steam Runtime 1 'scout' started. Modern versions of
    libcurl have versioned symbols attached to a verdef CURL_OPENSSL_4,
    but Debian introduced versioned symbols before upstream did, and used
    CURL_OPENSSL_3. We want to be compatible with both.
    
    Similarly, modern upstream versions of libcurl when built against GNUTLS
    have versioned symbols attached to a verdef CURL_GNUTLS_4, but Debian
    introduced versioned symbols attached to a verdef CURL_GNUTLS_3, and
    is still using that verdef as of 2022. We want to be compatible with
    both, if we can.
    
    The trick here is that since glibc 2.30, the dynamic linker does not
    require triples (SONAME, version, symbol), but only looks for pairs of
    (SONAME, version) and, independently, (version, symbol). This means that
    dependencies on versioned symbols can be satisfied by any of the
    recursive dependencies of the library found when searching for the
    SONAME, and not just the library itself. glibc seems to have introduced
    this functionality so that glibc itself would be able to move symbols
    from its smaller libraries into libc.so.6 without breaking compatibility.
    
    The shim library has verdefs for both sets of versioned symbols, so it
    can be positioned in the search path as libcurl.so.4 and will satisfy
    both sets of requirements for the verdefs. For the actual symbols, it
    delegates to libsteam-runtime-system-libcurl.so.4 and
    libsteam-runtime-our-libcurl.so.4, which are expected to be set up by
    the runtime's setup.sh as symlinks to the real libraries that implement
    the two faces of libcurl.
    
    This requires some setup, which will be coordinated by a new version of
    setup.sh, in each of the pinned_libs_* directories. The real work is done
    by libcurl-compat/compat-setup.c, which uses the steam-runtime-tools
    library to find out whether the system libcurl is compatible with the
    expected ABIs.
    
    If there is no system copy of libcurl, then we do not need to do all
    this and can use the runtime's libcurl directly: binaries that rely on
    having a newer libcurl will fail, but by definition those binaries
    can't have been built or tested against the scout runtime.
    
    Helps: steamrt/tasks#119
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>
    74499151
    History
    Build a shim libcurl that can dispatch to runtime or system copies
    Simon McVittie authored
    
    This works around ABI divergence from upstream in the libcurl in
    Debian/Ubuntu between about 2005 and 2018, which unfortunately includes
    the time at which Steam Runtime 1 'scout' started. Modern versions of
    libcurl have versioned symbols attached to a verdef CURL_OPENSSL_4,
    but Debian introduced versioned symbols before upstream did, and used
    CURL_OPENSSL_3. We want to be compatible with both.
    
    Similarly, modern upstream versions of libcurl when built against GNUTLS
    have versioned symbols attached to a verdef CURL_GNUTLS_4, but Debian
    introduced versioned symbols attached to a verdef CURL_GNUTLS_3, and
    is still using that verdef as of 2022. We want to be compatible with
    both, if we can.
    
    The trick here is that since glibc 2.30, the dynamic linker does not
    require triples (SONAME, version, symbol), but only looks for pairs of
    (SONAME, version) and, independently, (version, symbol). This means that
    dependencies on versioned symbols can be satisfied by any of the
    recursive dependencies of the library found when searching for the
    SONAME, and not just the library itself. glibc seems to have introduced
    this functionality so that glibc itself would be able to move symbols
    from its smaller libraries into libc.so.6 without breaking compatibility.
    
    The shim library has verdefs for both sets of versioned symbols, so it
    can be positioned in the search path as libcurl.so.4 and will satisfy
    both sets of requirements for the verdefs. For the actual symbols, it
    delegates to libsteam-runtime-system-libcurl.so.4 and
    libsteam-runtime-our-libcurl.so.4, which are expected to be set up by
    the runtime's setup.sh as symlinks to the real libraries that implement
    the two faces of libcurl.
    
    This requires some setup, which will be coordinated by a new version of
    setup.sh, in each of the pinned_libs_* directories. The real work is done
    by libcurl-compat/compat-setup.c, which uses the steam-runtime-tools
    library to find out whether the system libcurl is compatible with the
    expected ABIs.
    
    If there is no system copy of libcurl, then we do not need to do all
    this and can use the runtime's libcurl directly: binaries that rely on
    having a newer libcurl will fail, but by definition those binaries
    can't have been built or tested against the scout runtime.
    
    Helps: steamrt/tasks#119
    Signed-off-by: default avatarSimon McVittie <smcv@collabora.com>