Bug 440403 - openssl: SHLIB_VERSION_NUMBER != soname ? (F-7)
openssl: SHLIB_VERSION_NUMBER != soname ? (F-7)
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: openssl (Show other bugs)
7
All Linux
low Severity low
: ---
: ---
Assigned To: Tomas Mraz
Fedora Extras Quality Assurance
:
Depends On: 429846
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-03 08:33 EDT by Rex Dieter
Modified: 2008-05-09 12:16 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-05-09 12:16:11 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Rex Dieter 2008-04-03 08:33:25 EDT
Further investigation shows this issue affects both qt and kdelibs now, so would
request this be addressed in F-7 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@redhat.com 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@math.unl.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@redhat.com 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@math.unl.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@math.unl.edu on 2008-01-23 11:21 EST --
fyi, http://marc.info/?l=openssl-users&m=120110500517612&w=2

-- Additional comment from tmraz@redhat.com 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@math.unl.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@math.unl.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@redhat.com 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@redhat.com on 2008-01-26 15:40 EST --
Fixed, let's see what breaks - if anything.
Comment 1 Rex Dieter 2008-05-09 12:16:11 EDT
shrug, too close to EOL, not worth it, WONTFIX.

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