| Summary: | epiphany & galeon can't find plugins after upgrading to mozilla-1.7.10-r1 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Vaclav Slavik <vslavik> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | major | CC: | dwc, ed, farcepest, gnome, hanno, jlee |
| Priority: | Highest | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
This patch adds /usr/lib/nsplugins and /usr/lib/nsbrowser/plugins to the search path for plugins.
plugin path patch for Galeon 1.3.21 |
||
|
Description
Vaclav Slavik
2005-07-23 03:54:25 UTC
I can confirm epiphany shows similar behaviour and that this needs a proper fix asap. I also noticed mplayerplug-in doesn't compile with mozilla 1.7.10 . This is all not so good for a stable pack. Created attachment 64203 [details, diff]
This patch adds /usr/lib/nsplugins and /usr/lib/nsbrowser/plugins to the search path for plugins.
Attached is a patch to fix the problem with Epiphany. A similar patch will
have to be made for Galeon most likely.
No I think this should be fixed @ the source and that is mozilla finding it's own default plug-in dir without setting environment vars. Well if you look at mozilla-firefox-1.0.6-nsplugins.patch, that is exactly how Mozilla and Firefox in Portage are doing it, modifying the MOZ_PLUGIN_PATH, which, evidently, doesn't work with its embedding library. Created attachment 64356 [details, diff]
plugin path patch for Galeon 1.3.21
I've did this patch for my own machine.
After some upgrade in the last 48 hours neither galeon, nor epiphany are working for me, it seems that firefox removes some lines from /etc/env.d, which set the essential paths, for galeon and epiphany (for example MOZILLA_FIVE_HOME). I have commented also on bug# 99621 and I think the resolution to all these problems is a mozilla-config tool, which should behave in the similar way to java-config (interchanging the file in env.d to the correct one, which defines the needed environment-variables). And not hardcoding this in galeon or epiphany. The problem is not in mozilla also, because it is in the way we define the environment settings, why should we create possible collisions with exporting two ldpaths for mozilla and mozilla-firefox - they are defining the same libraries, and it is logical that in this case no one knows which one will be called. There are two soultions to this: the first is using some tool, as I said to intechange the things in /etc/env.d, the second is more elegant we should link the things, which use mozilla or mozilla-firefox with runpath and/or rpath field, which ensures the correct resolution and does not need change in the source file, but in the make-file. corrections, it is not a problem in galeon or epiphany, and my earlier comment should not be taken very seriously (the rpath/runpaths are set correctly):) . after some explorations: 1. my bug is corrected with rebuilding (because the rpaths were /usr/lib/MozillaFirefox) 2. the bug explained in this bug could be corrected with removing the /usr/lib/mozilla-firefox/plugins and linking it with ln -s /usr/lib/nsbrowser/plugins /usr/lib/mozilla-firefox/plugins to the plugins directory. It is a simple bug in mozilla-firefox, the ebuild should remove the /usr/lib/MozillaFirefox directory and probably link it to /usr/lib/mozilla-firefox, and remove /usr/lib/mozilla-firefox/plugins and make instead a link to /usr/lib/nsbrowser/plugins. I will test and try if all programs could function without the /etc/env.d, because the idea of exporting two ldpaths which contain essentially equivalent libraries is not a good idea. P.S. the same affect mozilla, simply changing the mozilla-firefox with mozilla where appropriate should solve the problem. I re-emerged galeon (1.3.21) and it doesn't fix the problem. The workaround is to use symbolic links: chef plugins # cd /usr/lib/mozilla/plugins chef plugins # ls libnullplugin.so chef plugins # ln -s /usr/lib/nsbrowser/plugins/* . chef plugins # ls -l total 20 lrwxrwxrwx 1 root root 42 Jul 30 22:27 flashplayer.xpt -> /usr/lib/nsbrowser/plugins/flashplayer.xpt lrwxrwxrwx 1 root root 40 Jul 30 22:27 javaplugin.so -> /usr/lib/nsbrowser/plugins/javaplugin.so lrwxrwxrwx 1 root root 44 Jul 30 22:27 libflashplayer.so -> /usr/lib/nsbrowser/plugins/libflashplayer.so lrwxrwxrwx 1 root root 41 Jul 30 22:27 libmozsvgdec.a -> /usr/lib/nsbrowser/plugins/libmozsvgdec.a lrwxrwxrwx 1 root root 42 Jul 30 22:27 libmozsvgdec.la -> /usr/lib/nsbrowser/plugins/libmozsvgdec.la lrwxrwxrwx 1 root root 42 Jul 30 22:27 libmozsvgdec.so -> /usr/lib/nsbrowser/plugins/libmozsvgdec.so -rwxr-xr-x 1 root root 19500 Jul 24 05:56 libnullplugin.so lrwxrwxrwx 1 root root 44 Jul 30 22:27 mplayerplug-in.so -> /usr/lib/nsbrowser/plugins/mplayerplug-in.so lrwxrwxrwx 1 root root 45 Jul 30 22:27 mplayerplug-in.xpt -> /usr/lib/nsbrowser/plugins/mplayerplug-in.xpt lrwxrwxrwx 1 root root 35 Jul 30 22:27 nppdf.so -> /usr/lib/nsbrowser/plugins/nppdf.so Maybe the plugin ebuilds should be changed to use /usr/lib/mozilla/plugins instead? Just a thought; I really don't know what the correct solution is. It is not that easy, there are currently some 4 directories, in which the plugins are installed ::)), and not only this, but if you install, say, opera and want to use the plugins ? It was better simply to delete /usr/lib/mozilla/plugins and link the directory and not each plugin, because you would have to repeat this procedure after the installation of a new plugin:) This issue should be fixed with these recent releases. Please try and re-open this bug if the problem persists: www-client/mozilla-1.7.10-r3 www-client/mozilla-firefox-1.0.6-r4 Sorry, I didn't mean to be vague. To give a little more information, I fixed the nsplugins patch last night. The nsplugins patch causes libxpcom.so (part of mozilla) to search for the plugins in /usr/lib/nsbrowser/plugins as well as /usr/lib/mozilla/plugins (or firefox, you get my drift). Multilib is also handled correctly. |
