Bug 429846 - openssl: SHLIB_VERSION_NUMBER != soname ?
openssl: SHLIB_VERSION_NUMBER != soname ?
Product: Fedora
Classification: Fedora
Component: openssl (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
Depends On:
Blocks: 440403 440404 440406
  Show dependency treegraph
Reported: 2008-01-23 08:16 EST by Rex Dieter
Modified: 2008-04-03 08:36 EDT (History)
0 users

See Also:
Fixed In Version: openssl-0.9.8g-4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-01-26 15:40:54 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
KDE Software Compilation 156488 None None None Never

  None (edit)
Description Rex Dieter 2008-01-23 08:16:05 EST
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
and the soname in rawhide is named

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?
Comment 1 Tomas Mraz 2008-01-23 09:07:18 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.
Comment 2 Rex Dieter 2008-01-23 09:11:42 EST
Interested in exposing SHLIB_SONAMEVER (in opensslv.h or somewhere) as 
referenced in openssl-0.9.8g-soversion.patch ?

That could serve nicely.
Comment 3 Tomas Mraz 2008-01-23 10:13:36 EST
I could add that but will it really help you? It will not be in openssl upstream
so KDE cannot depend on it.
Comment 4 Rex Dieter 2008-01-23 10:24:29 EST
fair nuf, I'll try pinging both openssl, kde upstreams and see how best to
address this.
Comment 5 Rex Dieter 2008-01-23 11:21:34 EST
fyi, http://marc.info/?l=openssl-users&m=120110500517612&w=2
Comment 6 Tomas Mraz 2008-01-23 17:51:41 EST
The soname is actually libssl.so.7 - we patch it to be so otherwise it would be
- 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.
Comment 7 Rex Dieter 2008-01-23 22:04:48 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.

Comment 8 Rex Dieter 2008-01-23 22:08:03 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).
Comment 9 Tomas Mraz 2008-01-24 03:02:46 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.

Comment 10 Tomas Mraz 2008-01-26 15:40:54 EST
Fixed, let's see what breaks - if anything.

Note You need to log in before you can comment on or make changes to this bug.