Hi Peter! Am 07.03.19 01:56 schrieb(en) Peter Bloomfield:
Not sure how to handle that: 'ldd src/balsa' shows that the Balsa executable is still *linked* to libssl: libsasl2.so.3 => /lib64/libsasl2.so.3 (0x00007f9d43fbb000) libssl.so.1.1 => /lib64/libssl.so.1.1 (0x00007f9d43f25000)
That's interesting – my build on Ubuntu 18.04 LTS and on Debian Stretch says
albrecht@deneb:~/Balsa/git/balsa-master$ ldd src/balsa | grep -e '\(ssl\|sasl\)'
libsasl2.so.2 => /usr/lib/x86_64-linux-gnu/libsasl2.so.2 (different address on Ubuntu/Debian)
*No* libssl dependency any more! My configure options on both systems are
./configure --with-compface --with-gpgme --enable-autocrypt --with-gss --with-spell-checker=gspell
--with-ldap --with-sqlite --with-gtksourceview --with-rubrica --with-canberra --with-libsecret --with-gnome
--with-gcr --with-osmo --with-html-widget=webkit2
If you have lddtree installed (on Debian coming with the pax-utils package) you could search for libssl in the
hierarchy. Or run “for n in $(ldd src/balsa | awk '{print $3'}) ; do echo "--- $n ---"; ldd $n; done” and
search the output…
On Debian, the dependency against libsasl2.so.2 is triggered by libldap_r-2.4.so.2, btw.
Cheers,
Albrecht.Attachment:
pgpFAWBO3c_QX.pgp
Description: PGP signature