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. ** Attachment added: "ssl.tar.gz" http://launchpadlibrarian.net/10186529/ssl.tar.gz -- [gutsy] /usr/lib/libssl.so missing https://bugs.launchpad.net/bugs/155784 You received this bug notification because you are a member of Ubuntu Bugs, which is the bug contact for Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
