Well, the system requirements page for Firefox claims to support my OS, but the 1.5 release crashes on startup just like the nightlies do. Quite unfortunate.
And before yet another wise-ass suggests that I should upgrade my OS, I must point out that I use this computer for actual work, which means that I can't just do OS upgrades willy-nilly, since they tend to make it unusable for a few weeks until I fix all the breakage from RedHat's update utility. That might be an option in summer 2006, but not till then.
Posted by bzbarsky at December 6, 2005 7:55 PMDoesn't work on Ubuntu 5.10 either :(
Pretty sure you just have to add the compat libstdc++ library or something like that. It worked for me :-)
- A
Posted by: Asa Dotzler on December 6, 2005 8:22 PMAsa, you have to install the libstdc++ update to a vanilla RedHat 8 in order to get Firefox to even _try_ starting. Then if the update has been installed it tries to start and crashes. We've had a bug open on this since May or June, if you recall.
Posted by: Boris on December 6, 2005 8:52 PMAsa: do you honestly think the user should have to do that?
[quote]
Doesn't work on Ubuntu 5.10 either :(
[/quote]
Both 1.5 and the nightlies work fine here on Ubuntu 5.10, weird....
Posted by: Shadow3333 on December 7, 2005 1:03 AMIn case someone cares, the crash on startup that I get is: http://talkback-public.mozilla.org/talkback/fastfind.jsp?search=2&type=iid&id=12685115
Posted by: Boris on December 7, 2005 8:54 AMBoris, I reopened bug 187029, which has same stacktrace:
https://bugzilla.mozilla.org/show_bug.cgi?id=187029
Yeah, I saw that bug. Reopening it is probably pretty useless -- no one will ever work on it.
Posted by: Boris on December 7, 2005 10:20 AMSomehow that rang a bell, because Firefox won't start on my work machine (SuSE 9.3), either, while SeaMonkey does.
Now that I looked at it again I see that it's a different problem, though: https://bugzilla.mozilla.org/show_bug.cgi?id=246313#c33
Posted by: Peter Weilbacher on December 7, 2005 11:43 AMTry installing/upgrading just GTK+. If you don't want it to affect the rest of the system, compile the new GTK+ stack from the source then use LD_LIBRARY_PATH=/usr/local/lib
This is of course a huge pain in the butt but it'll let you find out if it's hitting a bug in an early GTK2 that was fixed in later versions (this has happened to me before).
Posted by: Mike Hearn on December 7, 2005 3:50 PMMike, I've tried just upgrading GTK; that really doesn't play nice with other things if I want to use an RPM -- too much stuff has GTK versions hardcoded into their dependencies... The /usr/local idea has the same problem -- RPM won't really let two separate GTK versions hang around, at least that I know of.
That said, my own builds (against GTK2 and all) work fine, both those I build on my own machine and the ones I build on the loaner Fedora Core 3 machine I have. So while this may be a bug in the GTK2 version I have, I'm having a lot of trouble hitting it _except_ with the Mozilla.org Firefox builds.
Posted by: Boris on December 7, 2005 7:02 PM