Official 64-bit Linux builds load plugins from /usr/lib/mozilla/plugins and some distros want /usr/lib64 instead

RESOLVED DUPLICATE of bug 549308

Status

()

Core
Plug-ins
P3
minor
RESOLVED DUPLICATE of bug 549308
5 years ago
2 years ago

People

(Reporter: WG9s, Unassigned)

Tracking

(Depends on: 1 bug)

Trunk
x86_64
Linux
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Comment hidden (empty)
(Reporter)

Comment 1

5 years ago
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.
(Reporter)

Comment 2

5 years ago
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/
(Reporter)

Updated

5 years ago
Severity: normal → major
(Reporter)

Updated

5 years ago
Summary: Official 64-bit builds do not load plug-ins → Official 64-bit Linux builds do not load plug-ins
(Reporter)

Comment 3

5 years ago
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.

Comment 4

5 years ago
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
(Reporter)

Comment 5

5 years ago
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.
(Reporter)

Comment 6

5 years ago
I think the if /usr/lib64 exists as i suggested in my original comment would work at run time for this.
(Reporter)

Comment 7

5 years ago
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

Comment 9

5 years ago
I don't think that's necessary. Incompatible plugins don't load, but don't hurt anything else.

Comment 10

4 years ago
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?

Updated

2 years ago
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.