SHLIB_VERSION_NUMBER != soname ??

See also: https://bugzilla.redhat.com/show_bug.cgi?id=429846 Due to licensing issues, kdelibs dlopens openssl instead of linking. In order to make this work, kdelibs needs to know the soname of both libcrypto and libssl. Upstream kdelibs *tries* to use libssl.so.SHLIB_VERSION_NUMBER (and libcryp

Re: SHLIB_VERSION_NUMBER != soname ??

Justin Karneges wrote: I am not a lawyer, but I don't think dlopening openssl within a GPL application is any more legal than dynamically linking to it. Please, let's not digress. I apologize for even mentioning that part. I believe the real reason kdelibs dlopens openssl is to perform some

SHLIB_VERSION_NUMBER != soname ??

See also: https://bugzilla.redhat.com/show_bug.cgi?id=429846 Due to licensing issues, kdelibs dlopens openssl instead of linking.  In order to make this work, kdelibs needs to know the soname of both libcrypto and libssl.  Upstream kdelibs tries to use libssl.so.SHLIB_VERSION_NUMBER (and libcrypto