On Fri, Nov 08, 2019 at 01:04:14PM +0100, Steve Keller wrote: > I have a problem with libcurl.so.4 and a binary linked against it. In > Debian stretch I have the package libcurl3 installed and can run a > binary (I have no source code for it) linked against that libcurl. > > Although the package is libcurl3, it installs libcurl.so.4.4.0, with > symlinks libcurl.so.4 and libcurl.so.3 pointing to it, [...]
For whatever it's worth, this situation seems to be unique to libcurl, or perhaps to libraries that use OpenSSL or GnuTLS or LibreSSL. In buster, wooledg:~$ dpkg -L libcurl4 | grep -F .so /usr/lib/x86_64-linux-gnu/libcurl.so.4.5.0 /usr/lib/x86_64-linux-gnu/libcurl.so.4 wooledg:~$ dpkg -L libcurl3-gnutls | grep -F .so /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4.5.0 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.3 /usr/lib/x86_64-linux-gnu/libcurl-gnutls.so.4 It seems they're designed to coexist, so that programs that want to link against OpenSSL can use one, and programs that want to link against GnuTLS can use the other. Or at least, that's my guess.
