[gutsy] /usr/lib/libssl.so missing

Hi there
The .so link is provided by the libssl-dev package, in the case of mumble which isn't provided natively in ubuntu yet, you probably need the libssl-dev package in order to compile the applications, but in cases which the packages are provided by the distribution, the applications look for the correct version of the library, so there's no need to have libssl0.9.8 providing this link.

Hope this answer satisfy you. if you find an official packaged applications who can't be installed because of the lack of presence of this link, please report it, but by the meantime i'll mark this bug as invalid, since the package isn't really provided in Ubuntu. Thanks for report this issue and help to make Ubuntu better, please feel free to report any future bugs you might found

Any application which uses QSslSocket will fail, as it is *QT* who tries to open libssl.so and not Mumble. And that Qt4 is provided with Ubuntu.

You need to have either the libssl or libqt package provide the link, or you need to modify the source for Qt so it looks for a different library.

I've changed the package to qt4-x11; can you please provide additional information to substantiate this bug report?
Error messages, excerpt from the Qt source code, etc. would do

:~$ mumble
Locale is de_DE
QSslSocket: cannot find ssl library: QLibrary::load_sys: ssl kann nicht geladen werden (libssl.so: cannot open shared object file: No such file or directory).
OpenSSL Support: 0
No ciphers of at least 128 bit found
Aborted (core dumped)

mumble is not in our repo, so, could you give us a snippet of the code where this call is made?
If macros are used, please let us also know where they are initialised.

You can download ist under:

http://mumble.sourceforge.net/

Sorry, I don't think you have understood my question. I'm not asking to see your whole source code, I'm asking to see a snippet (which is, a small portion) of the code where the offending call is made.

he, I am a user not the enginer of mumble :)

The offendig call is in Qt. More specifically, in src/network/qsslsocket_openssl_symbols.cpp
For pristine Qt 4.3.2, it's on line 252 which states:

   QLibrary libssl(QLatin1String("ssl"));

At runtime, this results in a dlopen("libssl.so") which fails, as there is no libssl.so

As such, Qt concludes the system doesn't have OpenSSL installed and disables all SSL functionality.

The fix really should be in the openssl package, and the fix is to just create the symlink there. It would be wrong for the qt package to create a symlink for openssl. Alternatively you could modify the above line to load a specific version of the library, but that would mean you'd have to repatch and redistribute Qt every time openssl is updated.

BTW, the same needs to be done for libcrypto.so

This seems to be more of a compilation problem on your side. If libssl-dev is installed in your build environment, and the correct compiler/linker flags are used, than that call should be resolved as a dlopen to libssl.so.0.9.8
Can you check (also attach it here if you want) your build log?

Dynamic linking is resolved as you specify, but runtime dlopen() is not. dlopen() will try to open exactly what you give it. If that fails, it will try the same filename in /lib, /usr/lib etc, but it will not mangle the filename. This is the way dlopen() has always been. If it had been a link or compile time problem, the final binary wouldn't even start. It does start, and this is a runtime problem.

Mumble itself links to libssl.so.0.9.8 when built on Ubuntu, but this is not a Mumble problem, it's a Qt problem. This will fail for all applications which use SSL functionality in libQtNetwork.

I've attached a small program which illustrates the problem. Unpack, qmake-qt4, make, then run it with the symlink in place. It works. Remove the symlink. The program complains about the missing symlink. Now, that program is 1 line long, doesn't use a single libssl call directly, and isn't even linked to libssl. Yet it uses Qt, and Qt can't find the SSL library, so Qt complains when you use Qt's SSL functions.

Then I can only advice you to report this directly to trolltech.
I'm leaving this confirmed and affecting qt4-x11; once you have filed a bug upstream you can link it here so that we can follow the progress.

Why is this a bug upstream, when only a link isn't created in the qt4-x11 package?

This is the reply from Trolltech:

Hi Thorvald,

On Saturday, 27. Oct 2007 18:44 <email address hidden> wrote:
[snip]
> > Short description:
> > QSslSocket fails because libssl.so isn't found
> >
> > What I did:
> > Compiled a program using QSslSocket
[snip]
> > What I got instead:
> > QSslSocket: cannot find ssl library: QLibrary::load_sys: Cannot load
> > ssl (....)
> >
> > More info:
> > Any program using the new QSslSocket will fail on Ubuntu 7.10 unless
> > it has libssl-dev installed. This is a development pacakge and as such
> > should not be necesarry for normal operation.
> >
> > The reason for this is that Qt uses dlopen() on "libssl.so" at
> > runtime. libssl.so is a symlink, and this symlink is provided by the
> > development package. There's been discussion about this on the Ubuntu
> > bugtracker (https://bugs.launchpad.net/bugs/155784) and their
> > conclusion is that it's a bug in Qt that it opens libssl.so instead of
> > libssl.so.0.9.8
> >
> > I just checked, and a similar situation exists on RHEL5; the
> > "libssl.so" symlink is provided by the dev package.

Thank you for your report. Indeed, the libssl.so symlink is only
provided by the development package. I believe this is in accordance
with the unix convention.

Thus, we should pass the major version number of the OpenSSL library
when trying to resolve it. QLibrary already supports loading libraries
based on major version:

 http://doc.trolltech.com/4.3/qlibrary.html#QLibrary-3

However, I also believe that by unix convention, the base libarary
package should provde the following symlinks:

libssl.so.0
libssl.so.0.9

I cannot see that the base library package provides these, so I believe
this is a bug in the base OpenSSL library package.

Qt should not have to specify the entire version as this will force us
to rely on a particular patch version of the OpenSSL library, which may
be rather limiting. Instead, only the major version should be needed,
as minor and patch releases should be binary compatible with the major
version.

So if we fix the resiolving of the OpenSSL library to include the major
version number, the vendor of the base OpenSSL library package needs to
provide the conventional symlinks.

I have passed the informtion on to our development team. I created task
185864 in the process, and you can use this ID to follow the status of
the task online at:

 http://www.trolltech.com/developer/task-tracker

In the meantime, the workarounds are to create the conventional
symlinks, including libssl.so, or create the conventional symlinks and
modify the source to use the major version number for the OpenSSL
library. This is done in qsslsocket_openssl_symbols.cpp (QLibrary
libssl(QLatin1String("ssl")) etc.).

Thank you for bringing this to our attention. Have a nice day!

Kind regards,

Stian Thomassen, Support Engineer
Trolltech ASA, Norway

Realistically speaking, I doubt the fix for this will make it before the 4.4 releases. At the absolutely earliest, it will make it into 4.3.3, which is still a few months away. We'll still need to fix the libssl package to provide the symlink for libssl.so.0.

This is a problem for me today, so is there any chance that we could, in the meantime, have either the qt or libssl package provide the symlink?

What is required by the linux convention, and I must also add by the debian standard, is that the library package shall contain the library file itself, usually called libfoo.so.X.X.X, and its symlink libfoo.so.X which matches the SONAME.
In the case of non-well behaved libraries, like ssl, the SONAME matches the library name:

cesare@norsetto:~$ objdump -p /usr/lib/libssl.so.0.9.8 | grep SONAME
  SONAME libssl.so.0.9.8

At our level, we can't add a symlink like libssl.so.0 simply because this will break ABI compatibility.

I can't really see how adding a symlink will break compability. If so, loads of programs should get broken when you install libssl-dev, which does install the symlink.

Anyway, am I to understand that nothing will be done to work around this in current and future Ubuntu releases, and that this will not work until Qt manages to guess the full filename of libssl.so.x.y.z, something they have stated above they will not do?

First of all, I'm talking about libssl.so.0, not libssl.so (the latter is only needed at build time and its certainly not meant to solve runtime problems).
As far as I can see, the only solution is for Trolltech to link to the soname (which in this case is libssl.so.0.9.8), which anyhow they have to do if they want to maintain ABI compatibility (I think they have not yet understood the peculiarity of this library).
Believe me, if there was something I could do to solve this problem from our end, I will be more than happy to do.

As I've said a few times, Qt is not linking to the library, it is opening it dynamically at runtime. You don't even need to have libssl.so, .a or anything else installed when you compile Qt, you only need the headers.

Please read their email above, especially the part which says: "Qt should not have to specify the entire version as this will force us to rely on a particular patch version of the OpenSSL library, which may be rather limiting."

Anyway, you disagree with their choice of how to open the library. That's fine, but will you at least patch the Ubuntu version of Qt so that it either links to libssl (instead of opening it) or have it open the full filename?

Uploaded to hardy

qt4-x11 (4.3.2-1ubuntu1) hardy; urgency=low

  * Merge with Debian, remaining changes:
   - qt4-dev-tools conflicts on qdbusviewer
   - Add kubuntu_01_load_ssl.diff, LP: #155784

qt4-x11 (4.3.2-1) unstable; urgency=low

  * New upstream release.

  [Fathi Boudra]
  * Update desktop files categories.
  * Add desktop files icons. (Closes: #433581)
  * Update patches to Qt4.3.2.
  * Add 90_qmake_cxxflags_fpermissive patch.
  * Remove 0186-fix-component-alpha-text patch. Merged upstream.
  * Add qt-copy patches:
    * 0188-fix-moc-parser-same-name-header
    * 0189-fix-q3toolbar-qcombobox-signal-slot
    * 0191-listview-alternate-row-colors
    * 0192-itemdelegate-palette-state
    * 0193-qtreeview-division-by-zero
    * 0194-fix-moveonly-dnd-in-itemviews
    * 0195-compositing-properties
  * Update qt4-dev-tools long description.
  * Update copyright:
    * Update Trolltech GPL exception to v1.1.
    * Add Trolltech GPL exception addenum.
  * Update rules:
    * Build with -fpermissive.
    * Introduce QTVERSION.
  * Fix qt4-config menu section. (Closes: 444896)

  [Sune Vuorela]
  * Have strict interdependencies between packages with a shlibs.local file.
    (Closes: #438746)
  * Don't trust uname in generating the qt build key. This has bitten us in
    qt3, but will soon bite us in qt4 as qt4 becomes more popular.

  [Ana Beatriz Guerrero Lopez]
  * Add desktop files icons uuencoded and update rules to install them uudecoded.
  * Add sharutils build dependency.

qt4-x11 (4.3.1-2) unstable; urgency=low

  * There is a large difference between 8 spaces and a tab.

qt4-x11 (4.3.1-1) unstable; urgency=low

  * New upstream release.

  [Fathi Boudra]
  * Switch to quilt patch system.
  * Update copyright. Add Trolltech GPL Exception.
  * Update section in Debian menu files.
  * Update patches for Qt4.3.1.
  * Remove 51_kfreebsd_mkspecs patch. Moved in rules.
  * Add 0187-fix-font-fixed-pitch patch:
    This patch works around broken QFontInfo::fixedPitch by always using a
    glyph metrics comparison test to guess the information. This has the
    property of both ignoring (bad) and not relying on (good) any information
    that might be provided by the OS's font facility. For Mac OS X only.
  * Remove patches merged upstream:
    * 0177-qurl-clear-fix
    * 0183-qprocess-corruption
    * 42_alpha_fetch_and_add
  * Disable:
    * 0172-prefer-xrandr-over-xinerama patch. (Closes: #433931)
    * 0181-qdnd-x11-fix patch.

  [Sune Vuorela]
  * Add a quick and dirty test to make build on hppa fail if a current
    getdents kernel bug is detected.

 -- Jonathan Riddell <email address hidden> Mon, 05 Nov 2007 17:20:28 +0000

Accepted into gutsy-proposed, please test.

Using the test case in the description I was able to reproduce the bug using libqt4-[core|gui] version 4.3.2-0ubuntu3. After upgrading to libqt4-[core|gui] versions 4.3.2-0ubuntu3.1 I was no longer able to reproduce the bug.

copied to gutsy-updates

I really need to switch to gutsy-proposed when I do bug reports :(

This has caused a new bug: qt4-dev-tools depends on libqt4-core(=4.3.2-0ubuntu3). Notice the = and not >=
As such, you can't install qt4-dev-tools on current gutsy, meaning you can't do Qt4 application development as designer, linguist etc are all missing.

I still seem to be experiencing the issue. I am using ubuntu gutsy x86_64. Here's what I did:

psychiccyberfreak@psych4:~$ mumble
Locale is en_US
QSslSocket: cannot find ssl library: QLibrary::load_sys: Cannot load ssl (libssl.so: cannot open shared object file: No such file or directory).
OpenSSL Support: 0
No ciphers of at least 128 bit found
Aborted (core dumped)
psychiccyberfreak@psych4:~$ getlibs /usr/bin/mumble
This application isn't missing any dependencies
psychiccyberfreak@psych4:~$

Note that I did use a i386 package. When I compiled it myself under x86_64 it seems to run fine.

Have you updated your i386 Qt packages to the new version?

qt4-dev-tools is also updated, you should have version 4.3.2-0ubuntu3.1 available.