GNOME Bugzilla – Bug 447118
Implicit pointer conversion (cairo_directfb_surface_create)
Last modified: 2009-03-11 21:19:35 UTC
Hi, Dann Frazier reported in Debian bug http://bugs.debian.org/381081: """ Our automated buildd log filter[1] detected a problem that will cause your package to segfault on architectures where the size of a pointer is greater than the size of an integer, such as ia64 and amd64. The prototype for cairo_directfb_surface_create() in cairo-directfb.h is wrapped in an #ifdef CAIRO_HAS_DIRECTFB_SURFACE. ----- Forwarded message from Debian/IA64 non-US Build Daemon <buildd@caballero.debian.org> ----- Subject: Log for successful build of gtk+2.0_2.8.18-5 (dist=unstable) From: Debian/IA64 non-US Build Daemon <buildd@caballero.debian.org> Date: Mon, 31 Jul 2006 17:24:23 +0100 To: undisclosed-recipients: ; X-PMX-Version: 5.1.2.240295, Antispam-Engine: 2.3.0.1, Antispam-Data: 2006.7.31.85932 X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at ldl.fc.hp.com X-Spam-Checker-Version: SpamAssassin 3.0.3 (2005-04-27) on ldl.lart X-Spam-Level: X-Spam-Status: No, score=-1.5 required=3.5 tests=AWL,BAYES_00,UNDISC_RECIPS, UPPERCASE_25_50 autolearn=no version=3.0.3 Debian-Buildd-Error: Yes Function `cairo_directfb_surface_create' implicitly converted to pointer at gdkdrawable-directfb.c:1081 Function `gdk_font_ref' implicitly converted to pointer at gdkgc-directfb.c:204 """ He proposed to #define CAIRO_HAS_DIRECTFB_SURFACE, but I think a <cairo.h> include is missing. Unfortunately, adding a <cairo.h> #include isn't enough under Debian, but I suspect this is a Debian specific problem. This is likely to create crashes on 64-bits arches. Bye,
Alright, the reason it fails with the "#include <cairo.h>" in Debian is because cairo.pc's cflags are before the cairo-directfb.pc ones, and cairo-directfb's cairo.h isn't used. I wonder whether cairo-directfb tests in configure.in should be using GDK_PACKAGES instead of GDK_EXTRA_CFLAGS/_LIBS.
Created attachment 89882 [details] [review] Initial patch by Dann Frazier
Created attachment 89883 [details] [review] Proposed fix (requires configure.in changes to work in Debian)
Created attachment 89886 [details] [review] Fixes directfb pkg-config modules usage in configure.in It's important that "cairo-directfb" is first in the list of pkg-config modules, otherwise if pangocairo shows up first, it will pull "cairo" and the wrong cairo/cairo.h will be used. Complementary, this fixes the required packages needed to build directfb stuff: the directfb gdk backend uses some DirectFB functions directly but wasn't linking to directfb.
*** Bug 454958 has been marked as a duplicate of this bug. ***
Well, I believe this is a Debian issue. What I *guess* is that Debian has a cairo package with no directfb support, and another one, cairo-directfb, with directfb support, and the former ships cairo.pc while the latter ships cairo-directfb.pc. This is clearly abusing cairo, and you get into a race of which cairo is pulled in. I understand why you need to do that, but helps a lot if you bring it up on cairo list so we work something out upstream. Also reminds me that we added pango-features.h to pango recently with just version macros, but with a plan to add macros for which backends are compiled in later. That apparently breaks the ability to package backends separately. So I'll withdraw that plan... Not sure how to fix this in cairo now.
(In reply to comment #6) > Well, I believe this is a Debian issue. What I *guess* is that Debian has a > cairo package with no directfb support, and another one, cairo-directfb, with > directfb support, and the former ships cairo.pc while the latter ships > cairo-directfb.pc. Your guess is correct. > This is clearly abusing cairo, and you get into a race of which cairo is pulled > in. I understand why you need to do that, but helps a lot if you bring it up > on cairo list so we work something out upstream. Ok; I am only maintaining glib/gtk/pango stuff, the maintainer of cairo in Debian is Dave Beckett. We exchanged a couple of times over email about why cairo was like this and how to handle it (for example I once requested that we get a cairo-directfb.pc + cairo.pc for directfb in a special $PREFIX and the standard cairo.pc in the normal prefix), but his position was that the current layout is the good thing to do, I don't recall the details but probably have them in email. I'm not sure I'll be able to bring this up myself, but I'll try to get Dave starting such a discussion. > Not sure how to fix this in cairo now. If you ask me, ideally we have backends as shared objects loaded in at runtime based on the available + configured or programmed backend (CAIRO_BACKENDS env for example); this allows splitting the backends in different packages. Dunno how hard it is to implement.
(In reply to comment #7) > (In reply to comment #6) > > Well, I believe this is a Debian issue. What I *guess* is that Debian has a > > cairo package with no directfb support, and another one, cairo-directfb, with > > directfb support, and the former ships cairo.pc while the latter ships > > cairo-directfb.pc. > > Your guess is correct. > > > This is clearly abusing cairo, and you get into a race of which cairo is pulled > > in. I understand why you need to do that, but helps a lot if you bring it up > > on cairo list so we work something out upstream. > > Ok; I am only maintaining glib/gtk/pango stuff, the maintainer of cairo in > Debian is Dave Beckett. We exchanged a couple of times over email about why > cairo was like this and how to handle it (for example I once requested that we > get a cairo-directfb.pc + cairo.pc for directfb in a special $PREFIX and the > standard cairo.pc in the normal prefix), but his position was that the current > layout is the good thing to do, I don't recall the details but probably have > them in email. A separate $PREFIX is the right way to do it given cairo's current model. > I'm not sure I'll be able to bring this up myself, but I'll try to get Dave > starting such a discussion. > > > Not sure how to fix this in cairo now. > > If you ask me, ideally we have backends as shared objects loaded in at runtime > based on the available + configured or programmed backend (CAIRO_BACKENDS env > for example); this allows splitting the backends in different packages. Dunno > how hard it is to implement. Right, but that doesn't solve the problem of what goes into cairo-features.h that is included from cairo.h
(In reply to comment #8) > (In reply to comment #7) > > (In reply to comment #6) > > If you ask me, ideally we have backends as shared objects loaded in at runtime > > based on the available + configured or programmed backend (CAIRO_BACKENDS env > > for example); this allows splitting the backends in different packages. Dunno > > how hard it is to implement. > > Right, but that doesn't solve the problem of what goes into cairo-features.h > that is included from cairo.h I guess that if you support multiple backends in the same cairo, then you probably want to offer a way to query what features each backend supports at runtime instead of making these available in headers at build time; perhaps a backward compatible handling of what I see in cairo-features.h would be to list the features of the default backend or the union of the features of all backends?
(In reply to comment #9) > (In reply to comment #8) > > (In reply to comment #7) > > > (In reply to comment #6) > > > If you ask me, ideally we have backends as shared objects loaded in at runtime > > > based on the available + configured or programmed backend (CAIRO_BACKENDS env > > > for example); this allows splitting the backends in different packages. Dunno > > > how hard it is to implement. > > > > Right, but that doesn't solve the problem of what goes into cairo-features.h > > that is included from cairo.h > > I guess that if you support multiple backends in the same cairo, then you > probably want to offer a way to query what features each backend supports at > runtime instead of making these available in headers at build time; perhaps a > backward compatible handling of what I see in cairo-features.h would be to list > the features of the default backend or the union of the features of all > backends? Well, the list of features is essentially the list of backend. Take a look at that file and you see. Note that cairo backends are not drop-in replacements. You need to use the cairo_pdf_surface_create() API call to use the PDF backend. It's not a runtime feature hidden from the user.
Ah, we're not exactly talking of the same thing, I thought you meant backend as the low-level drawing backend (X or directfb) which is not the case. So, to reformulate my initial proposal then: would it be possible to have Cairo support multiple drawing backends in the same build and shipping these as plugins? This would basically permit us to build a single cairo with a set of features and split the drawing backends in multiple packages; the cairo-features header would represent the cairo capabilities that all drawing backends support.
(In reply to comment #11) > Ah, we're not exactly talking of the same thing, I thought you meant backend as > the low-level drawing backend (X or directfb) which is not the case. There is only one type of backend in cairo. Current backends are: X, Win32, PS, PDF, SVG, Quartz, glitz, directfb, OS/2, BeOS. All of them have their own surface constructors. Nothing is hidden from the user. You need to tell cairo where to draw to afterall. > So, to reformulate my initial proposal then: would it be possible to have Cairo > support multiple drawing backends in the same build and shipping these as > plugins? We don't have that architecture yet. What we can do instead, when we are happy about our backend interface and expose it, is to separate backends into their own shared objects, like Pango does for example, but we are not there yet. Hardcoding list of backends in cairo-features.h included from cairo.h can't be easily fixed this way. It doesn't make much sense to just list all possible backends. > This would basically permit us to build a single cairo with a set of features > and split the drawing backends in multiple packages; the cairo-features header > would represent the cairo capabilities that all drawing backends support. So, lets ask, why does Debian need to split in the first place? Because X libraries are not available at boot time?
(In reply to comment #12) > There is only one type of backend in cairo. > X, Win32, PS, PDF, SVG, Quartz, glitz, directfb, OS/2, BeOS. Urgh; I see now... I somehow imaginated that "software picture formats" such as PS, PDF, and SVG were something different from "native drawing stacks". > > This would basically permit us to build a single cairo with a set of features > > and split the drawing backends in multiple packages; the cairo-features header > > would represent the cairo capabilities that all drawing backends support. > So, lets ask, why does Debian need to split in the first place? Because X > libraries are not available at boot time? Well, people wanting to draw on DirectFB usually want to avoid pulling X; in the case of Debian, the libcairo2-directfb package permits running applications using Cairo on a DirectFB backend without pulling any X dependency on your host. One example is the Debian Installer ("d-i") which has a graphical mode based on directfb and doesn't have any X micro-packages on the CD.
The second patch is obsolete; we now have a single cairo build for all backends. This may of course change if cairo finally migrates to a backend-independent API. The first patch is still needed.
On my debian system the first thing that cairo-directfb.h does is to include <cairo.h>. So I don't think this patch is still needed.
Unless someone can explain me why this is still an issue, I will close this report as OBSOLETE.
I can't currently build the directfb backend, but if it builds for you with -Wall and you have no "implicitly converted to pointer" warning in your build log, then you can consider this bug fixed.
I have removed the patch from our latest build, since the cairo includes have been fixed. You should close the bug.