missing symlinks break binary compatibility with native upstream components

Two things would help to diagnose the problem:

1) Go to Tools->Error Console, and enter the following in the "Code"
textbox at the top (as one line) and press enter. It will add a line of output to the error console, eg "x86-gcc3"

    Components.classes["@mozilla.org/xre/app-info;1"]
      .getService(Components.interfaces.nsIXULRuntime).XPCOMABI

2) Create a new profile, install Weave, exit Firefox. Then delete *.dat and extensions.cache from your profile, and launch firefox via:

    strace -f firefox > ~/stracelog.txt 2>&1

   Let Firefox come up, then quit. You may need to Control-C in the terminal to end the strace. Attach the stracelog.txt here (note that if you didn't start with a clean profile, there could be sensitive data in the trace).

Actually, a 3rd thing might be useful too.

3) cd to your profile, then cd to extensions/{340c2bbc-ce74-4362-90b5-7c26312808ef}/platform/Linux_x86-gcc3/components/ and run:

    ldd WeaveCrypto.so

Attach output here.

*** Bug 442257 has been marked as a duplicate of this bug. ***

So, taking a cue from asac's question in bug 442257 comment 22, I did a clean install of Hardy into a VM (and updated it), but did *not* install anything else (such as the dev packages needed for building FF from source).

In that environment, I'm now able to reproduce the Weave failure. stracing the browser startup shows us the linker trying to find libnspr4.so in various places but failing. sigh.

There *is* a /usr/lib/libnspr4.so.0d, but I'm not sure if we should be linking against that. Have to look closer at what that is, and since Firefox on Ubuntu is a xulrunner all if we should be linking against all the other stuff at all (isn't libxul supposed to have it all?). Investigating...

Hmm. Yeah, we do seem to need to link against libnspr and friends. Otherwise building the component fails.

On the VM where I can reproduce the problem, "ldd WeaveCrypto.so" reports that it can't find libxpcom.so, libnspr4.so, libsmime3.so, libssl3.so, libnss3.so, libnssutil3.so, libplds4.so, and libplc4.so. On my build machine, these are all found in /usr/lib (presumably put there by the build-dep packages I have installed). [Well, libxpcom.so isn't found but it works anyway; I guess the xpcomglue_s that's linked in is taking care of this at runtime?]

I also found: https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/228032

...which makes me suspect this is a Debian/Ubuntu bug. And I found bsmedberg's old "Debian Versioning of Mozilla Libraries Harmful" blog post, which also makes me wonder just what's supposed to be happening here. :/

Suggestions? Does Weave need to link differently, or is this a Ubuntu bug?

Created attachment 327523
ldd WeaveCrypto.so - Firefox 3 (x86-gcc3) Ubuntu 8.04.1 (Hardy)

The ldd output is misleading. What you want to run is

LD_LIBRARY_PATH=/path/to/firefox/installation ldd WeaveCrypto.so

Ubuntu doesn't play the nasty debian versioning games, as far as I know, so you should have a /usr/lib/firefox-3.0/libxpcom.so and so forth.

Not so sure about NSPR, but it should be able to find libnspr4.so from the Firefox installdir or from /usr/lib

My strace.log is 5718 kilobytes (KB) in size, too big for a non-patch file
attachment.

Should I send it as a patch?

No, please bzip2 it and then attach it.

Created attachment 327524
stracelog.txt - Firefox 3 (x86-gcc3) Ubuntu 8.04.1 (Hardy)

Created attachment 327526
ldd with LD_LIBRARY_PATH

(In reply to comment #7)
> The ldd output is misleading. What you want to run is
>
> LD_LIBRARY_PATH=/path/to/firefox/installation ldd WeaveCrypto.so

Same result, not found.

The relevant portion is

[pid 7190] open("/lib/tls/i686/cmov/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/lib/tls/i686/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/lib/tls/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/lib/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/tls/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/i686/cmov/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/i686/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/lib/i486-linux-gnu/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7190] open("/usr/lib/i486-linux-gnu/libnspr4.so", O_RDONLY) = -1 ENOENT (No such file or directory)

This means that ubuntu is not shipping with the standard NSPR libraries, either as system-NSPR or as local-to-Firefox NSPR. This is a bug in Ubuntu. Mconnor/blizzard, can one of you make contact with them? Not having a unified way to ship plugin libraries is a pretty big deal in terms of the Firefox branding.

That might already be covered by the bug I noted in comment 5 (https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/228032). Blah.

Despite the "nasty debian versioning games" (which only exist for nspr and nss nowadays), I bet this doesn't fail on debian. Because I've always be careful that libnspr4.so and friends are symlinks to the versioned libraries. And while the burden was on iceweasel before, the symlinks are now provided by nspr and nss themselves. So to fix this, Ubuntu just needs to "take back" from debian.
As for Ubuntu users, they can certainly install libnspr and libnss from debian, and be happy.

Ben, maybe you should take a look at recent debian packages before speaking.

Please install libnspr4-dev and libnss3-dev in ubuntu. If it helps let me know and we will get the fix really soon.

btw, why dont we use bug #442257 which was used to get things started?

Created https://launchpad.net/bugs/244439 to track this issue.

I installed libnspr4-dev and libnss3-dev in ubuntu 8.04 and it seems to have worked. I tried weave with a stock firefox3.0 from getfirefox.com before that.

Please verify that installing the following packages fix this for you (assuming 32-bit) - with and without -dev packages:

NSPR: http://launchpadlibrarian.net/15727099/libnspr4-0d_4.7.1%2B1.9-0ubuntu0.8.04.2%7Emt1_i386.deb

NSS: http://launchpadlibrarian.net/15726878/libnss3-1d_3.12.0.3-0ubuntu0.8.04.1%7Emt1_i386.deb

If you have the -dev packages installed either remove them before installing them or install the latest as well:

NSPR: http://launchpadlibrarian.net/15726882/libnss3-dev_3.12.0.3-0ubuntu0.8.04.1%7Emt1_i386.deb

NSS: http://launchpadlibrarian.net/15727100/libnspr4-dev_4.7.1%2B1.9-0ubuntu0.8.04.2%7Emt1_i386.deb

Thanks!

Removing the -dev packages wouldn't allow me to login. Installing those newer non -dev versions fixed the problem tho. wierd...

OK, will take this bug and keep you updated on the progress on ubuntu here too. Would appreciate if I get other confirms that the packages from comment 19 fix this.

proposed fix uploaded to ubuntu development release (intrepid):
 - nspr_4.7.1+1.9-0ubuntu2_source.changes
 - nss_3.12.0.3-0ubuntu2_source.changes

(In reply to comment #22)
> proposed fix uploaded to ubuntu development release (intrepid):

Any chance to see this in Hardy as well?

(In reply to comment #23)
> (In reply to comment #22)
> > proposed fix uploaded to ubuntu development release (intrepid):
>
> Any chance to see this in Hardy as well?
>

Stable Release Update (SRU) process initiated. See comment on launchpad bug:

  https://bugs.edge.launchpad.net/ubuntu/intrepid/+source/nss/+bug/244439/comments/6

If everything goes well this usually takes about a week.

You can help by following up in LP bug once we call for testing there. Ill drop a note here as soon as the test bits are available.

(In reply to comment #21)
> OK, will take this bug and keep you updated on the progress on ubuntu here too.
> Would appreciate if I get other confirms that the packages from comment 19 fix
> this.
>
After upgrading from Weave 0.1.30 to 0.2.0 (Ubuntu 8.04, 32-bit system) the passphrase was not accepted. I used the fix from comment 19: uninstalling the libnspr4-dev and libnss3-dev packages, then installing the ones from the link; rebooting. It didn't help (tried several reboots).

Then I deleted the "weave" folder from my Firefox profile. After that it worked.

So I can't tell if it would have worked without the comment 19 fix (maybe deleting the folder would have been good enough from the beginning).

tried the suggested fix, but could not get it to work on my amd64 system hardy 8.04 (the packages are i386)

anyone knows another fix for amd64

Thanks

(In reply to comment #26)
> tried the suggested fix, but could not get it to work on my amd64 system hardy
> 8.04 (the packages are i386)
>
> anyone knows another fix for amd64
>

Not sure if weave is available for amd64. If so, try to get the latest _hardy_ packages for nss and nspr from the mozillateam PPA: https://edge.launchpad.net/~mozillateam/+archive

Update: the packages have entered hardy-proposed. To test them go to Administration -> Software Sources and enable the Pre-released updates option; then upgrade your system.

*** Bug 442951 has been marked as a duplicate of this bug. ***

*** Bug 443405 has been marked as a duplicate of this bug. ***

The updates have fixed the problem, but required an uninstall/reinstall of the Weave plugin. Not sure if that's a bug in Weave or FF... if it's even a bug at all! Thought it worth mentioning.

After having installed the latest releases of nspr_4.7.1+1.9 and nss_3.12.0.3 through the repository, it still didn't work for me.
Neither a restart, nor deleting the weave user directory worked for me.

Finally a reinstall of the weave-plugin did the trick!

Thank you guys!

Precompiled weave-0.2.0 with 64 bit support -> https://bugzilla.mozilla.org/attachment.cgi?id=327774 ;-) From bug 442679
:-)

Based on comment #32, I am closing this bug.