Red Hat Bugzilla – Bug 163665
firefox doesn't start on x86_64
Last modified: 2009-01-19 09:39:43 EST
From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.7.8) Gecko/20050715 Fedora/1.7.8-6 Description of problem: Running firefox on a FC devel x86_64 box as of 2005-07-19 completes almost immediately, even if ~/.mozilla/firefox does not exist to begin with, and no mozilla or firefox window is open. After the firefox script terminates, no firefox-related process is running, and ~/.mozilla/firefox was created. My firefox profile works fine on an i686 box with an FC devel just as up-to-date works fine. Running firefox on remote displays works or fails to work the same as on local displays, e.g., if I ssh from the i686 box to the x86_64 box and start firefox in it, it won't work; if I do it the other way round, then it works fine. I tried installing only the 32-bit version of firefox on the x86_64 box, removing the 64-bit version, but, oddly, this one wouldn't start either. Version-Release number of selected component (if applicable): firefox-1.1-0.2.1.deerpark.alpha2 How reproducible: Always Steps to Reproduce: 1.Run `firefox' from the command line, or start it from the menus or panels, on an x86_64 box Actual Results: Nothing happens Expected Results: It should start like it does on i686 Additional info:
Got a gdb backtrace and/or strace?
Created attachment 116965 [details] strace -f firefox-bin, as called by run-mozilla.sh No gdb trace, since it doesn't crash; it terminates normally. I'm attaching an strace of firefox-bin, with the arguments and environment passed to it by run-mozilla.sh (I added the strace call to run-mozilla.sh).
Created attachment 116966 [details] diff from previous strace to run with LD_LIBRARY_PATH=/usr/X11R6/lib64 I noticed the previous run didn't find libXcursor.so, so I added LD_LIBRARY_PATH=/usr/X11R6/lib64, but, although this time it found the lib, that didn't make much of a difference, as the strace diff shows.
An interesting data point: if there is a running firefox on the active display (e.g., started on a remote x86 box), running the broken x86_64 firefox succeeds in requesting the running firefox to open a given URL. So it's not *all* broken.
After updating to 20050721's firefox-1.1-0.2.3.deerpark.alpha2 and rebooting, it started in x86_64 again. Not sure whether it was the update or the reboot, but it's fixed.
Cool. Wonder if this was a duplicate of bug 163653 then.
I may have run into that as well, but when I first ran into the problem, I tried even moving my ~/.mozilla out of the way, to get a fresh start, and that didn't help.
Still doesn't work for me: [system@amd64-3000 firefox-1.1]$ firefox [system@amd64-3000 firefox-1.1]$ ./firefox-bin ./firefox-bin: error while loading shared libraries: libmozjs.so: cannot open shared object file: No such file or directory [system@amd64-3000 firefox-1.1]$ ls -l libmozjs.so -rwxr-xr-x 1 root root 673216 Jul 23 02:27 libmozjs.so [system@amd64-3000 firefox-1.1]$ rpm -q firefox firefox-1.1-0.2.4.deerpark.alpha2
Your issue appears different than the original issue that was reported, though the end result is the same. Please file a new bug? That way we can better track the different issues. Thanks.
Ok. entered as 164341.