[cairo] Compiling cairo against winelib, to enable win32 testing on Linux

[Jim Gettys]

Behdad,

Jeremy White at Codeweavers may be able to point you at people who can
help.

Unfortunately, most of the work has been focused on Wine/Crossover
Office, as those pay Jeremy's bills.  But Jeremy is a great guy, and can
point you in the best directions in this area.
                                     Best Regards,
                                        - Jim


On Tue, 2007-02-20 at 01:18 -0500, Behdad Esfahbod wrote:
> I got this idea to use winelib to compile the win32 backend on Linux.
> Carl and I both have the feeling that even being able to just compile
> (and not run/test) the win32 (and other) backends increases the quality
> of our releases because we would know that we've not broken something
> very silly for the least.
> 
> So I started looking into this.  Documentation for winelib is four years
> old, to say the least.  So I had to do lots of trials and see how wine
> builds its dlls itself to find my way out.  In the end, it doesn't look
> that bad, though not as good as I thought either.
> 
> I pushed some changes to master that enable using winelib by just doing:
> 
> ./configure CC=winegcc LD=winegcc
> 
> You can turn off the win32 font backend, if you want, by doing
> --disable-win32-font.  The main problem with the build system at this
> point though is that libtool decides that winelib cannot make shared
> libraries.  So it builds static libs only.  I'll look into fixing that
> later.
> 
> Next problem I still have is that pdf2png and svg2png won't link now.
> Not sure why's that.  Also note that binaries generated by winegcc are
> in fact a small script calling wine to load the actualy .exe.so file
> generated.  This is not much worse than what libtool already does for
> us, but we may be able to get to plain binaries since we don't use any
> native Windows binaries and so the wine loader should not be necessary.
> 
> Finally, running the test suite.  First, for an unknown reason, it
> crashes if $DISPLAY is set.  It does so in a gdi32.something_flush
> function.  Interestingly, if I unset DISPLAY, it kinda works now.  The
> font stuff doesn't look good, so I turned win32-font backend off and
> used freetype.  The other major problem is that it seems like some kind
> of composite operations are ignored.  The most evident effect of this is
> that about 50 tests fail, and most have a totally black output image.
> In some testing that I did, painting an image surface to a win32 surface
> works, but simply painting a solid color to it doesn't work.  Wine
> bug...
> 
> 
> Anyway, just wanted to give a heads up, and I'll be looking into this
> stuff a bit more, but those familiar with windows and wine stuff feel
> free to give this a try and improve it.  Good test for wine in fact.  I
> hope they pick this up and fix their stuff.
> 
-- 
Jim Gettys
One Laptop Per Child