Missing dependency libsoftokn3.so libmozsqlite3.so Ubuntu 12 FF12, 13

[helpcrypto]

Doing:
    ldd /usr/lib/firefox/libsoftokn3.so

Shows a missing library/dependency:
    libmozsqlite3.so => not found

This library should be -for example- linked or copied to:
    /usr/lib/i386-linux-gnu/

This missing dependency cause crash/error when trying to load softokn library unless LD_LIBRARY_PATH/symlink created.

Other libraries seem to be properly referenced.

Ubuntu 12.04
Firefox 12 and 13 (13.0.1+build1-0ubuntu0.12.04.1)

[Chris Coulson (chrisccoulson)]

Errrr, I've got no idea what you're actually trying to do, but I can assure you that everything is fine here. The needed libraries are preloaded based on the list in dependentlibs.list.

Perhaps it would help if you explained the problem you're facing rather than jumping to the wrong conclusion with an incorrect solution for a problem you haven't mentioned yet?

[helpcrypto (helpcrypto)]

Hi.

Im trying to connect to NSS using Java for cryptographic operations.
This is the exit i got:

$ ldd /usr/lib/firefox/libsoftokn3.so
 linux-gate.so.1 => (0xb775d000)
 libmozsqlite3.so => not found
 libnssutil3.so => /usr/lib/i386-linux-gnu/libnssutil3.so (0xb76ea000)
 libplc4.so => /usr/lib/i386-linux-gnu/libplc4.so (0xb76e3000)
 libplds4.so => /usr/lib/i386-linux-gnu/libplds4.so (0xb76de000)
 libnspr4.so => /usr/lib/i386-linux-gnu/libnspr4.so (0xb76a0000)
 libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb7685000)
 libdl.so.2 => /lib/i386-linux-gnu/libdl.so.2 (0xb7680000)
 libc.so.6 => /lib/i386-linux-gnu/libc.so.6 (0xb74da000)
 /lib/ld-linux.so.2 (0xb775e000)

Shouldnt libmozsqlite3.so be properly linked?

[Chris Coulson (chrisccoulson)]

No, it doesn't need to be. libmozsqlite3.so is already loaded by Firefox by the time that libsoftokn3.so is. That is what dependentlibs.list does.

I'm closing this, again, because it doesn't appear to be a bug with Firefox. If you find issues where Firefox doesn't load the right libraries, then feel free to reopen it. But, if you're trying to make other software work with the *private* copy of NSS bundled with Firefox, then that is completely unsupported, and you're on your own with that (and in any case, opening a bug is an inappropriate way to ask for support)

[helpcrypto (helpcrypto)]

Its not a bug with Firefox, but a problem in the way firefox is bundled in Ubuntu. This didnt happen a few releases ago.

HINT: A library shouldnt have broken dependencies/references, no matter if it is private or not.

Apart from that, as discussed in mozilla-dev-tech-crypto mailist, Java access to NSS IS a valid way of working, and theres a mozilla project called JSS to do so.
Until a better system is designed for crypto operations, this should work.

http://www.mozilla.org/projects/security/pki/jss/
http://en.wikipedia.org/wiki/Network_Security_Services#Java_support
http://docs.oracle.com/javase/6/docs/technotes/guides/security/p11guide.html

As the library has broken dependencies it fails to load, and that causes an undesired behaviour.
The only required step is to PROPERLY reference the library or link it.

Do you REALLY think having a "broken" dependency is OK?
It's common sense!

Of course i can set LD_LIBRARY_PATH or do a symlink, but thats a workaround, not a solution.

[Chris Coulson (chrisccoulson)]

Sorry, but it has always been this way, and Firefox used to set LD_LIBRARY_PATH as well. It no longer does that as it has a different way to load libraries now.

I'm not sure what you mean by "not a bug with Firefox, but a problem in the way firefox is bundled in Ubuntu", because this configuration is absolutely identical to the configuration in a build of Firefox from mozilla.org. In fact, upstream builds have to be configured like this because the only other alternative is hard-coding path information in binaries (using an RPATH entry) - and this would restrict where their binaries could be installed on your system, to a path dictated by Mozilla.

And the dependencies are not broken - in fact, the libraries all contain the correct DT_NEEDED entries, as you've already demonstrated. Your problem is that the libraries are not installed in to one of the default ld search paths (and this is deliberate, because the libraries are private as I've already explained! If we intended for you to use them, we would have installed them in to one of the default search paths).

And we inherit the same configuration from upstream, which does not hardcode the install path using an RPATH entry alongside the library dependencies. We're not going to make an Ubuntu specific change to the build system to do this, just so you can use the libraries in a way which is considered by us to be completely unsupported.

[helpcrypto (helpcrypto)]

Thanks for your time.