466250 - build failure for cairo-gtk2 build with a directfb cairo

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[Fabien Tassin]

Attachment: fix v1

When building trunk with a system cairo that is directfb enabled, it fails with:

g++ -o gfxASurface.o -c -I../../../dist/include/system_wrappers -include ../../../config/gcc_hidden.h -DIMPL_THEBES -DMOZILLA_INTERNAL_API -D_IMPL_NS_COM -DEXPORT_XPT_API -DEXPORT_XPTC_API -D_IMPL_NS_COM_OBSOLETE -D_IMPL_NS_GFX -D_IMPL_NS_WIDGET -DIMPL_XREAPI -DIMPL_NS_NET -DIMPL_THEBES  -DOSTYPE=\"Linux2.6\" -DOSARCH=Linux  -I. -I. -I../../../dist/include/cairo -I../../../dist/include/string -I../../../dist/include/pref -I../../../dist/include/xpcom -I../../../dist/include/unicharutil -I../../../dist/include/lcms -I../../../dist/include/locale -I../../../dist/include   -I../../../dist/include/thebes -I/usr/include/nspr   -I/usr/include  -I/build/buildd/xulrunner-1.9.1-1.9.1~b2~hg20081121r21862+nobinonly/build-tree/mozilla/dist/sdk/include    -fPIC   -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-long-long -pedantic -g -fno-strict-aliasing -fshort-wchar -pthread -pipe  -DNDEBUG -DTRIMMED -Os -freorder-blocks -fno-reorder-functions  -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12   -D_REENTRANT -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12   -D_REENTRANT -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/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/gtk-unix-print-2.0   -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/freetype2     -DMOZILLA_CLIENT -include ../../../mozilla-config.h -Wp,-MD,.deps/gfxASurface.pp gfxASurface.cpp
gfxASurface.cpp:59:32: error: gfxDirectFBSurface.h: No such file or directory
gfxASurface.cpp: In static member function 'static already_AddRefed<gfxASurface> gfxASurface::Wrap(cairo_surface_t*)':
gfxASurface.cpp:176: error: expected type-specifier before 'gfxDirectFBSurface'
gfxASurface.cpp:176: error: cannot convert 'int*' to 'gfxASurface*' in assignment
gfxASurface.cpp:176: error: expected `;' before 'gfxDirectFBSurface'
make[6]: *** [gfxASurface.o] Error 1
make[6]: Leaving directory `/build/buildd/xulrunner/mozilla/gfx/thebes/src'

One option could be to protect the code with MOZ_DFB as in the patch attached.
Another could be to fix the CFLAGS to include -I../public.

Comment 1

[Zeev Tarantov]

The CFLAGS already include -I../../../dist/include/thebes, which is where /src/gfx/themes/public/ gets copied. The file is not there because you are compiling MOZ_DEFAULT_TOOLKIT="cairo-gtk2", not "cairo-gtk2-dfb".

When mozilla is compiled with the bundled cairo with
 MOZ_DEFAULT_TOOLKIT="cairo-gtk2", cairo is configured to have
 CAIRO_HAS_XLIB_SURFACE but not CAIRO_HAS_DIRECTFB_SURFACE.
Which is great.
In src/gfx/thebes/public/Makefile.in, the varius surfaces are included in
the exported dist include directory depending on MOZ_WIDGET_TOOLKIT
and MOZ_X11 with MOZ_DFB. These are set by the main configure script, when
MOZ_DEFAULT_TOOLKIT is set. So with cairo-gtk2, MOZ_X11 is set but MOZ_DFB
is unset. gfxDirectFBSurface.h is not exported. This is also great.

When compiling mozilla/src/gfx/thebes/src/gfxASurface.cpp, it includes the
various surfaces depending on whether cairo supports them (as defined in
cairo-features.h, included from cairo.h), rather than depending on
MOZ_WIDGET_TOOLKIT and MOZ_X11 with MOZ_DFB, i.e. the configuration.
Ans so, when compiled with "ac_add_options --enable-system-cairo", if the system
cairo has been compiled with DFB support (for example on Ubuntu), gfxASurface.cpp
tries to include gfxDirectFBSurface.h, which is not in dist/include/thebes,
and errors out.

I think gfxASurface.cpp should really use mozilla's configuration macros rather
than cairo's to determine which surface to use. Maybe check both, though
it's the configure script's job to determine that cairo has the required support
for the toolkit we're requesting.

Comment 2

[David Ward]

Same error when building Thunderbird 3.0 beta 2 on Ubuntu 9.04 beta.  It's picking up CAIRO_HAS_DIRECTFB_SURFACE=1 from /usr/include/cairo/cairo-features.h, but MOZ_DFB=0 from the configure scripts.

This may or may not actually be causing the problem, but Thunderbird/comm-central's configure script does not have a toolkit option of 'cairo-gtk2-dfb', as mozilla-central's configure script does.  I can see that causing some inconsistencies as the comm-central sources build and rely on mozilla-central.  Can the same modifications that vladimir made to add DirectFB support to mozilla-central (http://people.mozilla.com/~vladimir/misc/1-thebes-directfb.patch) be added to comm-central?

Comment 3

[Hiroyuki Ikezoe (:hiro)]

Attachment: Update Fabian's patch

Also use MOZ_X11 instead of CAIRO_HAS_XLIB_SURFACE for cairo-gtk2-dfb.

Comment 4

[xtragb]

Bug confirmed on Ubuntu 9.04. Hiroyuki's update to Fabien's patch allows build without gfxASurface error.

Comment 5

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

This patch isn't sufficient to build comm-central, but that may be a different bug.

Comment 6

[Hiroyuki Ikezoe (:hiro)]

Which bug?

Comment 7

[David Ward]

Philipp, please try again.  I was also having a different problem building a working Thunderbird even earlier this week, due to something in the Mozilla 1.9.1 source, but that issue seems to have been resolved recently.

Building under an environment where cairo has directfb support is still broken.  This patch still fixes it with the current source (it is the only patch I need).  Could you (or someone) please review and commit?

Comment 8

[David Ward]

This patch has been ready for review for two months.  It is marked for review by vladimir.  Is he available for review or can someone else do it?

Comment 9

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 372770 [details] [diff] [review]
Update Fabian's patch

This is clearly right...

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Pushed.

http://hg.mozilla.org/mozilla-central/rev/9eca240fc4b8

Comment 11

[David Ward]

Thanks for applying the patch to mozilla-central.  However this patch also needs to be applied to mozilla-1.9.1 in order for comm-central (Thunderbird 3.0 and Sunbird 1.0) to build correctly.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Comment on attachment 372770 [details] [diff] [review]
Update Fabian's patch

per comment #11.

Comment 14

[Mark Banner (:standard8)]

Comment on attachment 372770 [details] [diff] [review]
Update Fabian's patch

Shifting approval flag onto the next 1.9.1.2 build so we can hopefully pick this up for all apps.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Comment on attachment 372770 [details] [diff] [review]
Update Fabian's patch

a1912=beltzner

Comment 16

[David Ward]

Thunderbird 3.0 beta 3 pulls from mozilla-central using the tag 'GECKO_1_9_1_BASE', so it is not getting this patch.  (See 'client.py' in comm-central.)  I'd like to see Thunderbird 3.0 (and Sunbird/Lightning 1.0) not be affected by this bug out of the box.  So does Thunderbird 3.0 need to start pulling a different tag from mozilla-central ... or does this patch need to be checked in under 'GECKO_1_9_1_BASE' ... or basically what needs to occur to make that happen?

Comment 17

[Samuel Sidler (old account; do not CC)]

Hiroyuki Ikezoe: When you check this into mozilla-1.9.1, be sure to use ".2-fixed" option in the "status1.9.1" field to mark this as fixed for 1.9.1.2.

Comment 18

[Mark Banner (:standard8)]

(In reply to comment #16)
> Thunderbird 3.0 beta 3 pulls from mozilla-central using the tag
> 'GECKO_1_9_1_BASE', so it is not getting this patch.  (See 'client.py' in
> comm-central.) I'd like to see Thunderbird 3.0 (and Sunbird/Lightning 1.0) not
> be affected by this bug out of the box.  So does Thunderbird 3.0 need to start
> pulling a different tag from mozilla-central ... or does this patch need to be
> checked in under 'GECKO_1_9_1_BASE' ... or basically what needs to occur to
> make that happen?

The Thunderbird 3 builds don't pull from mozilla-central they pull from mozilla-1.9.1 which is getting this fix. So nothing no changes are needed to make this happen.

Comment 19

[Samuel Sidler (old account; do not CC)]

Comment on attachment 372770 [details] [diff] [review]
Update Fabian's patch

This didn't land in time for 1.9.1.2.

Comment 20

[Daniel Veditz [:dveditz]]

Comment on attachment 372770 [details] [diff] [review]
Update Fabian's patch

Approved for 1.9.1.4, a=dveditz for release-drivers

Let's try to get this one landed this time.

Comment 21

[Daniel Veditz [:dveditz]]

Comment on attachment 372770 [details] [diff] [review]
Update Fabian's patch

past code-freeze for 1.9.1.4, removing non-blocker approval.

Comment 22

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Comment on attachment 372770 [details] [diff] [review]
Update Fabian's patch

If noone objects, I'll take care of the checkin for 1.9.1.5, I'd like to get this patch in, its a pity it hasn't made it before.

Comment 23

[Daniel Veditz [:dveditz]]

Comment on attachment 372770 [details] [diff] [review]
Update Fabian's patch

Approved for 1.9.1.5, a=dveditz for release-drivers

Comment 24

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Pushed to mozilla 1.9.1
<http://hg.mozilla.org/releases/mozilla-1.9.1/rev/55b533191e5c>

status 1.9.1 -> .5-fixed