The issue here is that official 64-bit linux builds look for plugins at /usr/lib/mozilla/plugins, which is where the 32-bit plugins are located. They should, at least for my and most other distros be looking in /usr/lib64/mozilla/plugins.
So, for 64-bitbuilds the entire where to look for plug-ins should be a run time and not a compile time decision. The way this should work for a 64-bit build is that if /usr/lib64 exists, it should look in /usr/lib64/mozilla/plugins/ if not, it should look in /usr/lib/mozilla/plugins/
Summary: Official 64-bit builds do not load plug-ins → Official 64-bit Linux builds do not load plug-ins
So to make it clear in most linux 64-bit distro's /usr/lib/mozilla/plugins has the 32-bit plugins and the 64-bit plugins are at /usr/lib64/mozilla/plugins so the fact that official 64-bit Linux builds look for plug-ins at /usr/lib/mozillla/plugins makes them try to load 32-bit plug-ins, for the 64-bit browser, which obviously does not work.
The code in question is here: http://hg.mozilla.org/mozilla-central/annotate/18fc62fd8dcc/xpcom/io/nsAppFileLocationProvider.cpp#l207 I believe the current behavior is determined by the Mozilla build machines being pure-64 (or maybe a Linux variant that has /lib and /lib32). I don't know if there is a straightforward way to determine what strategy a particular distro is using; we could possibly just always load from both /usr/lib/mozilla/plugins and /usr/lib64/mozilla/plugins in 64-bit builds.
Severity: major → minor
Summary: Official 64-bit Linux builds do not load plug-ins → Official 64-bit Linux builds load plugins from /usr/lib/mozilla/plugins and some distros want /usr/lib64 instead
the problem is that this is a determination that needs to be made at run time that is currently inappropriately trying to be made at build time.
I think the if /usr/lib64 exists as i suggested in my original comment would work at run time for this.
Also, for if this should be major or monor depends on if the workign for subject should be " Official 64-bit Linux builds load plugins from /usr/lib/mozilla/plugins and MOST distros want /usr/lib64 instead" or " Official 64-bit Linux builds load plugins from /usr/lib/mozilla/plugins and some distros want /usr/lib64 instead"
(In reply to Benjamin Smedberg [:bsmedberg] from comment #4) > we could possibly just always load from both > /usr/lib/mozilla/plugins and /usr/lib64/mozilla/plugins in 64-bit builds. I think in that case we need do the rejection of incompatible architectures first.
Depends on: 558462
Priority: -- → P3
I don't think that's necessary. Incompatible plugins don't load, but don't hurt anything else.
We're deviating from the original request. To solve this bug, there is no need to determine path at runtime and there is no dependency on bug 558462: 32-bit version of firefox should look into /usr/lib/mozilla/plugins and 64-bit version should look into /usr/lib64/mozilla/plugins. That's it.
It's not as simple as looking in /usr/lib64/mozilla/plugins for 64-bit builds. $ ls -l /usr/lib64 ls: cannot access /usr/lib64: No such file or directory $ uname -a Linux zenigata 3.14-1-amd64 #1 SMP Debian 3.14.4-1 (2014-05-13) x86_64 GNU/Linux /usr/lib64 is a RedHatism. It exists on RedHat, Fedora, Centos, I guess SuSE, but it doesn't on Ubuntu and Debian.
(In reply to Mike Hommey [:glandium] from comment #11) > It's not as simple as looking in /usr/lib64/mozilla/plugins for 64-bit > builds. > > $ ls -l /usr/lib64 > ls: cannot access /usr/lib64: No such file or directory > $ uname -a > Linux zenigata 3.14-1-amd64 #1 SMP Debian 3.14.4-1 (2014-05-13) x86_64 > GNU/Linux > > /usr/lib64 is a RedHatism. It exists on RedHat, Fedora, Centos, I guess > SuSE, but it doesn't on Ubuntu and Debian. Yes, under openSUSE both lib and lib64 exist as subdirectories of (at least) / /usr and /usr/local. They range from empty to containing long lists of subdirectories, files and symlinks. lib64/32 is here a symlink to ../lib On my system (running openSUSE) all NPAPI plugins are in /usr/lib64/browser-plugins/ as shown on about:plugins with plugin.expose_full_path set to true. (The path displayed is the true full path/filename after resolving all symlinks). Couldn't 64-bit Mozilla apps look in both lib64 (if present) and lib, and accept what they can handle?
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 549308
You need to log in before you can comment on or make changes to this bug.