Closed Bug 558462 Opened 14 years ago Closed 3 years ago

Should do something sensible when plugin binaries and Firefox are not using the same architecture


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



(blocking2.0 -, blocking1.9.2 -)

Tracking Status
blocking2.0 --- -
blocking1.9.2 --- -


(Reporter: ehsan.akhgari, Unassigned)



(Whiteboard: [lorentz])

I tried installing a 64-bit en-US Firefox nightly on Ubuntu 9.10 x86-64, and it prompted me to install Flash when I visited youtube, and I clicked through the wizard and installed it.

Then I installed a 32-bit fa Firefox nightly, and noticed that flash doesn't load, and mozilla-runtime isn't running.  I got a lot of errors like this on the console:

LoadPlugin: failed to initialize shared library /var/lib/flashplugin-installer/ [/var/lib/flashplugin-installer/ wrong ELF class: ELFCLASS64]

Here's the info about my flash player binary:

ehsan@ehsan-ubuntu:~/fa$ dpkg -l | grep flash
ii  flashplugin-installer                          Adobe Flash Player plugin installer
ehsan@ehsan-ubuntu:~/fa$ file /var/lib/flashplugin-installer/ 
/var/lib/flashplugin-installer/ ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

We should do something sensible here.  From the user's standpoint, the sensible thing to do is for Flash to work.  In order to do that, we need to ship both a 32-bit and 64-bit version of mozilla-runtime.

If that's not possible, we should at least show some sort of an error message to the user.

At the current state of things, it seems to the user that OOP is broken.

ehsan@ehsan-ubuntu:~/fa$ dpkg -l | grep nspl
ii  nspluginwrapper                      1.2.2-0ubuntu6                             A wrapper to run Netscape plugins on other a
Blocks: OOPP
Whiteboard: [lorentz]
The underlying problem here actually doesn't have anything to do with OOPP, but rather with the way that ubuntu's addon installs flash on linux x86-64.  I filed for that problem.

A simple workaround is to run
  $ ln -s /usr/lib/flashplugin-installer/ ~/.mozilla/plugins/
after the ubuntu installer finishes.

I'm not really sure in which direction to take this bug, but we can leave it open to at least track the ubuntu issue.  I'd rather not make this bug "support mismatched firefox/plugin architectures", that's a lot to bite off.
Chris, could you please paste the link to the Ubuntu bug you filed here?
(In reply to comment #3)
> Chris, could you please paste the link to the Ubuntu bug you filed here?

Heh, my glasses seem to have crashed.  Restarting...
Not blocking as per comment 2
blocking1.9.2: ? → -
We probably want something like my patch for bug 551471, but for Linux. Mac OS X already does a check like that. Trusting installers to do the right thing is not a good plan.
Not blocking 1.9.3 either, also based on comment 2.
blocking2.0: ? → -
For anyone passing by this bug, the following add-on saved the day as a short-term workaround
Taking this so i think of it when i have time.
Assignee: nobody → georg.fritzsche
Priority: -- → P3
While the rejection of incompatible archs would be easy to do as on OS X:

... we are currently missing an implementation for GetArchitecturesForBinary() on non-OSX platforms:

... probably using libelf to do the check. As far as i can tell we don't have code to base this on yet in the codebase.
Assignee: georg.fritzsche → nobody
Severity: major → normal
Flags: firefox-backlog?
Flags: firefox-backlog? → firefox-backlog+
Flags: firefox-backlog+ → firefox-backlog-
See Also: → 1670988
Resolving as wont fix, plugin support deprecated in Firefox 85.
Closed: 3 years ago
Resolution: --- → WONTFIX
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.