Description of problem:
Firefox does not start up on ppc64.
If started with no previous firefox configuration, it attempts to
bring up the dialog box asking where to import a configuration from.
However the dialog box isn't functional -- the radio buttons don't
'take' when you click on them, and the back/next/cancel buttons are
empty. See http://david.woodhou.se/firefox-import.jpeg
If I first run firefox elsewhere to give me a working configuration,
then firefox on ppc64 just exits silently. However, precisely the same
binaries work on a ppc32 kernel. I've attached the results of 'strace
-f /usr/lib/firefox-0.10.1/firefox' on both ppc32 and ppc64 machines.
Mozilla has problems which may be related. On ppc64, mozilla starts up
but the GUI seems not to be actually attached to anything useful. The
menus all appear to behave normally but don't actually _do_ anything.
You can select 'File.. Quit' but it won't actually happen. Likewise
typing into the location box doesn't cause it to attempt to load a
page. The bookmarks menu and toolbar are empty. Again, precisely the
same binaries work fine on ppc32 kernel.
My initial thought was to blame this on the 64-bit kernel's emulation
of 32-bit syscalls. But bizarrely, my own build of mozilla-1.7.3-11
has precisely the same problems even on a 32-bit kernel. I'm assuming
the two are the same problem, and that they're both related to the
firefox bug too. Even if it's a kernel bug, I have no idea what the
problem might be, so could do with some mozilla-fu in finding what's
Created attachment 105008 [details]
strace of firefox working on ppc32 host
Created attachment 105009 [details]
strace of the same binary failing on ppc64 host
There were two problems. First, when building on a ppc64 host the
libxptcmd Makefile selects the known-nonfunctional 'unsupported'
version rather than the ppc_linux version instead of just refusing to
build on a system which it doesn't recognise.
Secondly -- and this was the one which actually broke our RPM build --
there was a very broken method used to detect the stack direction,
which got it wrong when a static function got inlined by the compiler.
The following patch (also sent unmangled by bugzilla in private mail)
fixes that for both firefox and mozilla:
--- mozilla/js/src/jscpucfg.c.orig 2004-10-19 18:46:55.253506232
+++ mozilla/js/src/jscpucfg.c 2004-10-19 18:47:33.160743456 +0100
@@ -160,7 +160,7 @@
- return (&dummy2 < dummy1addr) ? -1 : 1;
+ return -1; /* It always grows down on supported Linux platforms */
int main(int argc, char **argv)
See also https://bugzilla.mozilla.org/show_bug.cgi?id=242518
I commited a different patch, which prevents inlining of the method in
question, so the check which is a valid check, can stay. This is more
in line with what will need to happen for upstream, to where I
submitted the patch. Marking UPSTREAM, since further work on this
issue will happen there.
This will be fixed in the mozilla -18, firefox -21, and thunderbird