Update: This is now out of date. Unless you insist on running FF4 or FF5, please see the update for FF6.
As far as I can tell, there will be no official release of Firefox 4 for RHEL 6 and clones (running Scientific Linux here).
If you scramble around for SRPMs to build FF4 on RHEL 6, you’ll end up with Fedora stuff which is utterly heedless of those of us who prefer stability. In other words, the SRPM is crafted for the latest and greatest, and unless you are an RPM hacker, you won’t get it to work.
The other course is to absorb another Yum repo, in case this the one from Remi. This means you must also absorb the EPEL repository, which has broken my system in the past and often does not have what I need. It also means there will be conflicts if you happen to like the ATrpm repository, since that tends to be mutually exclusive with EPEL. In other words, you must allow the Fedora folks to own your machine or you can’t have any of their stuff at all. It doesn’t help the Fedora folks are serious die-hard fanboys, and not very friendly to those who aren’t.
The point is, when running RHEL or any of the derivatives, it’s best to build Firefox 4.0 for yourself from source. At the same time, you want it as close to the RPM way of doing things as you can get it, by making sure the package you build includes as many of the same build options as are used in the RPMs. That’s because it will tend to reflect the way your system is designed in the first place.
Download the source from Mozilla, the item labeled firefox-4.0.source.tar.bz2
(or whatever is current by the time you read this). The older orthodox build location is /usr/local/src/
, but these days you are encouraged to build everything from your user account and login as root only to install. I created a src
folder in my home directory, and moved the file there. Then I unzip and untar it, and drop down into the resulting directory (mozilla-2.0).
You’ll need some basic configuration instructions, which comes in the form of a file named mozconfig
. After several attempts, I find the following is as close to the Fedora RPM as you can get for RHEL 6:
mk_add_options MOZ_MAKE_FLAGS="-j4"
ac_add_options --enable-application=browser
ac_add_options --with-system-jpeg
ac_add_options --with-system-zlib
ac_add_options --with-pthreads
ac_add_options --disable-tests
ac_add_options --disable-debug
ac_add_options --enable-optimize
ac_add_options --disable-installer
ac_add_options --enable-default-toolkit=cairo-gtk2
ac_add_options --disable-strip
ac_add_options --enable-pango
ac_add_options --enable-svg
ac_add_options --enable-canvas
ac_add_options --enable-startup-notification
ac_add_options --enable-libxul
ac_add_options --disable-crashreporter
ac_add_options --enable-safe-browsing
ac_add_options --enable-libnotify
ac_add_options --disable-necko-wifi
ac_add_options --disable-cpp-exceptions
ac_add_options --disable-updater
ac_add_options --enable-url-classifier
ac_add_options --enable-gio
ac_add_options --disable-gnomevfs
That first line is for machines with at least a dual core CPU. Change that -j4
to a -j2
if you have an older, single core processor. Otherwise, the only thing you’ll lack are a few dependencies even after installing the basic collection of development packages.
The way to do this is note the instructions here, which are a little out of date. Use the instructions for Fedora to add some packages with Yum. Then run the command make -f client.mk
— if you are still missing something, the build will error out. By scanning upward a few lines from what you see on the command line, you’ll see the name of the package that’s missing. Sometimes you’ll have to run Yum searches to identify what RHEL calls the package you seek, but I didn’t have much trouble working it out. I recall it was three items, but I didn’t take notes at the time. If you need the kind of guidance I offer here, it’s a good time for you to learn for yourself. C’mon; you can do it!
Once it builds successfully, login as root and type make install
, and hit ENTER. Should install nicely with the executable script in /usr/local/bin
named “firefox” — just create your desktop applink to that file.
Just in case things don’t work as you like, I recommend you save a backup copy of your old Firefox settings. In my case, I chose to make a copy of the entire ~/.mozilla
folder, renaming it ~/xmozilla
. The addons for Firefox 3 don’t always work, and you’ll need to upgrade some of them, but on startup the new Firefox 4 will walk you through that.
Enjoy.
Great post. Just one question. Is it possible to make a standalone executable for firefox 4 based on the SC6 default install and its libraries?
Something like pbi packages for PCBSD although we are talking about linux here…
I have no idea. I’ve never looked into making those types of packages; I’m doing well just to get the occasional RPM to build correctly. The closest I can come is using checkinstall to create an ad hoc RPM version.
Sorry, to bother again. Can you make a RPM package of Firefox 4 for a standartd Scientific linux 6 install?
Thank you
It’s not a bother. It depends on what precisely you are expecting. There are some other options I didn’t use, such as where it installs the scripts, binaries, libraries and such. To avoid dependency hassles and so forth, it’s simple to accept the defaults, with everything installed under /usr/local/. Using checkinstall, once you have built FF, run checkinstall instead of “make install” and you’ll end up with a special package for Scientific Linux and should install as normal. The difficulty is matching the exact dependencies, as I’m not sure checkinstall sets those properly, but it will be portable to other SL systems which have the same runtime libraries.
Does that help?