We have nspr and nss as individual builds in portage. Mozilla, Firefox, Thunderbird, and everything else should use the global nspr and nss. For instance, Firefox installs its own nspr in /usr/lib/MozillaFirefox. To fix Firefox: 1. Nspr in the portage tree has to be upgraded to version 4.5.0 from CVS. 2. During the Firefox ebuild, we should put the nspr-config file in Firefox's ${FILESDIR}. That file needs to be edited slightly to follow Gentoo's nspr installation directories (/usr/lib/nspr and /usr/include/nspr). 3. The mozconfig.eclass file needs to be edited to have nspr as a dependency. It also needs to replace --without-system-nspr with --with-system-nspr --with-nspr-prefix=/usr. To make nss work, some of the Makefiles need to be edited. If the Mozilla applications could use the global nspr and nss libraries, that would reduce a lot of redundancy. It would also fix a lot of gaim-encryption problems (linking against the wrong libraries, working on people's machines who have Firefox or Mozilla installed, but not on others... etc.) Reproducible: Always Steps to Reproduce:
Ok, this bug is more serious that I had thought. The problem is that the Firefox build uses a special version of NSPR and NSS. Specifying --with-system-nspr will lead to a lot of errors, and I'm not sure how to fix most of them. I'm also not sure how to make it use a global NSS. First problem: Firefox uses its own NSPR and NSS, and all files that link to NSPR and NSS link to /usr/lib/MozillaFirefox/*.so. However, all of those ebuilds still depend on NSPR and NSS (gaim-encryption, evolution, etc.). This is because they need the stand-alone NSPR and NSS to provide header files. They still link to the Firefox-provided libraries, because that's what's specified first in /etc/ld.so.conf. However, the headers don't match the libraries. Second problem: If we were to switch the order of the paths in /etc/ld.so.conf, a lot of Firefox files would break (shlibsign, etc...), because the header files that they were compiled against had different symbols. Third Problem: Firefox, Mozilla Suite, Thunderbird, etc. all use the same set of NSPR and NSS libraries, provided from one of these builds, whichever is listed first in /etc/ld.so.conf. However, the versions of these libraries that they need could be potentially different. For instance, version 0.9 of Firefox, but the latest Thunderbird, etc. This is a problem that definately needs to be fixed soon. I think the Mozilla devs should be contacted about this. They need to have some consistency in their libraries. Another fix might be to take the NSPR and NSS files from the Mozilla Suite, and use them instead of the ones in Portage right now. I raised the severity of this issue, considering how many people use Firefox, Thunderbird, Mozilla, Evolution, Gaim... and more...
i've always thought that the problem here is that nss/nspr don't come packaged with versioned libraries (eg. libnss.so.5, etc), this would help the situation much better, esp for things like evolution/gaim which require nss/nspr and has the option for people not to install the whole mozilla/firefox suite just to get the nss/nspr libraries.
You could look at bug 100597, there are not only nss, nspr it is a huge mix of libraries, which could lead to so much bugs. The problem now is that no one knows how the libraries are resolved at run-time, because all are exported in the ldpath, I have made some patches for setting rpath/runpath dynamic tags (mozilla, mozilla-firefox ...) to guarantee at least that they will correctly resolve their libraries at run-time (and the ldpath exports should be removed as soon as possible from the ebuilds).
I have reviewed all the possibilities here and it is not sane. If at a later time it becomes plausable then we can reopen and bring it to the table for discussion.
