On Wednesday 23 January 2008 7:52 am, Rex Dieter wrote: > 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.so.SHLIB_VERSION_NUMBER) as defined by openssl/opensslv.h > header. Unfortunately, this doesn't work, since > SHLIB_VERSION_NUMBER=0.9.8 > and the soname in on my box is: > libssl.so.0.9.8g > > Is the value of SHLIB_VERSION_NUMBER incorrect on my build? > Is this usage/expection of SHLIB_VERSION_NUMBER to name sonames invalid? > Any suggestions on how to make this work better?
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. We used to dlopen openssl in the Psi IM project, and Debian complained to no end. I'm pretty sure KDE3 Konqueror + openssl is an illegal combination, despite people using it daily. Admittedly, Psi + openssl has been an illegal combination for years as well, although with Qt 4 this has finally changed (Trolltech added an exception for openssl in their 4.3 license). So maybe with KDE4, Konqueror is (or can be) legal. I believe the real reason kdelibs dlopens openssl is to perform some binary compatibility check, which a standard dynamic link wouldn't ensure. If that's the case, then I'd say you could just drop this check. Maybe openssl had ABI issues in 1999, but I don't think it does anymore. However, it has been almost a decade since this kdelibs code was written, so I might not be remembering it right. :) -Justin ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
