Bug 208700 - 64-bit firefox not functional
64-bit firefox not functional
Product: Fedora
Classification: Fedora
Component: firefox (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Christopher Aillon
Depends On:
  Show dependency treegraph
Reported: 2006-09-30 07:42 EDT by David Woodhouse
Modified: 2007-11-30 17:11 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-04-02 14:52:25 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Mozilla Foundation 361413 None None None Never
Mozilla Foundation 361415 None None None Never

  None (edit)
Description David Woodhouse 2006-09-30 07:42:14 EDT
After an upgrade from FC5 to FC6 I had firefox and firefox-devel installed for
both ppc and ppc64 architectures.

/usr/bin/firefox attempts to run the ppc64 version, which fails.

Furthermore, /usr/bin/firefox _redirects_ the error messages to /dev/null,
making it hard to diagnose. Manually running it shows the following:

[dwmw2@pmac ~]$ /usr/lib64/firefox-

(firefox-bin:10192): Gtk-WARNING **: Unable to locate theme engine in
module_path: "clearlooks",
[dwmw2@pmac ~]$ 

I'm not sure why the actual firefox binary is installed for both architectures
-- wouldn't it be sufficient to install just the libraries which are supported
by firefox-devel? That is, shouldn't we have separate firefox-libs and firefox
packages, and install only the _former_ in both architectures?
Comment 1 David Woodhouse 2006-10-16 07:05:50 EDT
Installing gtk2-engines.ppc64 makes the above warning go away but firefox still
just exits, now silently.

Breakpoint 2, 0x0000008051144cd0 in .exit () from /lib64/libc.so.6
#0  0x0000008051144cd0 in .exit () from /lib64/libc.so.6
#1  0x00000080511297f4 in .generic_start_main () from /lib64/libc.so.6
#2  0x0000008051129a68 in .__libc_start_main () from /lib64/libc.so.6
#3  0x0000000000000000 in ?? ()

It wants fixing, but we don't actually want to be using 64-bit firefox anyway,
so the simplest fix in the short term is probably to drop the firefox.ppc64
package from the compose, since it's probably too late to fix it properly by
moving the libraries into a separate 'firefox-libs' package.
Comment 2 David Woodhouse 2007-01-02 11:43:08 EST
We've shipped a few firefox updates since FC6 was released with this FC6Blocker
bug still unfixed, and we're _still_ knowingly shipping an officially-branded
"firefox™" which is totally non-functional on ppc64.

We should be shipping only the 32-bit firefox, or at _least_ fixing the
/usr/bin/firefox shell script so that it runs the 32-bit firefox by default
instead of the 64-bit one.
Comment 4 David Woodhouse 2007-01-02 15:27:54 EST
Note that even if 64-bit firefox actually worked, it would be the wrong thing
for us to do. Our distribution is mainly 32-bit on PowerPC; our plugins are
32-bit. The plugins available elsewhere (RealPlayer, Java) are 32-bit.

For us to ship a 64-bit firefox would be inconsistent with the rest of the
distribution and very suboptimal -- even if it _did_ work. We need to use 32-bit
Comment 5 Christopher Aillon 2007-01-02 15:36:20 EST
Noted for the hundredth time.  Please let me know when your patch is ready.
Comment 6 David Woodhouse 2007-01-02 15:40:49 EST
The patch won't be ready for 1.5.0.x -- it's for trunk only.
Comment 7 Christopher Aillon 2007-01-02 15:43:57 EST
Then we need a 1.5 version.
Comment 8 David Woodhouse 2007-01-02 15:59:56 EST
No, we don't. For reasons outlined in comment #4.
Comment 10 David Woodhouse 2007-01-02 16:26:46 EST
Please don't make private comments; this is a Fedora issue and if you have
something which you don't want to say in public then it's better not to say it
at all.

In a _Fedora_ context there is no need for a 1.5.0.x patch and I will not be
generating one -- because it would be counterproductive if we actually _shipped_
such a thing. If upstream wants it then they can of course do it for themselves
-- but it isn't something we want to ship in Fedora.
Comment 11 Christopher Aillon 2007-04-02 14:52:25 EDT
Should be fixed now.

Note You need to log in before you can comment on or make changes to this bug.