Here are the problems: 1) the new mozilla-1.7.10-r2 and mozilla-firefox-1.0.6-r3 are missing the link to /usr/lib/nsbrowser/plugins and are installing correspondingly only the libnullplugin.so in own plugins directory, which is not needed and the plugin probably must be installed to /usr/lib/nsbrowser/plugins, only if no plugins are to be found there or the directory does not exist. (the current behaviour breaks most notably galeon and epiphany see bug 100008) 2)the /etc/env.d-files for mozilla and mozilla-firefox are exporting ldpath and other variables, which soils the ldpath and the environment, that's why they should be completely removed. Moreover it is a thing which is prone to bugs, because it makes the libraries available twice and could lead to problems with incorect resolution of other libraries linking to them. - solution to this is setting the rpath and I will commit patches for mozilla, mozilla-firefox and mozilla-thunderd, which will apply the rpath/runpath dynamic tags to them - there are some other advantages to this, after using this patches and patching /usr/libexec/mozilla-launcher, and removing the ldpath-exports I have the following results: strace -F -f -eopen mozilla 2&> mozilla_with_ldpath.log and after patching /usr/libexec/mozilla-launcher and removing the ld-export strace -F -f -eopen mozilla 2&> mozilla_without_ldpath.log these are the results cat mozilla_with_ldpath.log |grep "(No such"|wc 419 5086 44299 cat mozilla_without_ldpath.log |grep "(No such"|wc 165 1962 18320 so there are 3 time less failed-open-file-attempts, which should hint a faster start time (because of not searching for standard libraries in mozilla-specific directories). 3) /usr/libexec/mozilla-launcher (ver. 1.44) is setting the environment-variables to the old paths: export MOZILLA_FIVE_HOME=${MOZILLA_LIBDIR:-"/usr/lib/MozillaFirefox"} export MOZILLA_FIVE_HOME=${MOZILLA_LIBDIR:-"/usr/lib/MozillaThunderbird"} there is no more executables in MozillaFirefox MozillaThunderbird, and the correct directories are mozilla-firefox and mozilla-thunderbird and after all, why are the old directories not completely removed? Some remarks for the patches, there will be broken libraries, but this could be probably easily repaired, on my computer these are: 1. epiphany-extensions-1.6.4, compiles fine but not set the rpaths, this probably should be send upstream, because epiphany is doing allright in this situation (compiles and sets the rpaths correct and runs) 2. devhelp-0.10 compiles fine, but does not set the rpath of /usr/lib/libdevhelp-1.so 3. eclipse-3.0.2, in /usr/lib/eclipse-3/plugins/org.eclipse.swt.gtk_3.0.2/os/linux/x86/libswt-mozilla-gtk-3064.so
Created attachment 64538 [details, diff] mozilla-thunderbird-rpath.patch this patch will set the correct rpath/runpath dtags for the executables and the libraries of mozilla-thunderbird-1.0.6, making it possible for them to run without the need of adding paths to the linker
Created attachment 64539 [details, diff] mozilla-rpath.patch This will set the correct rpaths to the mozilla's libs and the exes
Created attachment 64540 [details, diff] mozilla-firefox-rpath.patch this will set the rpaths/runpaths of mozilla-firefox's libs and exes, which will make it possible for them to run without ldpath-tinkering
Created attachment 64700 [details, diff] gecko-sdk-rpath.patch This is a patch, which will set rpath/runpath of the executables/libraries in gecko-sdk in order to resolve them correctly to themselves and not to /usr/lib/nspr/ set of libraries, which is the current situation. For example mplayerplug-in link to gecko-sdk at compile time and after that at run-time resolves to the libraries in /usr/lib/nspr/ (could be tested with ldd) probably leading to bugs and crashes, although even if it would have made the linking correct, the libraries in gecko-sdk would have resolved their dependacies to /usr/lib/nspr/ (again it could be tested with ldd). Which could lead to the question is nspr or gecko-sdk superfluous?
Created attachment 64813 [details, diff] mozilla-thunderbird-rpath.patch This will set the rpath/runpath to some libraries, which missed it (nspr, nss) and all now are using the $ORIGIN tag. Moving the libraries and binaries should be no problem. (mozilla-thunderbird)
Created attachment 64814 [details, diff] mozilla-firefox-rpath.patch Absolutely the same patch as mozilla-thunderbird, using the $ORIGIN-tag made it possible.
Created attachment 64858 [details, diff] mozilla-firefox-rpath.patch It seems, that the $ORIGIN will not work. The Makefiles are such a mess, in particular nss, nspr - seems they are not ported.
Created attachment 64859 [details, diff] mozilla-thunderbird-rpath.patch The same $ORIGIN not working for mangle (mangling the $ORIGIN), so fixed path.
Created attachment 64860 [details, diff] mozilla-rpath.patch With all the four-ebuilds (mozilla, mozilla-firefox, mozilla-thunderbird, gecko-sdk) will resolve only to its own libraries (including nss, nspr ones). It's interesting that only evolution-suite and the gnome clock-applet are linking to nss/nspr-libraries.
Thanks, these patches look great. Regarding the nsplugins stuff, I believe that's fixed in the latest ~arch and package.masked ebuilds, available this morning. To test them, you'll need to do: echo =www-client/mozilla-1.7.10-r3 >> /etc/portage/package.unmask echo =www-client/mozilla-firefox-1.0.6-r4 >> /etc/portage/package.unmask echo =mail-client/mozilla-thunderbird-1.0.6-r4 >> /etc/portage/package.unmask echo www-client/mozilla ~x86 >> /etc/portage/package.keywords echo www-client/mozilla-firefox ~x86 >> /etc/portage/package.keywords echo mail-client/mozilla-thunderbird ~x86 >> /etc/portage/package.keywords
Created attachment 65888 [details, diff] mozilla-rpath-1.patch This patch (based on the nsplugins trick), should make possible uniformly patching mozilla, mozilla-firefox and probably mozilla-thunderbird and setting the rpath in system independant way.
Created attachment 65889 [details, diff] mozilla-firefox-1.0.6-r5.ebuild.diff This is the diff to the current mozilla-firefox-1.0.6-r5.ebuild. It will compile all libraries with the corresponding rpath, will install (with ssl use-flag) nspr and nss libs, archives and includes (needed to build evolution and evolution-data-server), fixes a bug in the nspr pkg-config file and adds a -Wl,-R${libdir} flag to all of them. It does not install the binaries from nss-suite (in /usr/bin), which collide with mozillas and are not needed anyway.
Created attachment 65890 [details] mozilla-firefox-1.0.6-r6.ebuild And this is the full ebuild for mozilla-firefox-1.0.6
Created attachment 65891 [details, diff] mozilla-1.7.11.ebuild.diff Patch to mozilla-1.7.11.ebuild, building with rpath-tag set, fix of mozilla-nspr.pc pkg-config file, adding -Wl,-R${libdir} to the rest of them. Uses the same mozilla-rpath-1.patch and should use the correct lib-dir.
Created attachment 65892 [details] mozilla-1.7.11-r1.ebuild The full ebuild for mozilla-1.7.11
Created attachment 65910 [details, diff] mozilla-thunderbird-1.0.6-r4.ebuild.diff Diff to the current mozilla-thunderbird ebuild, using the uniform patch (mozilla-rpath-1.patch)
Created attachment 65911 [details] mozilla-thunderbird-1.0.6-r5.ebuild And the full ebuild for the mozilla-thunderbird.
Created attachment 65969 [details] mozilla-1.7.11-r1.ebuild There were some bugs - the patch name was not correct and the sed patching the mozilla-nspr.pc was not on fully qualified name - and because of this was failing.
Created attachment 65970 [details] mozilla-1.7.11-r1.ebuild There were some bugs - the patch name was not correct and the sed patching the mozilla-nspr.pc was not on fully qualified name - and because of this was failing.
Created attachment 65973 [details] mozilla-firefox-1.0.6-r6.ebuild The same not fully qualified name firefox-nspr.pc in the sed
If upstream decided is is the right thing to do I would add it but until then I do not see a reason. Anyone else on mozilla herd want to add anything on this should do so, Gergan please send this upstream.
I don't think the upstream will have any interest, the problems are in the distributions (bsd for example always use the rpaths). Now we here have possibilities to emerge different versions (or similar packages) and this only means, that the users will suffer from borked run-time linkage and gentoo should do the thing - it is better alternative to using ldpath for the packages, which depend on mozilla, firefox, gecko-sdk and pray for the best.
I am gonna go ahead and test firefox right now as far as them ending up in the tree simple answer is not yet ... reason I want more input from mozilla herd so I am not the only included in such a drastic decision.
I have posted a bug on mozilla https://bugzilla.mozilla.org/show_bug.cgi?id=304655 but I don't know what the result of this would be. It is the normal thing to do java makes it, they make it for opensolaris (i have seen resolved bug report for nss and nspr). It is the only reasonable resolution to the run-time linking problems if you have more than one library providing the same services.
I have added myself to the bug upstream and will monitor. Thanks
Gergan you will be happy to know we are adding the rpath right now to the tree. It is gonna be p.mask for testing but it is moving to tree. firefox and thunderbird are commited already and I will work on committing mozilla as soon as possible.
Thank you very much. It's a good thing, that we will be probably the first linux-distro, which will try to resolve the mozilla-linking-nightmare and bring more stability (hopefully). Thank you for your support and for your fast responses.
I have finally add mozilla-1.7.11-r2 to the tree, yes p.masked. far as gecko-sdk goes that should be its own bug as we are not responsible for the package. cat /usr/portage/net-libs/gecko-sdk/metadata.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE pkgmetadata SYSTEM "http://www.gentoo.org/dtd/metadata.dtd"> <pkgmetadata> <herd>mozilla</herd> <maintainer> <email>josejx@gentoo.org</email> <name>Joseph Jezak</name> </maintainer> </pkgmetadata> If you would open a new bug on it and assign to josejx@gentoo.org and then we can close this completely. Thanks for the patch and all you work on the ebuild.
I'll file a bug report for gecko-sdk. I've set a thread on gentoo-forums http://forums.gentoo.org/viewtopic-t-370844.html for testing the ebuilds and the possibilities they give. There is one small thing, which I've missed - patch the mozilla-config and firefox-config files. I don't know if any package uses them, but for completness sake, it should look sth like this: # Fix firefox-config and install it sed -i -e "s|/usr/lib/firefox-${PV}|${MOZILLA_FIVE_HOME}|g s|/usr/include/firefox-${PV}|${MOZILLA_FIVE_HOME}/include|g + s|\(echo -L.*\)\($\)|\1 -Wl,-R${MOZILLA_FIVE_HOME}\2" \ ${S}/build/unix/firefox-config I thank you one more time for all the time spent on my bug and I think you could close the bug. Or should I make it?
Gergan, shouldn't your last fix for firefox-config not read # Fix firefox-config and install it sed -i -e "s|/usr/lib/firefox-${PV}|${MOZILLA_FIVE_HOME}|g s|/usr/include/firefox-${PV}|${MOZILLA_FIVE_HOME}/include|g + s|\(echo -L.*\)\($\)|\1 -Wl,-R${MOZILLA_FIVE_HOME}\2|" \ ${S}/build/unix/firefox-config When I build firefox-1.0.6-r6 as its now in portage, firefox-config doesn't change at all (firefox-1.0.6 references are not exchanged). When I add the "|" at the end of the changed line it works Cheers
yes of course, I've forgot the pipe :) It should be as you suggested it, I didn't really try it, so it's simply a typo, sorry. (But as I said I didn't find untill now packages, which use it)
I submitted a new bug for the gecko-sdk rpath-patch to Joseph Jezak as you recommended (bug #104273).
Looks concluded to me, resolving.