402471 - Current CVS fails to build. Errors in thebes/cairo files.

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Robert Bradbury]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071024 Firefox/2.0.0.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.8) Gecko/20071024 Firefox/2.0.0.8

Building with --enable-default-toolkit=cairo-gtk2 --enable-pango --enable-system-cairo fails to build on a current release of Gentoo Linux.

gfxPDFSurface.cpp and gfxPSSurface.cpp both get compile errors with an undeclared "cairo_surface_show_page" function.  That is a function defined in the system libcairo.a but it does not appear to be declared in any of the system header files.

System cairo is gentoo: x11-libs/cairo-1.4.10.

Reproducible: Always

Steps to Reproduce:
1. Build firefox using same procedures which used to work.
Actual Results:  
Build fails due to compile errors in gfxPDFSurface.cpp and gfxPSSurface.cpp.

Expected Results:  
It *should* build.

I wonder if this is a 

I cannot reconfirm Bug #384917 (or agree that the current release lacks the problem) if I can't build the current release.

Comment 1

[Robert Bradbury]

Sorry, I was going to say I wonder if this is a case of using non-public cairo functions but from a quick google it looks as if its supposed to be a public function.  So somewhere its not being declared for use in C++ when building with the options I've listed.

Comment 2

[Reed Loden [:reed]]

Include the build errors, please?

Comment 3

[Stuart Parmenter]

--enable-system-cairo is unsupported.  you will need a newer version of cairo (1.5.???) to build with it.  I suggest getting rid of that option

Comment 4

[Robert Bradbury]

And who precisely makes the decision to support/desupport a legitimate compile flag which a reasonable user would want to use?  After all, if I have the cairo libraries loaded on my system by various programs and they are "up-to-date" with various Linux distributions, then *why* the heck is Firefox dependent on "more advanced system libraries"?

Particularly when Firefox is known as a god awful memory pig!

If it is indeed UNSUPPORTED then REMOVE THE FRIGGEN CONFIGURATION OPTION from the configure script.

Or is this yet another classic example of Mozilla/Firefox supporting various options when they happen to feel like it?

A standard, widely distributed Linux distribution.
A standard set of configuration flags supported by the configure script.

And the CVS release DOES NOT COMPILE.  And precisely "who" has the problem here?


The errors are:
c++ -o gfxPDFSurface.o -c -fvisibility=hidden -DIMPL_THEBES -DMOZILLA_INTERNAL_API -DOSTYPE=\"Linux2.6\" -DOSARCH=Linux  -I../../../dist/include/cairo -I../../../dist/include/libpixman -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/xpcom -I../../../dist/include/unicharutil -I../../../dist/include/lcms -I../../../dist/include   -I../../../dist/include/thebes -I../../../dist/include/nspr  -DMOZ_PNG_READ -DMOZ_PNG_WRITE   -I../../../dist/sdk/include       -fno-rtti -fno-exceptions -Wall -Wconversion -Wpointer-arith -Wcast-align -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wno-long-long -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -O2 -g2 -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12   -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2 -I/usr/include/libpng12   -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/cairo -I/usr/include/freetype2 -I/usr/include/libpng12     -DMOZILLA_CLIENT -include ../../../mozilla-config.h -Wp,-MD,.deps/gfxPDFSurface.pp gfxPDFSurface.cpp
gfxPDFSurface.cpp: In member function 'virtual nsresult gfxPDFSurface::EndPage()':
gfxPDFSurface.cpp:94: error: 'cairo_surface_show_page' was not declared in this scope

A similar error is produced on the compile of gfxPSSurface.cpp.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Robert: INCOMPLETE is a resolution that's used for bugs that don't have enough information in them to be useful. If you want to protest the resolution of this bug, use "Reopen bug".

Comment 6

[Stuart Parmenter]

We plan on gecko 1.9 being compatible with cairo 1.6 which isn't released yet.  Until then, using system cairo is only available for those who want to verify that the version on their system matches up to the one we require.

Comment 7

[Stuart Parmenter]

(In reply to comment #4)
> And who precisely makes the decision to support/desupport a legitimate compile
> flag which a reasonable user would want to use?  After all, if I have the cairo
> libraries loaded on my system by various programs and they are "up-to-date"
> with various Linux distributions, then *why* the heck is Firefox dependent on
> "more advanced system libraries"?

Your cairo libraries are not up-to-date enough for our needs.  We've said for the last couple of years that this flag would be unstable and that it might happen to work and it might not.  When we first started using cairo it didn't completely meet our needs and we've had to push updates to it.  We can't wait on new stable cairo releases during our prime development process.

> 
> Particularly when Firefox is known as a god awful memory pig!
> 

I'm not sure what you're trying to get at here.  Us using our internal cairo doesn't really lead to any real additional overhead.  That said, a lot of work has been done to address memory concerns and some of those require a version of cairo newer than your distro ships!  Should we just not take advantage of these changes so that you can build with an old version of cairo?


> If it is indeed UNSUPPORTED then REMOVE THE FRIGGEN CONFIGURATION OPTION from
> the configure script.
> 

You can happily use the option _if_ your cairo matches the one that we have internally.  Folks like the cairo maintainers use this option with the unstable cairo builds they have locally which do match the requirements we have.


> Or is this yet another classic example of Mozilla/Firefox supporting various
> options when they happen to feel like it?
> 
> A standard, widely distributed Linux distribution.
> A standard set of configuration flags supported by the configure script.
> 

I don't even know what you're talking about here.

> And the CVS release DOES NOT COMPILE.  And precisely "who" has the problem
> here?
> 
CVS compiles fine.  _You_ have deviated from the standard set of build options.   Ever think there is a reason that we don't have that option as the default? Perhaps you should try building with the default before you start off on long rants?  

Comment 8

[Robert Bradbury]

Ok, I will confirm that the current CVS compiles without the --enable-system-cairo option.

I also have downloaded cairo-1.5.2 and in that source, cairo.h does contain a new declaration for cairo_surface_show_page.  So it is likely, were I to install that then the --enable-system-cairo might work.

So is there *anywhere* which says precisely *what* system packages must be installed to build the CVS system under Linux?

Gentoo is only up to cairo-1.4.10 (no 1.5s, much less 1.6's) and that suggests to me that the timing of the release of Firefox 3.0 is going to have to match the timing of major library upgrades by a number of Linux distributors (unless you intend for them to all release w/o --enable-system-cairo in which case you are wasting memory and CPU time across millions of machines due to excessive paging, cache misses, etc.).