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

Status: RESOLVED DUPLICATE of bug 549308

(Core Graveyard :: Plug-ins, defect, P3)

Comment 1

[Bill Gianopoulos [:WG9s]]

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.

Comment 2

[Bill Gianopoulos [:WG9s]]

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/

Comment 3

[Bill Gianopoulos [:WG9s]]

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

[Benjamin Smedberg]

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.

Comment 5

[Bill Gianopoulos [:WG9s]]

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.

Comment 6

[Bill Gianopoulos [:WG9s]]

I think the if /usr/lib64 exists as i suggested in my original comment would work at run time for this.

Comment 7

[Bill Gianopoulos [:WG9s]]

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"

Comment 8

[Georg Fritzsche [:gfritzsche]]

(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.

Comment 9

[Benjamin Smedberg]

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

Comment 10

[V P]

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.

Comment 11

[Mike Hommey [:glandium]]

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.

Comment 12

[Tony Mechelynck [:tonymec]]

(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?