If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Firefox does not install as configured




Build Config
9 years ago
6 years ago


(Reporter: Robert Bradbury, Unassigned)


3.0 Branch

Firefox Tracking Flags

(Not tracked)




9 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008091617 Firefox/3.0.3pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/2008091617 Firefox/3.0.3pre

If I configure firefox with "--disable-strip" and "--disable-strip-libs" (and '--enable-optimize=-O2\ -g2') [note I am running configure directly, bypassing the convoluted .mozconfig] one would expect the *compiled* firefox to be compiled with debug symbols and installed with debug symbols (and this is what I believe happened with Firefox 2.0).

Now, installed Firefox 3.0 binaries are stripped of all symbols.  I *do* not want my installed binaries stripped, I want them *exactly* as they are compiled and produced in the source directories.  This change was apparently made back in April 2008, or maybe earlier, when toolkit/mozapps/installer/packager.mk was changed to create an alternate firefox-devel (sdkdir) directory in which the lib subdirectory contains exact copies of the .so libraries with debug symbols.

I do not want 2 copies of the Firefox libraries (one stripped and one unstripped) installed.  I just want 1 single functional copy with debug symbols (as was the case in 2.0).  The idea of wasting disk space with non-debug & debug versions is silly.  Or if you are going to do it require an explicit --enable-sdk option (default should be Firefox 2.0-like install with no stripping of the debug symbols).

It should be noted that even with the firefox-devel directory there is no unstripped firefox-bin! (despite the --disable-strip).

While I have managed to locate the "STRIP" definitions in autoconf.mk and rules.mk, both ENABLE_STRIP and PKG_SKIP_STRIP are undefined in my autoconf.mk file -- so I do not understand *where* the strip activity is taking place.  Due to the excessively complicated Firefox install process (e.g. nsinstall?) there is no output in the make output files that can direct me to what make file or program file I must modify to terminate this improper strip activity.

Reproducible: Always

Steps to Reproduce:
1. Build firefox with config optiosn as outlined in Details section, disabling all strip activity.
2. Install firefox (make install into /usr/local/lib/firefox-*)

Show me the document where it the justification for this change in firefox install behavior is justified.  Or is this simply creative thinking on the part of some developer attempting to see how much extra disk space around the world he can waste?
Actual Results:  
Striped firefox-bin and shared libraries end up in the firefox- directory while nonstriped shared libraries end up in the firefox-devel directory.

Expected Results:  
As in previous versions of firefox the installed binary and shared libraries should contain all debug symbols.

It would also be nice if when one included the "--enable-static" option one really ended up with a *STATIC* firefox (which would load faster than those that may require searching through many directories many times for shared object libraries).  On all desktop systems (which generally have a single user) there may only be a single firefox process ever running.  Such users may prefer faster startups rather than shared libraries (which are never shared).

On Gentoo Linux, it would be nice if firefox, mozilla, nvu (or kompozer), seamonkey, etc. would all "share" the shared libraries -- but that isn't the way the package management and install processes operate.  So effectively all of the "shared libraries" are single-copy unshared libraries.  I suspect this is true for other Linux versions as well.

It is also worth noting that when "--enable-static" is used, the install process complains with at least 28 Warnings, e.g.
Warning: package error or possible missing or unnecessary file: bin/defaults/existing-profile-defaults.js (packages-static, 18).

A proper install should not be issuing warnings of this nature.


6 years ago
3.0 branch is no longer supported.
Have you seen this improved (or worsened) in more recent releases?
Version: unspecified → 3.0 Branch
(In reply to Wayne Mery (:wsmwk) from comment #1)
> 3.0 branch is no longer supported.
> Have you seen this improved (or worsened) in more recent releases?
Whiteboard: [closeme 2011-08-27]

Comment 3

6 years ago
Closed per Whiteboard
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Whiteboard: [closeme 2011-08-27]


6 years ago
You need to log in before you can comment on or make changes to this bug.