Re: Generic binaries depending on libcurl3

On Sat, 23 Nov 2019 at 14:03, Thomas Leonard <[email protected]> wrote:
>
> On Sun, 17 Nov 2019 at 18:37, Bastian Eicher <[email protected]> wrote:
> >
> > The generic Linux binaries for 0install
> > (https://0install.net/injector.html#linux-generic) depend on libcurl3.
> > However, this library is no longer available in Debian starting with Buster
> > or Ubuntu starting with 18.10.
> >
> > Installing the suggested replacement library libcurl4 results in:
> > 0install: /usr/lib/x86_64-linux-gnu/libcurl.so.4: version `CURL_OPENSSL_3'
> > not found (required by 0install)
> >
> > Maybe we should look back into possibilities for statically linking
> > 0install's dependencies?
>
> This Dockerfile seems to work now (using the latest Alpine edge,
> building from a 0install Git clone):
[...]

I tried a few more things with this. The situation is:

- If we statically link everything on Alpine then we can't use GTK,
because the statically-linked libmusl doesn't support dynamic linking.
- If we dynamically link libmusl then we get a dependency on libmusl
and it doesn't work anywhere except Alpine.
- If we build on Debian then we only get a dependency on glibc, but it
has lots of symbols that aren't on Alpine, etc.

I also tried using cohttp/ocaml-tls as an alternative to libcurl
(https://github.com/0install/0install/pull/122). That avoids the above
problems, but it seems that ocaml-tls doesn't work with all web-sites.
For example, the set of ciphers supported by GitLab doesn't seem to
intersect with the set supported by ocaml-tls, so you just get a
handshake failure.

We could use cohttp with openssl, but I seem to recall that openssl is
no better at binary compatibility than libcurl.


-- 
talex5 (GitHub/Twitter)        http://roscidus.com/blog/
GPG: 5DD5 8D70 899C 454A 966D  6A51 7513 3C8F 94F6 E0CC