Open main menu

CDOT Wiki β

User:Melz/Assignment1

< User:Melz
Revision as of 00:12, 18 September 2006 by Melz (talk | contribs) (Introduction)

Introduction

I successfully built the Firefox brower (bleeding edge version) on Ubuntu Linux using gcc. Amazingly, I managed to compile it on an ancient AMD 1.1GHz machine with 256MB of RAM. I'm well aware of the minimum build requirements but since I had restricted resources over the weekend, I went ahead anyway.

The entire journey took approximately two days. As you may have guessed, most of the problems that occured were due to hardware issues (ie. lack of memory). But this just proves that where there's a will, there's always a way!

The Journey

Get on IRC

The first thing I did was get on #seneca channel (irc.mozilla.org) and idled for a week or so. The concept was to wait for others to try building Firefox, let them share their error messages and log all the suggestions shared by everyone who helped to resolve the issues.

In short, this helps one figure out which operating system is the best and painless option for building Firefox. Not to mention, it helps a lot to obtain a list of required dependencies before having to watch the compiler spit out the error messages at you.

Deciding which version of Firefox to build

One week later, I'm finally ready to start building.

After reading some suggestions, I decided to go for the bleeding edge builds on CVS. Apparently mylau faced a number of issues while building from the stable source archive, and Vlad's suggestion was to go with CVS to avoid those headaches.

I also spent some time reading the build documentation at MDC. It's probably the best place to get started since it covers the entire building process.

Getting the required dependencies

The default installation of Ubuntu 6.06 was rather bareboned for developers. I had to install some required tools to get started, namely the gcc compiler and cvs.

Now I'm ready to check out some code and compile stuff! After getting the green light on Tinderbox, I proceeded by executing the following command:

cvs -d :pserver:anonymous:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/client.mk

Unfortunately, that command just hung there. CVS wasn't checking out anything. I double-checked the documentation and apparently cvs 1.12.9 was reported to work fine. After spending an hour looking around, I came to the conclusion that the college labs had the cvs port blocked.

Now I had to resort to downloading the source and compiling it on my old computer at home.

Configuring and Building

The second attempt to check out the source from CVS was sucessful. So it was the college firewall that was causing problems earlier.

Next, I had to configure the build options. I went ahead with the sample .mozconfig included in the build documentation:

. $topsrcdir/browser/config/mozconfig
mk_add_options MOZ_OBJDIR=@TOPSRCDIR@/ff-opt-static
ac_add_options --enable-optimize
ac_add_options --disable-debug
ac_add_options --enable-static
ac_add_options --disable-shared
ac_add_options --disable-tests
mk_add_options MOZ_CO_PROJECT=browser

Everything seems ready. So I started compiling:

make -f client.mk build

... which then died at the following pre-requisite check:

checking for gtk+-2.0 >= 1.3.7 gdk-x11-2.0 glib-2.0 gobject-2.0... 

Browsing through the IRC logs, I realized I needed to install a few more dependencies, specifically libgtk-dev and libidl-dev.

After that, everything went chugging along ... or so it seemed.

Wrapping things up

Since my computer was pretty really slow, I left it compiling overnight.

When I woke up, the build process had died prematurely. I googled the error message and there wasn't much of a solution to the problem other than reinstalling gcc. Since memory was an issue here, I assumed it must have "crashed" due to lack of memory.

So I ran the build command again and the build process picked up from where it ended. I concluded that it really was due to lack of memory. This problem continued to occur several times after (each time at different points of the code, but with the same error code).

Slowly, I approached the final goal. Unexpectedly, the last linking part keeps crashing my terminal window so I couldn't proceed further.

Since Gnome probably sucks up enough memory by itself, I decided to switch to console mode (I know, why didn't I think about it before?). After I did that, I killed both the Gnome Display Manager (gdm) and VMWare (since it was running as well).

I crossed my fingers and started building again. And it finally completed sucessfully. Phew!

Screenshot

Conclusion

Overall, I think it was quite an interesting adventure, having compiled my own custom build of Firefox. This is the first GUI application I ever compiled on Linux and I must admit it also has the largest codebase I ever handled for a single application.

Along the way, I picked up a lot of useful knowledge, particularly those relating to maximizing my Linux experience. I'm not covering them in this report since the topics I had to delve into ranged from changing boot options all the way to simple commands for switching to console mode.

However, I definitely would want to rebuild the source tree again sometime soon because I broke a number of "rules" by not cleaning up my object folder after a compile error. Obviously, I was playing with fire by doing so, but since I didn't want to spend extra time re-compiling everything, I went ahead and risked it. In fact, I'm still amazed I successfully built Firefox from CVS that way.