Bug#623596: [Pkg-openssl-devel] Processed: Re: Bug#623596: mumble: Problem with the import certificats

[Mark-Willem Jansen <markwillem@hotmail.com>]

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