469493 - Firefox 3.1 does not build with --enable-static (on Linux)

Status: RESOLVED WONTFIX

(Firefox Build System :: General, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.18) Gecko/20081123 Galeon/2.0.4 Firefox/2.0.0.18
Build Identifier: firefox-3.1b2-source.tar.bz dated 121210 @ 19:16

I only use the shell script configure options to configure builds.  Whoever made up the additional options on top of that should IMO be keel-hauled.  "configure" has worked fine for a decade or more for Linux configurations (except when the people editing the script mess up).


Now with respect, to the "configure" script and options.
With Firefox 3.0.6pre, I happen to use options such as:
    --enable-application=browser \
    --enable-optimize="-O2 -g2" \
    --disable-shared \
    --enable-static --disable-libxul \
    --disable-tests \

which *will* produce a workable viable firefox-bin which can be installed and run.


Reproducible: Always

Steps to Reproduce:
1. Attempt to configure a Firefox 3.1 Beta with opptions such as:
    --enable-application=browser \
    --enable-optimize="-O2 -g2" \
    --disable-shared \
    --enable-static --disable-libxul \
    --disable-tests \

2. Attempt to run configure
3. Configure will fail
   Error:
    configure: error: --enable-static is not supported for building firefox. You probably want --enable-libxul.

4. No. I don't even know what "libxul" is (if someone could point out documentation for it it would be appreciated).   I want a *STATIC* browser image (or as close to it as can be produced using the Firefox configuration system.) I know what a "browser" is, e.g. "firefox" and I know what --enable-static is (at least in dozens of other Linux apps -- it means you produce .a libraries that can be loaded into a *static* image) [1].

5. So I follow the suggestions of the error message and change the configure to:
    --enable-application=browser \
    --enable-optimize="-O2 -g2" \
    --disable-shared \
    --disable-libxul \
    --disable-tests \

And this does not work.  It seems to produce an extremely small browser/app/firefox-bin and when one attempts a "make install" one gets:
 gmake[1]: Entering directory       
   `/src/Firefox/firefox-3.1/mozilla-central/browser/installer'
Makefile:71: *** you need a "--enable-static or --enable-libxul" build to package a build.  Stop.
gmake[1]: Leaving directory `/src/Firefox/firefox-3.1/mozilla-central/browser/installer'

I removed the "--enable-static" because it resulted in a non-configuration.
I did not enable "--enable-libxul" because I don't know what libxul is and have
no interest in it for a Firefox browser based application.

IMO, you could do a much better job with respect to whether various configurations work under Linux.  Let me state this VERY explicitly -- I care nothing about whether Firefox 3.0.X runs under windows -- I only care if I can compile and debug the software under Linux.  And in situations where one cannot follow the conventions which have existed under Linux for a decade or more and under UNIX for several decades before that -- you are likely to incur significant displeasure on the part of individuals who understand the development paths.
Actual Results:  
Firefox-3.1b2 will not compile and install under Linux given flags which worked properly under firefox-3.0.6pre.

Expected Results:  
Could you at least release Firefox versions which are *KNOWN* to compile and build under specific versions of Linux (and document that!?!)   That means one does not release Mozilla specific configurations but one releases Linux specific configuration files (i.e. those directly using "configure").  Which can be edited on a switch by switch basis to determine what you haven't bothered to test.

Comment 1

[(not currently active) Ted Mielczarek]

Firefox builds just fine on Linux. Those error messages are very clear, I don't know how you think we could make them any better? You're passing random options to configure, and then complaining that they don't work. That makes no sense. If you simply configured as:
./configure --enable-application=browser

You would have wound up with a working browser that "make install" works on.

In short:
* We stopped supporting --enable-static builds of Firefox, as that's not what we ship, and they offer no advantage over libxul builds
* We don't support "make install" on shared builds, which is what you get when you --disable-libxul
* Ranting at developers in bugs does not endear you to them

Comment 2

[Robert Bradbury]

Ted, I am *NOT* passing "random options" to configure.  I am passing options which largely worked under Firefox 2.0 and 3.0.x prereleases (which with a fair amount of work could be used to attempt a static Firefox build).

Now if you are going to change build options, e.g. "--build-static" or "--disable-libxul" to operate differently between 3.0.x alpha and 3.1 then I would expect some documentation and some rationale.

*** Where is it? ***

Now, I realize that the Firefox developers are generally opposed to static builds, but I can provide a number o reasons they are useful.
1) First and foremost they load faster.  (There is no argument against this.  Loading shared libraries and resolving symbols creates a delay in load time.  And you don't "ship" anything from my perspective (under Linux) -- you may provide a binary download of Firefox under windows (but I hate and despise windows) and my Firefox distributions under Gentoo Linux are compiled from the open source.

2. Second, they are distributable and debugable image.  We have had the problem with Bug #467744.  If one is dealing with a distributable image which relies on shared libraries and the libraries change underneath the distribution (hopefully to correct bugs) the debuggers cannot provide a decent stack trace or frame examination.

3. Who the hell are you as the "Firefox gods" to assume a position or perspective that "we shall distribute no static binaries"?  I may want a binary that I can decode assembly line by assembly line (the Russians and the Chinese do this) from a security standpoint.  If one does not have the ability to mix and match secure vs. insecure system libraries then one is screwed.  I would trust a distributed secure application as a "static" distribution from a known source over a non-static use whatever system libraries are available -- this is what created many of the problems Windows is currently undergoing.

In short -- the current Firefox/Mozilla perspective is highly questionable -- we want you to release the most current software.  We want you to do so securely.

In short, I view the current perspective of Firefox to distribute insecure software relying on unknown system libraries as faulty -- and a significant problem which needs to be addressed.  The only way to resolve this problem is to distribute "certified" software which works on "certified" OSs.  You must distribute "certified" packages -- and a significant part of that is to distribute a "static" Firefox (with documented libraries).

Comment 3

[Wolf [:wolf]]

"libxul intends to replace this mix of shared libraries with, a static build of "gecko" including XPCOM, networking, DOM, layout, rendering, and embedding modules in one shared library."
From https://wiki.mozilla.org/XUL:Lib_XUL, which if you googled libxul, you'd have found.

https://developer.mozilla.org/en/Configuring_Build_Options#Statically_Linking_Components

Comment 4

[Jesse Ruderman]

If we no longer support --enable-static, maybe the error message "you need a '--enable-static or --enable-libxul' build to package a build" should be changed :)

Comment 5

[(not currently active) Ted Mielczarek]

You may certainly do whatever you like with the source, but we do not have to support build options that we do not want to. Feel free to patch the source locally to make it work however you would like.

Comment 6

[(not currently active) Ted Mielczarek]

--disable-libxul isn't the problem here, it builds fine with that, you just can't install the resulting build. (Shared builds are meant for development.)

I agree that we might be able to make the error messages a bit clearer, but I disagree with the incoherent premises of this bug.

Comment 7

[Robert Bradbury]

Yes, Wolf, thanks for pointing that out and I have yet to read and process it.  But it is sometimes hard to know what to look for when one is copying configurations (from Gentoo emerge logs) and adapting them.  Neither the mozilla-firefox or mozilla-thunderbird emerges (which is what would be typical for a Gentoo Linux configuration) involve enabling or disabling libxul!  And the Gentoo emerge processes are exemplary in that they document explicitly what they are handing to the mozilla "configure" file.

I was simply taking configurations "known-to-work" (distributed by major Linux suppliers) and adapting them with standard flags, e.g. "--enable-static" which has a very standard definition under Linux (i.e. one produces .a libraries that can be linked statically).  Now the Mozilla/Firefox developers, (who if I may wax editorially) seem to have their heads up a Windows a**hole, do not seem to understand the concept of a REAL static link.  I.e. something that runs "standalone" on the hardware & OS.

Now, this may be difficult under Linux, given the ability to attach shared libraries "at will", but one *should* be able to produce a minimal (static linked) functional browser (without a requirement for *any* external libraries) if one wants to separate problems in the product from problems in the system (Hardware+OS).

So I reject the claim by Mozilla that this problem is either (a) RESOLVED; or (b) INVALID.  If you cannot produce a "static" product you have *no* product.

Comment 8

[Benjamin Smedberg]

And yet, the project module owners are the ones who get to make that decision.

For what it's worth, --enable-static in Mozilla does not do what you seem to think. It folds various XPCOM components in with the main binary, but it does not remove all use of shared libraries, and it still links with dynamic libc/libstdc++/etc.

The libxul configuration is faster than the static configuration, and has been carefully designed to be our default and best configuration. We're not going to support other configurations. Please do not re-open this bug.

Comment 9

[Robert Bradbury]

Yes, Wolf, thanks for pointing that out and I have yet to read and process it.  But it is sometimes hard to know what to look for when one is copying configurations (from Gentoo emerge logs) and adapting them.  Neither the mozilla-firefox or mozilla-thunderbird emerges (which is what would be typical for a Gentoo Linux configuration) involve enabling or disabling libxul!  And the Gentoo emerge processes are exemplary in that they document explicitly what they are handing to the mozilla "configure" file.

I was simply taking configurations "known-to-work" (distributed by major Linux suppliers) and adapting them with standard flags, e.g. "--enable-static" which has a very standard definition under Linux (i.e. one produces .a libraries that can be linked statically).  Now the Mozilla/Firefox developers, (who if I may wax editorially) seem to have their heads up a Windows a**hole, do not seem to understand the concept of a REAL static link.  I.e. something that runs "standalone" on the hardware & OS.

Now, this may be difficult under Linux, given the ability to attach shared libraries "at will", but one *should* be able to produce a minimal (static linked) functional browser (without a requirement for *any* external libraries) if one wants to separate problems in the product from problems in the system (Hardware+OS).

So I reject the claim by Mozilla that this problem is either (a) RESOLVED; or (b) INVALID.  If you cannot produce a "static" product you have *no* product.

As a side note to Benjamin *then* you should NOT call the flag "--enable-static" because that has a specific meaning when one is building X-libraries which does not appear to be followed by mozilla-developers.

And my comments regarding a static-link stand.  You seem to be completely rejecting the concept without acknowledging its usefulness in some situations.  I find that a lousy debating position.  Yep you can win by being a "dictator" but wait until the day when the people reject that perspective.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Robert, no one's arguing against your use case for a real static link.  All that's being said is that we don't plan to put in the time and work to support it.  Anyone who wants to is welcome to do this, of course: the source is open.  That said, we don't want to spend time maintaining such code either, hence a change to provide this option wouldn't be accepted into the main codebase.

Re-resolving with the original resolution, which looks correct to me.

Please don't reopen this bug again.  If you feel that the above policy decision by the module owner is wrong, please raise the issue in the relevant newsgroup.  You'll have the most luck with that if you also have a maintainer for the code you want added.

> Yep you can win by being a "dictator" but wait until the day when the people
> reject that perspective.

Sure.  If and when that happens, there will be a policy change.  I suggest you read up on Mozilla's module owner system.  At the moment, there is general satisfaction with the ownership of the build system module, for what it's worth.

Comment 11

[Robert Bradbury]

Boris, I appreciate your comments because it did appear that Ted's comments were arguing for the position that there is not and should not be a "static link".  If we are at the position where "static links" are a reasonable goal, but not currently supported by the current development team, then the goal from a development standpoint should be how to encourage the possibility of static links.  The 3.1 configure does *not* do that.  And that is why I have backtracked to the 3.0 configure and will backtrack to the 2.0 configure if necessary.

I have reconfigured my "configure" arguments 23 times in the hope of finding a combination of --enables, --withs, --disables, --withouts, that will build a set of ".o" and/or ".a" files which can be assembled into a functional firefox.  So far no success.  But I'll keep at it until I come to the conclusion that its hopeless.

FMI: Is there a list of known developer "admins" who get to shift the priorities (e.g. build-it vs. build-it-in-static form)?  Because if the development process continues in the direction it seems to be on it will generally turn me off on Firefox (the only really useful features are NoScript and AdBlock).  If I can find equal features in another browser I will switch to it.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Robert, just dropping --enable-static will build a functional Firefox.

> Is there a list of known developer "admins" who get to shift the
> priorities 

Priorities are set through discussion, with module owners having final say in their module (subject to possible veto from Brendan).   The module owners list is at http://www.mozilla.org/owners.html

The right route for policy discussion is the newsgroups, as I said above.