Difference between revisions of "User:Melz/Assignment1"
(WIP. First draft.) |
(→Screenshot: - added image) |
||
(15 intermediate revisions by the same user not shown) | |||
Line 16: | Line 16: | ||
After reading some suggestions, I decided to go for the bleeding edge builds on CVS. Apparently [[User:Mylau|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. | After reading some suggestions, I decided to go for the bleeding edge builds on CVS. Apparently [[User:Mylau|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 | + | I also spent some time reading the [http://developer.mozilla.org/en/docs/Build_Documentation build documentation] at [http://developer.mozilla.org/ MDC]. It's probably the best place to get started since it covers the entire building process. |
==Getting the required dependencies== | ==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: | + | 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: | ||
+ | |||
+ | <pre> | ||
+ | cvs -d :pserver:anonymous:anonymous@cvs-mirror.mozilla.org:/cvsroot co mozilla/client.mk | ||
+ | </pre> | ||
+ | |||
+ | Unfortunately, that command just hung there. CVS wasn't checking out anything. I double-checked the [http://developer.mozilla.org/en/docs/Mozilla_Source_Code_Via_CVS#Requirements 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: | ||
+ | |||
+ | <pre> | ||
+ | . $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 | ||
+ | </pre> | ||
+ | |||
+ | Everything seems ready. So I started compiling: | ||
<pre> | <pre> | ||
− | + | make -f client.mk build | |
</pre> | </pre> | ||
− | + | ... which then died at the following pre-requisite check: | |
<pre> | <pre> | ||
− | + | checking for gtk+-2.0 >= 1.3.7 gdk-x11-2.0 glib-2.0 gobject-2.0... | |
</pre> | </pre> | ||
− | ...'' | + | 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 <strike>pretty</strike> 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= | =Screenshot= | ||
− | Here's | + | Here's a screenshot of the Help > About Mozilla Firefox dialog for my custom build: |
− | + | [[Image:Melz_ff3ss.png]] | |
=Conclusion= | =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. | ||
+ | |||
+ | This entire build process wouldn't have been successful without help from the various people at the #seneca IRC channel, the build documentation at Mozilla Developer Centre, and good 'ol trusty Google. Thanks for all your help! |
Latest revision as of 17:47, 18 September 2006
Contents
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
Here's a screenshot of the Help > About Mozilla Firefox dialog for my custom build:
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.
This entire build process wouldn't have been successful without help from the various people at the #seneca IRC channel, the build documentation at Mozilla Developer Centre, and good 'ol trusty Google. Thanks for all your help!