Bug 39493

Created attachment 49446 [details] [review]
Correct all OSX 10.7 build failures

Oops, that should have been "< MAC_OS_X_VERSION_10_7". 
There are also two files in perf that define getline and strndup, which are supplied by Lion in stdio.h and string.h, respectively. This patch works around those, as well.

(In reply to comment #1)
> Created an attachment (id=49446) [details]
> Correct all OSX 10.7 build failures
> 
> Oops, that should have been "< MAC_OS_X_VERSION_10_7". 

I can confirm this issue and the fix for ATSUI looks ok to me.

> There are also two files in perf that define getline and strndup, which are
> supplied by Lion in stdio.h and string.h, respectively. This patch works around
> those, as well.

I think that detecting the availability of  getline and strndup at through autoconf would be a better.

(In reply to comment #2)
> (In reply to comment #1)
> > Created an attachment (id=49446) [details] [details]
> > Correct all OSX 10.7 build failures
> > 
> > Oops, that should have been "< MAC_OS_X_VERSION_10_7". 
> 
> I can confirm this issue and the fix for ATSUI looks ok to me.

Looking more at it, I realized that it's probably an API break.

Another patch, which fixes the build for me is available here:
http://cgit.freedesktop.org/~ranma42/cairo/commit/?h=wip/lion-build&id=226ddd92589bc6d93ad7dab34e79e2770d096a69

Can you confirm if this patch solves your issue as well?

> 
> > There are also two files in perf that define getline and strndup, which are
> > supplied by Lion in stdio.h and string.h, respectively. This patch works around
> > those, as well.
> 
> I think that detecting the availability of  getline and strndup at through
> autoconf would be a better.

The autoconf-based detection is in master (and the implementation if the functions are not available is now in the util/cairo-missing library).

Cairo builds on Lion with the ranma42 patch, yes.

The only problem with any build-time configuration for these is that the resulting shared library won't work on previous versions of OSX. That includes Snow Leopard and previous in the cases of getline and strndup, and Tiger for ATSUI support. One can work around that for now by building against the 10.6 SDK.

But unfortunately it now fails when building on Leopard:
  CCLD   cairo-analyse-trace
Undefined symbols:
  "_strndup", referenced from:
      _main in cairo-analyse-trace.o
  "_getline", referenced from:
      _main in cairo-analyse-trace.o
ld: symbol(s) not found

$  nm util/cairo-missing/.libs/libcairo-missing.dylib | grep strndup
00001da0 t _strndup

So, not exported.

Created attachment 50961 [details] [review]
Make cairo-missing a static library

(In reply to comment #4)
> Cairo builds on Lion with the ranma42 patch, yes.
> 
> The only problem with any build-time configuration for these is that the
> resulting shared library won't work on previous versions of OSX. That includes
> Snow Leopard and previous in the cases of getline and strndup, and Tiger for
> ATSUI support. One can work around that for now by building against the 10.6
> SDK.

Yes, that's true.
If it becomes an issue, we can define strndup()/getline() in cairo-missing unconditionally, so that they will always be available.

Regarding the font thing, I just noticed that although it's not available in the headers, FMGetATSFontRefFromFont is still provided by the 10.7 frameworks:
$ nm /Developer/SDKs/MacOSX10.7.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/Current/Frameworks/QD.framework/Versions/Current/QD | grep FMGetATSFontRefFromFont
0000000000007ec1 T _FMGetATSFontRefFromFont

We can probably make it available just like "private" APIs by dlsym'ing it.

(In reply to comment #5)
> But unfortunately it now fails when building on Leopard:
>   CCLD   cairo-analyse-trace
> Undefined symbols:
>   "_strndup", referenced from:
>       _main in cairo-analyse-trace.o
>   "_getline", referenced from:
>       _main in cairo-analyse-trace.o
> ld: symbol(s) not found
> 
> $  nm util/cairo-missing/.libs/libcairo-missing.dylib | grep strndup
> 00001da0 t _strndup
> 
> So, not exported.

Yes, they're not exported as it was supposed to be a static library.
Can you please check if the attached patch fixes your 10.6 build?

Otherwise, can you provide additional details about your 10.6 build environment?
In my environment the build fails with:
Undefined symbols for architecture x86_64:
  "_png_set_longjmp_fn", referenced from:
      _read_png in lto.o
      _png_simple_error_callback in lto.o
      _write_png in lto.o

(which is weird, as the build works just fine when I don't have "-isysroot /Developer/SDKs/MacOSX10.6.sdk" in CFLAGS/LDFLAGS).

Created attachment 50989 [details]
Cairo config.log for gtk-osx build

Comment on attachment 50989 [details]
Cairo config.log for gtk-osx build

Yes, that did it. 

(I'd created the attachment before looking to make sure that libcairo-missing had gotten rebuilt -- and naturally, it hadn't.)

Created attachment 51316 [details] [review]
The dlsym trick

This patch should work and provide the API on every system (returning nil fonts when it doesn't actually work).

OK, that works too, and should handle the binary portability problem as well.
Thanks!

Fixed in master by:

commit 8664df767cb9dbe48647f9853e3dcf551701d3ca
Author: Andrea Canciani <ranma42@gmail.com>
Date:   Sat Sep 3 09:39:24 2011 -0700

    quartz: Fix the 32-bits build on MacOSX 10.7
    
    FMGetATSFontRefFromFont() is not public on Lion nor on 64-bits
    Frameworks, but it seems to be available in the dynamic libs, hence we
    can dlsym() it just like other private functions.
    
    Works around the error:
    cairo-quartz-font.c: In function 'cairo_quartz_font_face_create_for_atsu_font_id':
    cairo-quartz-font.c:830: error: implicit declaration of function 'FMGetATSFontRefFromFont'
    
    Fixes https://bugs.freedesktop.org/show_bug.cgi?id=39493