On Sat, Mar 12, 2016 at 8:06 PM, Kurt Roeckx <k...@roeckx.be> wrote: > On Sat, Mar 12, 2016 at 04:56:22PM +0000, Chris Knadle wrote: >> > Maybe Qt should have some way to indicate what version it's build >> > against so that we can binNMU it with all the other packages? Or >> > maybe Qt should just link against it, instead of doing dlopen()? >> >> Mumble upstream looked into the -openssl-linked ./configure option for >> building Qt (neither Qt4 nor Qt5 source packages in Debian use this today) >> but if I understand the situation correctly that won't help; Qt would depend >> on one version, Mumble would still depend on the other, and both versions >> would still be loaded and the situation would be the same. > > If nothing uses dlopen(), the symbol versioning should work as far > as I know, and you things should work. You would also be binNMUd > around the same time.
What I meant by "won't help" is that the final Mumble + Qt combination would still be using different versions of libssl/libcrypto in that configuration. I had hoped that something (either Debian packaging tools or ld-linux.so) would have prevented such a situation. :-) My fear with having multiple copies of libssl/libcrypto in the same address space is that something rubs OpenSSL the wrong way and breaks in a subtle way. >From a technical point-of-view, nothing should break. The only plausible way that something would break that I can think of, is if something in OpenSSL "pollutes" a process-global namespace in some way, such that some behavior in the "other" OpenSSL copy is affected. I don't know if that's the case (I assume not), but that's my worry about having two copies in memory: I don't believe it is something OpenSSL upstream tests, so who knows if it actually *works*?
