[cairo] Patches for MSVC.NET
stuartp at gmail.com
Wed Dec 14 19:55:57 PST 2005
You don't really want to build the fontconfig stuff, the atsui stuff,
the font-subst stuff, etc on Windows.
As for the test stuff, I just checked in the right fix which is to
#define access _access and to #define F_OK to 0 (per MSDN unix porting
guide whose url is evading me at the moment.)
I'll look through the rest of the patches tonight.
On 12/14/05, Bill Baxter <wbaxter at gmail.com> wrote:
> Hi there,
> I recently got Cairo and Glitz compiling under MSVC.NET 7.1.
> Sunmoon on IRC suggested that I post the patches to the mailing list to see
> if there's any interest.
> I'm sure that some of the #ifdefs I've used are not the right ones. For
> instance I've thrown in some #ifdef _WIN32's in some places that maybe
> should be #ifdef _MSC_VER. But anyway if someone is interested in making
> MSVC officially supported, then at least these patches point to the trouble
> The thing that was the biggest pain was figuring out what to do with the MMX
> stuff in fbmmx.c. Under MSVC the __m64 data type is not a simple typedef
> but a funky union with a __declspec(align(8)) in the declaration. Because
> of that you can't just cast it to and from other types like ullong. I went
> with a special macro that would do the cast via a pointer like
> *(type*)(&m64thing). But actually now that I think of it maybe casting via
> one of the __m64 union members would have been more straightforward. Either
> way it's different from how the casting is done for other platforms, so some
> sort of macro to abstract out the platform differences is called for.
> Another problem with MMX was that the __declspec(align(8)) apparently causes
> functions with more than 3 __m64 arguments to not compile. So I turned
> those into (rather unsafe) macros for MSVC. The macros are unsafe in the
> sense that they have side effects on their arguments, but I checked and
> those side effects are ok for the contexts in which those macros are called.
> Finally in the MMX land, the *8888() functions generate warning messages
> like "No emms instruction at end of function". I know zilch about mmx,
> though, so I'm not really sure what the right fix for that is or if it's
> even really a problem. Apparently it has something to do with the mode of
> the floating point registers. I stuck an _mm_empty() in one of the
> functions, but I'm not sure if that's the right fix.
> The other thing I wasn't sure about was what to do about FontConfig stuff.
> I just ifdef'ed it out for MSVC, because as far as I can tell there isn't a
> version of fontconfig for Win32. Not sure if that will have any ill
> effects. Not even really sure what fontconfig does.
> There was one function that the cairo test program wanted to be cairo_public
> that was not declared as such.
> Other than that it was pretty standard MSVC porting issues. Missing
> standard Unix string functions etc. Took me a while to realize that I had
> to build Cairo as a dll in order to get the thread initialization to work
> properly. :-) Had the whole thing compiling as a static lib intially and
> it would just crash on the first mutex lock.
> I've also included the project files I made for Cairo, Glitz, Glitz
> Rendertest, and one of the Cairo tests in the 'tests' directory.
> William V. Baxter III, Ph.D.
> OLM Digital
> Kono Dens Building Rm 302
> 1-8-8 Wakabayashi Setagaya-ku
> Tokyo, Japan 154-0023
> +81 (3) 3422-3380
> cairo mailing list
> cairo at cairographics.org
More information about the cairo