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 going wrong.
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 +0100 +++ mozilla/js/src/jscpucfg.c 2004-10-19 18:47:33.160743456 +0100 @@ -160,7 +160,7 @@ { int dummy2; - 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 -10 versions