[cairo] cairo 1.12.4 and 1.12.6 fail to build on OSX 10.6.8

[Chris Wilson]

On Wed, 31 Oct 2012 14:38:27 +0100, Thomas Klausner <wiz at NetBSD.org> wrote:
> On Wed, Oct 31, 2012 at 01:22:57PM +0000, Chris Wilson wrote:
> > > I've added these patches to pkgsrc to get further in the build
> > > breakage on NetBSD-5[1], but this breaks startup of firefox and others on
> > > NetBSD-6 with:
> > > assertion "!"reached"" failed: file "cairo-xlib-surface-shm.c", line 58,
> > > function "_cairo_xlib_surface_put_shm"
> > 
> > Thanks, that was a mistake on part thinking that it wouldn't be called
> > if we never succeeded in getting a shm surface.
> >  
> > > The programs work fine with cairo-1.12.6 + the "Xorg"-recognition fix
> > > but without those patches.
> > 
> > Right, this is worrying as we know believe that we can't enable SHM on
> > your system. Can you please attach the config.log?
> 
> Attached. Thinking some more about it, I noticed that I hadn't
> supplied a new config.h.in with the three new symbols, so the
> configure check's output couldn't propagate to the source code. I'm
> sorry, I think this is just a local problem due to this error.
> 
> A short test later: yes, patching config.h.in gets rid of this issue.
> Sorry again about the wrong error report.

It also looks like the test for shmstr.h doesn't pass in enough includes
for it to succeed, the configure test fails with an undefined PixmapPtr.
Hmm, the server is leaking its internal API? Ugh. I can see why it was
removed.

> > >  Thomas
> > > 
> > > [1] The build on NetBSD-5 later fails with
> > >     CC     cairo-gl-device.lo
> > >   cairo-gl-device.c: In function '_cairo_gl_context_init':
> > >   cairo-gl-device.c:285: error: 'GL_MAX_RENDERBUFFER_SIZE' undeclared (first use in this function)
> > 
> > Looks like we need to be testing for a recent enough version of glext.h
> > before allowing the gl backend to be built. You will need to be careful
> > to use --enable-gl=auto if you want to use the same pkg script and not
> > have configure error out if it cannot build GL when passed --enable-gl.
> 
> So the simple fix is to --disable-gl on systems with too old MesaLib
> like NetBSD-5 and lose some speed (anything else?)?

--disable-gl should be sufficient, you don't lose anything but the
feature to create a cairo_gl_surface_t, which is only really being
experimented with currently by toy applications (excluding the embedded
deployments). The advantage is then every user of cairo is no longer also
linking to libGL.so, which for some drivers can cause every process to
suddenly grow by a few megabytes of private memory (even if it is never
actually used).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre