I dug a bit deeper into the what happens during the building and loading of the
libssl.so* and libcrypto.so*.
When the qt4-x11 source package is buildd libssl-dev is installed as a
dependency.
It is not a direct dependency of qt4-x11, but due to another dev that is
installed.
At the time the packages of qt4-x11 were build for wheezy. libssl-dev was still
depending to libssl0.9.8 and not libssl1.0.0, as it is at the moment. So for
libqt4-network
the fall-backs are not used, when lib[ssl|crypto].so.0.9.8 are present on the
system.
On my system the sequence of picking the libraries are with
libssl-dev(1.0.0d-2)
installed:
first attempt: (using SHLIB_VERSION_NUMBER)
- library for ssl : libssl.so.1.0.0
- library for crypto : libcrypto.so.1.0.0
second attempt: (using development files)
- library for ssl : libssl.so
- library for crypto : libcrypto.so
third attempt: (scanning the most common library paths)
- library for ssl : /usr/lib/libssl.so.1.0.0
- library for crypto : /usr/lib/libcrypto.so.1.0.0
- library for ssl : /usr/lib/libssl.so.0.9.8
- library for crypto : /usr/lib/libcrypto.so.0.9.8
- library for ssl : /usr/lib/libssl.so
- library for crypto : /usr/lib/libcrypto.so
Just ripped the loading code from qsslsocket_openssl_symbols.cpp. And added
some
qWarnings.
So the upcoming 4.7.2-4 will solve this problem as it cause libqt4-network to
load
libssl.so.1.0.0 and libcrypto.so.1.0.0 on the first attempt. But there is a
possibility
the upgrade will also break other programs.
Mark-Willem
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
