Current versions of mozilla-firefox have a configure file which has a "--enable-static" option. At least with Firefox 3.0.X/3.5.X versions from CVS this produces builds which *do* build correctly (so long as the typeaheadfind extension is not enabled). This reduces the number of firefox shared libraries and reduces firefox startup and gdb startup time (if one is compiling with -ggdb/splitdebug/nostrip). Given the lack of attention by Mozilla/Firefox developers to Linux distributions and the longstanding bugs (gdk, session restore, cpu use/GREEN, memory ulimit, flash, etc. bugs for there to be any effective improvement in Linux versions of Firefox, it will be necessary for Linux developers to drive this. That becomes much easier if one can build "static/debug (-ggdb/splitdebug|nostrip)" versions from the standard Linux distributors (rather than having to use the disk space, CPU, etc. for a "distributed" version + multiple CVS versions directly from Mozilla). Single images also help from the perspective of testing "old" bugs (some of the gdk/ulimit bugs have existed for years) if one wants to compare "old" and "new" versions of Firefox on the same profile without having to worry about various combinations of firefox (or seamonkey, galeon, etc.) with xulrunner, nss, nspr (ignoring the system libraries). Getting the "static" flag (--enable-static), and perhaps a real "debug" (-ggdb) flag into the ebuild(s) would be a start towards getting effective stack traces, and increased probability of people attempting to debug (and improve) Firefox under Linux. It is worth noting that it is "almost" possible to build a completely static firefox (reducing the number of shared libraries from 75-100 down to < 10) with the following minimal changes: 1) Gentoo enables --enable-static in more of the standard system libraries (primarily glib and gtk+) [This is a Gentoo problem]. 2) Mozilla changes configure to use fewer system .so files -- this requires a "fudged" load sequence that pulls in most of the system .a files, leaving only those which require real dynamic loading (using dlopen()). I have done this (with 2.X) and it makes debugging Firefox much easier. When this change is made for firefox (and the USE documentation updated), consideration should be given to allowing it for all the Mozilla dependent packages (Seamonkey, Galeon, Epiphany, etc.). Reproducible: Always Steps to Reproduce: 1. USE+=" static" emerge mozilla-firefox Actual Results: A static use option does not get passed as --enable-static to configure. Expected Results: Generally speaking Gentoo should pass USE=static as "--enable-static" to all libraries/packages as it tends to be an option in most configure file. Whether it does anything (or what the end-user intends) with those packages is a package-specific problem (as there tends to be a real difference in what static should do with packages which are "libraries" vs. packages which are programs vs. packages which are libraries and/or programs). I consider this to be a normal bug given the longstanding (and arguably worsening) situation with Firefox (and other Mozilla packages) on Linux. While it doesn't rise to the level of being "major" it is relatively easy to correct and would significantly lower the "barriers to entry" for qualified developers to actually work on improving Firefox under Gentoo. It took me about 2 years (off and on) to learn enough about Gentoo to get to the stage where I could actually debug Firefox (it was difficult enough that I punted and started using the Mozilla CVS directly to get something which was both up-to-date and amenable to real debugging). Workable "static" and "debug" ebuild options would have eliminated those hurdles.
To many packages depend on parts of xulrunner being built shared, if they where static the package that links to xulrunner would fail.
Well one could easily be using firefox without having to have non-firefox xulrunner based packages installed. For example one could simply choose to run firefox static without running epiphany, galeon or icecat [indeed in 5 years I've never used icecat]. So there is *no* point to having a shared xulrunner and resolution of links in a large library such as xulrunner slows program startup times (which are already slow with Firefox). One would also wonder why someone would choose to typically run all of epiphany, galeon and firefox (the only reason I sometimes do so is to have browser instances with Javascript enabled and disabled) -- and as Firefox has yet to be fully integrated into Gnome (can't easily restart multiple Firefox profiles within different workspaces) different browsers seems to be one of the few means of distinguishing between session "types". But there *is* a perfectly reasonable situation where a user wants to run as many static images as possible because it reduces the single-point-of-failure probability due to a shared library data corruption or external security risk exposure (e.g. Windows security problems that arise due to the corruption of a single "critical" DLL). The recent glibc upgrade breaking many programs built as static images points out however how even this may be flawed if implementations of glibc are not *really* static. The adoption of a perspective that static builds are not "useful" destroys the effectiveness of "extent" based file systems (e.g. btrfs) because it prevents the loading of a program over what could well be a single track read of the disk. And thus leads to slower system start and/or session login times (a point that Ubuntu seems to be addressing by promoting "swiftness" in newer releases).
You miss the fact that yelp and others depend on shared objects being avaliable not just web browser components.
