Further investigation shows this issue affects both qt and kdelibs now, so would
request this be addressed in F-8 as well.

+++ This bug was initially created as a clone of Bug #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 rawhide is named
libssl.so.0.9.8g

In order to workaround this, we're currently having to patch kdelibs to hardcode
looking for libssl.so.0.9.8g/libssl.so.7

Is the value of SHLIB_VERSION_NUMBER incorrect?
Is this usage/expection of SHLIB_VERSION_NUMBER to name sonames invalid?
Any suggestions on how to make this work better?

-- Additional comment from tmraz on 2008-01-23 09:07 EST --
The file name in rawhide has to be ....0.9.8g otherwise it would conflict with
potential compat libraries with different SONAME.

We should probably patch the SHLIB_VERSION_NUMBER to reflect that but it could
theoretically break other things as I don't know how 3rd party apps use this macro.

But don't ask me what I think about dlopening openssl libraries to overcome the
GPL incompatibility.

So this will not be a priority for me to solve. kdelibs should instead use GPL
or GPL compatible licensed code for SSL. Such as nss_compat_ossl library.


-- Additional comment from rdieter.edu on 2008-01-23 09:11 EST --
Interested in exposing SHLIB_SONAMEVER (in opensslv.h or somewhere) as 
referenced in openssl-0.9.8g-soversion.patch ?

That could serve nicely.

-- Additional comment from tmraz on 2008-01-23 10:13 EST --
I could add that but will it really help you? It will not be in openssl upstream
so KDE cannot depend on it.


-- Additional comment from rdieter.edu on 2008-01-23 10:24 EST --
fair nuf, I'll try pinging both openssl, kde upstreams and see how best to
address this.

-- Additional comment from rdieter.edu on 2008-01-23 11:21 EST --
fyi, http://marc.info/?l=openssl-users&m=120110500517612&w=2

-- Additional comment from tmraz on 2008-01-23 17:51 EST --
The soname is actually libssl.so.7 - we patch it to be so otherwise it would be
libssl.so.0
- we do this because the abi is not stable so we almost always have to bump
sonames on version upgrades

The file name is libssl.so.0.9.8g - again we patch it this way otherwise it
would be libssl.so.0.9.8
- again we do this so multiple openssl versions (with potentially different ABI)
could be installed together.

This makes us (not upstream) to be not in sync with SHLIB_SONAMEVER. So this
question doesn't make much sense to be reported upstream. As I wrote we
could/should probably patch the SHLIB_SONAMEVER to be 0.9.8g but there is a
small possibility it might break things.


-- Additional comment from rdieter.edu on 2008-01-23 22:04 EST --
Thanks for the clarification. 

I don't care so much about SHLIB_SONAMEVER, it's the value of
SHLIB_VERSION_NUMBER that I'm more interested in, since that is what (upstream)
kdelibs uses to determine the name of the shlib(s) to dlopen.



-- Additional comment from rdieter.edu on 2008-01-23 22:08 EST --
My take/wish: fix SHLIB_VERSION_NUMBER to match reality.  3rd-parties that use
this are broken in the status-quo (e.g. kdelibs).

-- Additional comment from tmraz on 2008-01-24 03:02 EST --
(In reply to comment #7) 
> I don't care so much about SHLIB_SONAMEVER, it's the value of
> SHLIB_VERSION_NUMBER that I'm more interested in, since that is what (upstream)
> kdelibs uses to determine the name of the shlib(s) to dlopen.

Oops, I meant SHLIB_VERSION_NUMBER instead of SHLIB_SONAMEVER in the comment 6.



-- Additional comment from tmraz on 2008-01-26 15:40 EST --
Fixed, let's see what breaks - if anything.