376505 - Current CVS source cannot be built on Linux

Status: RESOLVED INVALID

(Firefox Build System :: General, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.1) Gecko/20061208 Firefox/2.0.0.1

As of April 3, 2007, did a source update from CVS and attempted to compile firefox.  Build fails with errors in:
../../dist/include/xpcom/nsTHashtable.h
./../include/nsScriptSecurityManager.h
nsBindingManager.cpp
nsCSSFrameConstructor.cpp
nsCSSRendering.cpp
nsChromeRegistry.cpp
nsCommandParams.cpp
nsContentList.cpp
nsDisplayList.cpp
nsDocument.cpp
nsFrameManager.cpp
nsHTMLDocument.cpp
nsLayoutUtils.cpp
nsScriptNameSpaceManager.cpp
nsViewManager.cpp
nsXULDocument.cpp
txKeyFunctionCall.cpp

Attachments will follow.

Reproducible: Always

Steps to Reproduce:
1. cd mozilla; make -f client.mk checkout MOZ_CO_PROJECT=browser
2. make clean distclean
3. sh 1SETDBG.sh  # run configure
4. make -i > Compile.lst 2>&1
Actual Results:  
Many errors.  Summary will be attached.

Expected Results:  
It *should* have compiled.


Two things would be *really* nice:
1) Modules aren't checked into CVS and available for distribution unless they *will* compile and build under Linux.
2) The developers would release a *standard* build configuration for Linux.
(The "oh we aren't going to bother to support option xyzzy" doesn't cut it when you have 20+ options).  Failing to have a "known to compile" configuration does not allow people who would *like* to help with Linux product quality determine whether (a) the mozilla development process is a disaster; (b) the CVS failed for some reason; or (c) their "private" configuration is problematic.  At least if a "recommended" standard configuration were distributed it might allow people to separate (a) from (b) & (c).)

If one had a "standard" configuration then users could automate this process and run two compiles -- one standard, and then if that works a private configuration.  I know there is a problem with the library state under Linux but it isn't *that* hard to say the "standard" configuration requires libraries X, Y & Z.

Comment 1

[Robert Bradbury]

Attachment: 1SETDBG.sh - Script to configure firefox for debugging

This script uses the standard Gentoo Linux Firefox configuration flags adjusted towards the goal of producing a fully static firefox with debugging symbols in the binary or the binary and a limited set of shared libraries.

Using this script to configure Firefox fails to produce an executable with the *distributed* Firefox 3.0alpha3 sources as well as the Firefox CVS sources as of April 3 2007.

Comment 2

[Robert Bradbury]

Attachment: An edited list of errors extracted from making firefox

These were simply extracted from a make -i and edited to remove some of the more obvious errors due to the same problem.

Comment 3

[Benjamin Smedberg]

I have no clue what you're talking about. Our tinderboxes build on Linux every hour, as do most of our developers. The problems you have pasted don't make any sense, and appear that you have an inconsistent checkout of some sort.

Comment 4

[Robert Bradbury]

I object to this being considered "invalid".  I have provided the explicit configure, and ome must declare the configure as invalid (i.e. we do not test that configuration *and* provide the "standard" working Linux configuration) or document where the likely CVS problems may be.  I am currently updating and compiling with a 070404 CVS systen.  If it is true that it is checked to compile it would be useful to know precisely *WHAT COMPILE OPTIONS WORK*.  If you do not provide a claim that "this version should compile on most Linux systems" then you are simply providing evidence that Mozilla developers do not really care about Linux.  There are obviously a number of Linux systems out there.  And if one is providing a system which is only Windows enabled, then ones bias is obvious.

Comment 5

[J. Paul Reed [:preed]]

(In reply to comment #0)
> 2) The developers would release a *standard* build configuration for Linux.

http://lxr.mozilla.org/mozilla/source/tools/tinderbox-configs/firefox/linux/

Comment 6

[Robert Bradbury]

Following suggestions of the bad checkout the cvsco.log from the bad build contained:
cvs [checkout aborted]: end of file from server (consult above messages if any)

A subsequent checkout which did not contain any errors does build properly.

I apologize for the inconvenience.  Earlier (infrequent) CVS checkouts had worked and built properly and I expected that CVS checkouts were reliable.  Obviously that is not the case.

Thank you for the pointer to the linux build configurations.

Comment 7

[Robert Bradbury]

I will confirm as of 8 June 2007, a full CVS checkout will not compile under  Gentoo Linux with gcc 4.1.2 (though the gcc version may be unrelated).
----------------------------------------------------------------------------
PROBLEM 1: bug #372269/bug #368844 is still present.
To get cairo-xlib-utils.c to compile on my machine I have the following diff:
42a43
> #define HAVE_STDINT_H 1       /* force definition */

This is *not* a proper fix -- a proper fix involves changing "configure" to recognize that /usr/include/stdint.h is present on the machine and to have the proper variables (HAVE_STDINT_H) be set in the compile line or the system header files, perhaps mozilla-config.h.

As recent discussions in Bug #368844 point out it is highly undesirable to have a situation where the CVS source does *not* compile (or patches exist which have not been applied to the source).  People run around wasting time applying patches, unapplying them and end up totally confused as to what is required to build the program.

------------------------------------------------------------------------------
PROBLEM 2: nsNSSComponent.cpp will not compile.  It is dated May 30, 2007.
Errors produced are:
nsNSSComponent.cpp: In function 'void setOCSPOptions(nsIPrefBranch*)':
nsNSSComponent.cpp:998: error: 'ocspMode_FailureIsVerificationFailure' was not declared in this scope
nsNSSComponent.cpp:998: error: 'CERT_SetOCSPFailureMode' was not declared in this scope
nsNSSComponent.cpp:1001: error: 'ocspMode_FailureIsNotAVerificationFailure' was not declared in this scope
nsNSSComponent.cpp:1001: error: 'CERT_SetOCSPFailureMode' was not declared in this scope
nsNSSComponent.cpp: In function 'nsresult setPassword(PK11SlotInfo*, nsIInterfaceRequestor*)':
nsNSSComponent.cpp:2494: warning: dereferencing type-punned pointer will break strict-aliasing rules

-----------------------------------------------------------------------------
These problems would appear to provide evidence that the CVS source is not compiled under Linux  in a "robust" fashion a regular basis.
-----------------------------------------------------------------------------
In particular, I would suggest that the Tinderbox be changed to:
     
    --enable-mathml
    --enable-ipv6
    --enable-xprint
    --without-system-nss  (though the error used --with-system-nss)
    --without-system-nspr
    --without-system-jpeg
    --without-system-png
    --without-system-zlib
    --enable-pango
    --enable-svg
    --enable-svg-renderer=cairo
    --enable-system-cairo

The goal should be to compile as *much* of the source as possible.  In cases where there are mutually exclusive branches in the source code attempts should be made to compile with *both* branches.  My impression of the current Tinderbox situation is that it is attempting to compile as little Linux specific code as possible.

Comment 8

[Hussam Al-Tayeb]

Robert, will it build with the internal nss?
I think the problem is that you are running the stable system nss and firefox requires the cvs version of nss.
Will it build if you use --without-system-nss ?

Comment 9

[(not currently active) Ted Mielczarek]

The --without-system-* options are the default in configure.  Our tinderboxes compile that code.  --enable-system-cairo is currently broken, but that's filed as bug 368844.  If you have a specific issue, please file it, but we don't keep bugs open for random collections of issues unrelated to the initial filing.  It is certainly possible that there are specific issues related to your environment or compiler or choice of configure flags that cause problems, and we appreciate specific bug reports (and patches, too), but we don't appreciate unfounded accusations of bias.  It's a big project, with a lot of source code, and making sure it compiles on a wide range of systems is a difficult task.  I can assure you that nobody is intentionally making it harder to compile on Linux, but we're certainly not perfect.

Comment 10

[Robert Bradbury]

The problem with --without-system-nss seems to be due to a configuration
problem (attempting to compile new CVS sources with old system header files). 
Problem has been documented in: Bug #383866.

Comment 11

[Hussam Al-Tayeb]

So the system-nss problem will get automatically resolved when nss 3.11.7 is out?

Comment 12

[Robert Bradbury]

Hussam, see my comments under Bug #383866.  Completion of the new NSS code will not solve the problem unless people (a) first do a complete compile and *install* (--without-system-nss), then (b) attempt to compile with (--with-system-nss).  Furthermore, --with-system-nss will *not* work if the Mozilla compile/install places the results someplace different from the "system" install (e.g. /usr/local/include|/usr/local/lib vs. /usr/include|/usr/lib).  There is a real problem in the setup of config/autoconf.mk with having only one flag (--with(out)-system-nss(nspr)) and two variables involved in compiling vs. linking, e.g. NSS(NSPR)_CFLAGS and NSS(NSPR)_LIBS which may require different settings in different build situations.

In my situation I want to compile --without-system-nss (setting NSS_CFLAGS) but link --with-system-nss (setting NSS_LIBS).  That strange situation is due to the fact that "--enable-static" doesn't really work at all -- i.e. it is currently impossible to produce a fully static Mozilla/Firefox under Linux.  If you read the history of Bug #263160 (and the difficulties people have had reproducing it -- even though it now seems to be a longstanding and highly annoying bug) it may become clearer why a fully static Firefox with debug symbols built in would be a highly desirable component to distribute to people who are having "strange" problems).